X11R6.8.2 maintenance release plans and call for comments.

[Kristian Høgsberg]

Torrey Lyons wrote:
> At 5:21 PM -0400 10/26/04, Adam Jackson wrote:
> 
>> Content-Type: multipart/signed; boundary="nextPart2014852.bJrVRQmWj7";
>>     protocol="application/pgp-signature"; micalg=pgp-sha1
>> Content-Transfer-Encoding: 7bit
>>
>> On Tuesday 26 October 2004 15:13, Jim Gettys wrote:
>>
>>>  Kristian, Donny, Torry, Mike, Roland, Daniel, Alan and Leon have been
>>>  discussing details of stable release policies in the Release Wrangler's
>>>  list; we need to strike a good balance of convenience vs. rigor here.
>>>  A serious strawman of policy was written by Kristian here:
>>
>>  > 
>> http://freedesktop.org/pipermail/release-wranglers/2004-October/001070.html 
>>
>>
>> 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.

> 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. People committing should apply fair judgment and only commit 
simple bug fixes, and post bigger patches to this list. If this turns 
out not to work, we can still go back to requiring pre-commit approval.

cheers,
Kristian