CVS policy discussion, communication (was Re: Discussingissues)

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

On Tue, 15 Apr 2003, Mark Vojkovich wrote:

>> "While there are things that people have a right to demand - they have a 
>> right to demand to be able to contribute..."   
>> 
>> The above clearly outlines to me why "the people who have contributed the 
>> most having the most say?" is clearly wrong. Just because you have been 
>> developing XFree86 code for many years, what right do *you* have to 
>> control what *I* can contribute to XFree86? The mere fact that such a 
>
>   The fact that I've have written and maintained particular parts
>of the code gives me the right to reject misguided modifications to
>that code.  You should not be allowed to get any code you see fit
>into XFree86.  There needs to be agreement on the part of the people
>who know the most about that code.  Most of the time, defering to the
>opinion of the maintainer/author is suitable.

I don't think anyone sensible would disagree with that.  ;o)

Theoretically the CVS access list could have people could be
given limited access with rules drafted that say "stay out of
here, this is Mark's area and you will die if you even think of
touching this area".  A simple CVS policy guide would let people
know very clearly what parts of the repository are "owned don't
touch", what parts are "unowned, get approval on list before
committing", what parts are "obvious fixes are ok from you", and
whatever other categories would be considered acceptable.

With such guidelines in place, if someone violates the rules,
then depending on the severity of their goofup, they either get
yelled at and their changes reverted, yelled at and their commit
fixed, or something more severe such as being locked out of a
portion of the repository or in worst cases - temporary or
permanent CVS write access revokation.

Other projects have policies similar to this that have proven to
work well.  It doesn't mean that you allow a whackload of 500
people to have access necessarily though (although some projects
do).  When allowing someone access, IMHO, what is the most
important when considering possible CVS write access for someone,
is that:

1) They've contributed code in the past, preferably several times 
   which has been mostly good stuff.

2) They seem likely to make more contributions and/or maintain a
   given area of code and having CVS write access might both help
   them to do so, and also possibly encourage them to do more to 
   help the project out in the future.

3) They understand clearly what areas of the tree they can touch, 
   and under what specific rules, and they understand the 
   different levels of consequence for screwing something up 
   accidentally, and also of screwing something up purposefully
   or incompetantly, or by doing something that causes upheaval 
   or is met by wide disapproval.

4) They know what kind of changes are considered acceptable 
   during different times of development and adhere to this 
   policy.  ie: feature freeze, code freeze, etc.

5) They know to commit obvious fixes, and to bugzilla other stuff 
   or open up discussion in email about it, and not just commit 
   random stuff.

6) They know to test things as well as they can before
   committing, or get other people to do so prior to committing.

7) They keep the tree buildable at all times, and either back out 
   a broken commit they've made, or fix the problem, trying to 
   make sure with every change they make that they have made 
   responsible and reasonable attempts to not break things 
   carelessly.


>> small list of people control what does and does not get into XFree86 
>> means that mine and everyone elses contributions to XFree86 stand a very 
>> large chance of getting lost. As you said above, myself and other 
>> developers have a right to demand to be able to contribute, and IMHO that 
>> is entirely what this discussion is all about.
>
>   I would be happy if this is what the discussion was about.  
>Some people are discussing how we can get the problem of contributing
>code solved, but others, including the person who started this
>whole thing has been using the fact that there are problems as
>an argument for scraping not just the commit mechanism, but the
>entire leadership structure of the project.

While there have been times when I've thought project leadership
might be the core problem, I don't think that is the real core
problem anymore.

I personally believe the largest problem of all is a problem of
miscommunication between all parties.  Generally speaking, if all
parties can work on the communication problems, put aside some
personal differences, personality conflicts and whatnot, and try
to keep the past - "in the past" as much as possible, then it
might be possible to repair broken relationships, regain lost
trust, reflect true intentions, and generally work together in a 
more co-operative and positive way.

I think that all involved persons and groups of people have
common goals, and that we're just not all very good at
communicating things between each other in the best or most
polite way possible.  People generally tend to get tied up in 
personal issues or past occurances and it blurs the process of 
trying to resolve issues and move forward.

Not sure what the best way is to try to improve the situation, 
but I'm going to try to do my part to try and communicate more 
effectively and practice what I'm preaching above.  ;o)  I'm sure 
I'll slip up every now and then, just point this email out to me 
when I do.  ;o)

I'm hoping others will try to do the same, and I have faith that
progress in communication is achievable.  Governance becomes a
non-issue quickly if communication (on *ALL* sides) can take a
turn for the better.

Take care,
TTYL


-- 
Mike A. Harris



_______________________________________________
Forum mailing list
Forum@XFree86.Org
http://XFree86.Org/mailman/listinfo/forum