X11R6.8.2 maintenance release plans and call for comments.

[Roland Mainz]

Kristian Høgsberg wrote:
[snip]
> >> I thought Kristian's proposal was pretty solid.  Torrey had raised the
> >> objection that the requirement for a bug number for each change might be
> >> excessive.  Personally bugzilla is so integrated with my workflow that I
> >> don't see this as an issue.  I would at minimum like for each change to
> >> include _some_ external reference, be that a link to a message in the
> >> mail
> >> archives, or a distributor bug number, or whatever.  I can deal with that
> >> being a SHOULD rather than a MUST though.
> >
> > Yes, that is what I had in mind. A common scenario for me is that I get
> > private email reporting a bug which I fix quickly in the top of tree. I
> > always include a note on who reported the bug in the ChangeLog and
> > commit message. I find it burdensome to have to create a special bug in
> > Bugzilla simply for the purpose of being able to back port each fix when
> > I've already well documented everything.
> 
> But if the only reference in the ChangeLog is the email address of the
> reporter it isn't really that useful.  The nice thing about a bugzilla
> reference is that you can go and read the description of the problem,
> and ideally the patch will be attached to the bug, which makes it easy
> to review and back out if necessary.
> 
> However, I'm also OK with a SHOULD instead of MUST, especially for
> small, trivial patches.

There is still a problem: Without having a bugzilla bug id and a patch
stored there it is _very_ hard to identify patches and allow vendors to
import only exactly that patch into their codebase on demand. And the
bugzilla bugs can be used for further communication between developers
and to store additional comments after checkin (like "this bug caused
bug xyz" or "... this regressed feature abc ...".

Just one example: Right now I am fighting myself with this problem -
someone from Redhat checked in a patch which seems to change the usage
of iso10646-1 encoded fonts in fontsets but there is no bugid and I
think the patch I fetched from CVS is either incomplete or the change
commited to CVS is broken itself. There is no bugzilla bug where I can
ask and no patch stored in a bugzilla bug which can be looked at. GREAT.
xx@@@@!!!... ;-(

I would perfer a "MUST-have-bugzilla-bug" here to avoid this mess.
Opening a bugzilla bug and store a patch there is usually a task which
can be done within less than a minute. And it avoids the __PAIN__ like
the one described above.

> > A more fundamental question is whether changes to the 6.8.x branch
> > require approval or merely must follow guidelines. If each change needs
> > to be approved by the release manager or committee before being made,
> > then a Bugzilla entry is necessary for tracking. Personally I would
> > prefer a model of the person responsible for an area being able to use
> > their judgement on when a particular fix fits into a clearly specified
> > set of guidelines on what is appropriate for the stable branch. Gray
> > areas would be referred to a wider audience for discussion.
> 
> I think this could work, and in any case I think it's worth giving it a
> try.  Those that have an interest in the maintenance branch should watch
> the commits and speak out if they don't agree to a patch being
> committed.

Uhm... is it really neccesary to repeat the same kind of mistake with
the backout chaos in the last cycles of the X11R6.8.0 release ? I would
really like to avoid such mess. If patches get commited they should stay
commited. And not being backed out 5 minutes before 12h and then
recommited again in a slightly modified form. And I'd like to have
simple, strict, written rules with no exceptions (not even for the
release manager).

> People committing should apply fair judgment and only commit
> simple bug fixes, and post bigger patches to this list.

Then there is still zero control over what goes in into the stable
branch and what not. Remember that the commit-diffs mailinglist is dead
since a while - which means the only way to review changes after commit
is to fetch them file by file from CVSweb.

What about:
1. For all code which has an (module) owner the owner can decide whether
he/she makes pre-commit approval by the release manager mandatory or not
(on a per-file or per-directory basis - which has to be annouced here by
the module owner _before_ commits under this rule are made).
2. All unowned code requires pre-commit approval by the release manager
3. The release manager cannot approve his/her own patches (unless he/she
is module owner, then [1] can be applied), either the release-wrangers
list has to discuss and approve the patches or a 2nd release manager
needs to be named to do the approval in those cases
4. If the release manager is unsure whether a change is too risky,
usefull etc. he should be allowed nominate two or three persons (which
means: experts for the matching code) who can decide whether the change
should go "in" or not (the release manager still has a general veto
right) (for example the MESA changes would fall into that category - I
am not an expert for those changes so I would ask the MESA gurus whether
they think that a patch should go "in" or not.).

Is that OK so far ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)