X11R6.8.2 maintenance release plans and call for comments.

[Kristian Høgsberg]

Roland Mainz wrote:
> 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@@@@!!!... ;-(

This particular patch was applied to HEAD, and I don't think we have any 
requirements that all HEAD commits must have a bugzilla reference, and I 
don't think we should have one.  That said, there actually is a Red Hat 
bugzilla entry for this problem, it's

   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77045

and yes, it would have been nice if that link was in the ChangeLog 
entry.  I'm not familiar with the details, but if you could describe the 
specifics of the problem in a mail to the xorg list I'm sure Søren will 
reply.

> 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.

That's also fine with me for the 6.8.x branch, that's what I had in my 
original proposal.

>>>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).

I think the unfortunate situation with 6.8.0 came about because people 
did not pay attention to what was being comitted when it was comitted. 
If people had been watching the commits, we could have had the 
discussion in good time and resolved the issue much better, I'm sure.

>>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.

Right, good point, if the commit-diffs list cannot be restored, there's 
no way this could work.  There need to be a way to monitor and review 
commits, and viewcvs doesn't cut it.  I'm thinking that the bugzilla 
mechanism you proposed is probably the best way to go then.

> 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.).

This sounds like a reasonable approach, however I don't think we need to 
write down firm rules for this, it's basically common sense.  And with 
the bugzilla mechanism the actions of the release manager are easy to 
follow and revert, should that become necessary.

cheers,
Kristian