Some general comments and clarifications about CVS write access.

["Mike A. Harris" <mharris@www.linux.org.uk>]

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