Some general comments and clarifications about CVS write access.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Tue, 15 Apr 2003, Kendall Bennett wrote: >> Yes, that's a way to influence the technical direction of >> XFree86. The group I was addressing specificially was the group of >> people who don't do the work, but who think they should have a say >> in what XFree86 should be doing. Those people don't have have any >> incentive to give to the people who do the work. > >Which group of people specifically are you talking about here? Lurkers on >the XFree86 mailing lists? > >Clearly to me Keith Packard, Jim Gettys, Havoc Pennington, Mike Harris >and others involved in trying to sort out this mess are not those people. >Those guys are all active developers who want the flexibility to be able >to work efficiently on the code, not dictate to someone else what they >should be working on! I don't believe any of them would sit back and tell >someone else what to do, but would rather dig right in and do it >themselves, just like they have done in the past. You just brought up something that I think I should make a comment on as a few people have touched upon this in the past and due to the heat-levels in the particular discussions that were going on, I decided to just not comment about it rather than fan any flames. Since this isn't a flamewar though, I'll make a few comments here about CVS access. ;o) For the most part, for me personally at least right now, I don't need CVS write access to work efficiently on any code as I'm not working on any major section of code that would benefit me greatly having CVS write access. I believe that sometime in the past I've asked David Dawes about what was required in order to get CVS write access before, just to be aware of what was needed just to understand the process rather than being a request. I don't think I've ever asked David or anyone else to actually give me CVS write permission, or if I have, I don't recall doing so. Some people on this list have implied however that I have asked, or that I would love to have CVS write access. Those are their words, and definitely not mine. I've submitted quite a number of patches to the patches@ or fixes@ submission addresses in the past, both ongoing over time, as well as patch blasts sometimes when we start having a pileup of patches we're applying to our releases. Not all of these patches are of my own authorship however. The patches come from various places including: 1) Patches I've written myself. Most, but not all of these patches have ended up being committed to CVS by David or someone else either unmodified or with slight modification. A few have been rejected, sometimes with an explanation of why, and in most cases the explanation was very reasonable. Only one patch springs to mind which was rejected that I disagreed with the objections of the person rejecting it. No big issue. 2) Patches another Red Hat developer has written and given me. Some of these are like #1 above. Other submissions have been rejected and often with fairly good reasons given. Some of these patches are things that I've reviewed and personally felt were correct, while other patches are in areas of X that are beyond my comprehension - such as the i18n code. Ick. I've basically thrown i18n patches over my shoulder upstream in hopes someone who actually understands that stuff will look at it and either accept it or reject it with an explanation of why. My thought being "I don't understand this crap, perhaps someone more knowledgeable will, and if I submit and it is good, it will be committed and the codebase benefits, rather than sitting on it not knowing either way". 3) Patches from user submitted bug reports that the bug reporter found a bug, fixed it and submitted their report and patch. 4) Patches from user submitted bug reports that the bug reporter found a bug, found a patch in the wild and attached it. For both 3 & 4 - Some of these patches are obvious fixes, while others I simply may not be able to judge due to unfamiliarity with the problem area. I've submitted both types of patches upstream in hopes the obvious ones would get committed to CVS, and the ones that I can't really review for correctness myself will be rejected by someone more knowledgeable in the particular area than I am. I don't necessarily "endorse" all of these patches as being "correct" when submitting them. My thought was to let someone else decide that. 5) Patches backported from XFree86 CVS head or DRI-CVS. I generally do this in order to improve our packages with fixes that have gotten into the current development code which for whatever reason nobody has commited to the current stable branch also. These are generally simple obvious fixes, and are in all cases tested in the wild. They are sometimes accepted, but they're usually just ignored. I assume that they're rejected either because they are small and/or trivial and not likely bugs that affect many people, so they're good enough just waiting for the next release. Or perhaps some of them are ignored/rejected because they require testing and nobody thinks they've already been tested good enough yet, or that there is a stronger risk of breaking something that is larger than what the fix will bring in fixing it. 6) Patches someone has posted to a mailing list or other forum in which I've noticed the patch and realized that person hasn't posted their patch to the proper place where a developer is likely to see it or care about it, so I just politely forward the patch on without paying much attention to what it is really doing, and without reviewing it. I've done this simply so that more patches get seen by people who might want to review them for correctness and whatnot, and in the hope it might actually fix the problem and in a correct way. Unfortunately, I haven't always been clear when submitting patches of wether or not I've reviewed them or not, or if I'm just passing them on, and so quite often patches that get rejected have left a "What the hell was Mike thinking when reviewing this and submitting it" taste in some people's mouths. I suppose it is my fault for not making things ultra clear with every submission as to what my intentions of submitting it were, and wether I had actually reviewed it or not or was just trying to be a good samaritan. 7) Patches I've snarfed from other distributions. These are usually accepted, but sometimes rejected. Some I review and use in our packaging, and others I might just pass upstream as I'm not sure if it is a proper or useful fix or not. Again, I haven't been careful with distinguishing between the two when sending things in. Statistically, most of the patches that I have submitted to the patches or fixes submission lists of my own authorship, have been commited to CVS either unmodified, or with slight modification by the committer. Of all of the patches that I've ever submitted which have been rejected, the overwhelming majority of them were patches written by other people, most of which I've not really reviewed personally, or which are simply in areas of code that I really know nothing about. When in doubt, I've submitted a patch upstream in order for someone else to determine wether or not it is good. The unfortunate problem this has caused, is that on the receiving end of patch submissions, it seems that the person reviewing the patch generally assumes that every single patch being submitted was personally reviewed by the submitter to fix the given problem, and that the patch submitter also both reviewed the patch and approved it to be a good and proper fix. When these patches are not considered "good" or correct, or if they're considered outright crap, it has ended up causing the person reviewing the submission to think I'm crackheaded for submitting the patch in the first place. That may be my fault for not being clear about things when submitting patches as to their specific origin, and wether or not I personally consider the patch to be correct, or if I'm just passing it on for someone else to decide, or if I'm just throwing a random patch I found over my shoulder to someone else to determine if it is good or not. The end result is that some XFree86.org people do not think the quality of my patch submissions are up to scratch, and some have went as far as publically or privately kicking dirt in my face over it, or believe that I can't make the distinction between what is good and what is bad with a high ratio of good judgement. I disagree of course, because the majority of patches that I have submitted that I actually wrote or reviewed and felt were correct fixes have almost all been included in CVS without any problems. In fact, theoretically, if I did actually have CVS write access to the repository, the only stuff I'd actually commit to CVS in the first place would be things that I knew to be decent fixes which nobody would likely object to, or at least to the same degree that anyone else who has CVS access right now would commit. Anything that I can't personally be really sure about, or is just a random patch thrown upstream in case someone finds it to be useful would end up being something shoved in bugzilla for someone else to look at, and _definitely_ not something I'd put into CVS. That's more or less common sense IMHO. Anyone who has CVS in some project out there needs to be reasonably sure that the code they are committing isn't going to randomly break stuff constantly. Doing otherwise is simply irresponsible and if someone has CVS access in a project and continuously breaks stuff by committing things without properly reviewing them or testing them, then they should end up having their priveledges removed either temporarily or permanently depending on the extent of problems they've caused other developers or the project as a whole. That's how quite a few other projects basically work anyway. People who have CVS write permission have a responsibility to use it properly and in a way that is not harmful to the project they're working on. If one has code and isn't sure, then they should either discuss it with other developers in mail/IRC/whatever, or they should submit it to the project's bug tracker and state "not sure about this one, what do others think" or somesuch. So while I'm not personally asking for CVS write access to the XFree86.org CVS repository, if I did have that priveledge I feel fairly confident that I'd use it pretty responsibly, just as I have in any other projects I've had CVS write access to. I've got write access to DRI-CVS and haven't trashed it at all. ;o) I have no problem submitting patches to XFree86.org bugzilla however, and that's how I'll be submitting from now on since I feel that bugzilla is superior to the patch submission mailing lists were anyway. Bugzilla has a sort of side effect of forcing you to be more explicit about problems when filing, and is likely to make any intentions of a patch submission much more clear. It also has the benefit of allowing others to see the patches and comment on them, provide feedback, and exposes it publically in a multi-way discussion of sorts rather than a "private submit" + "private response/reject" way. It only stands to increase communication in a positive way IMHO and extend it to more people. In the end, what is much more important to me than getting CVS write permission for myself is simply seeing positive progress in the realm of patch submissions, peer and project review, and communication, patch attribution and origination, and I think bugzilla improves this drastically right now. When I submit patches via CVS, I will try to flag them clearly as to wether I consider them correct "as-is", or wether i am submitting them for review. Perhaps my intentions will become more clear then in the future, and people will get sick of using bugzilla and trust my true judgement. ;o) Apologies for the long book, but I do tend to be a windbag at times when I want to communicate something. ;o) Take care all, TTYL -- Mike A. Harris _______________________________________________ Forum mailing list Forum@XFree86.Org http://XFree86.Org/mailman/listinfo/forum
[Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Samba] [Linux Security] [Linux RAID] [Linux Resources]