Are we doing a X11R6.8.x maintaince release ?

[Kristian Høgsberg]

Mike A. Harris wrote:
> Jim Gettys wrote:
> 
>> Nothing is planned, at least at the moment.  If a suitably 
>> motivated individual wanted to do one, I expect we'd be happy to 
>> see it happened (most of our current effort is oriented toward a 
>> more significant release early next year).
>> 
>> Security updates will, of course, be generated as needed. - Jim
> 
> 
> I've talked with various others, and there is a strong sentiment to 
> see the XORG-6_8-branch updated with bug fixes, so that over time 
> additional point releases can be made.  Of course for this to work 
> well, the additional work to maintain this branch into the future, 
> and to perform the release engineering would require additional 
> volunteerism, and it would seem reasonable to expect those who want 
> the branch to be maintained to do this extra work.

To elaborate a bit, internally at Red Hat, we've been discussing the
possibility of using the XORG-6_8-branch for bug fixes, that is, as a 
stable branch.  As an X.org distributor, Red Hat keeps a number of bug 
fix patches that we apply to the latest release when we build it, and 
most other distributors do the same.  The motivation behind this 
proposal is to pool the maintenance work done by distributors and 
collaborate on maintaining a stable branch of the latest release.  This 
would benefit all distributors as well as users compiling X.org 
themselves. Ideally, distributors should only apply distribution 
specific patches, bug fixes should be upstream, available to everybody.

The overall idea is to take a pragmatic approach, and adopt a 
conservative policy for accepting patches.  If a patch proposed for the 
stable branch is controversial in some way, we would not include it in 
the stable branch.  I don't think it will be possible to set up strict 
rules for what kind of patches should be accepted or not.  Each case 
will be a judgement call, but I'm optimistic that there will be a large 
body of simple fixes that can be applied and that disputes will be rare.

With the shorter release cycles we now have, I think that a strict 
bug-fix-only stable branch could work, since there will be less pressure 
to get feature patches into the stable branch.  Distributors will of 
course still be able to apply rejected patches to their builds if they 
so choose.  Another way to think of this is that the stable branch 
should be the intersection of the patch sets the various distribtors 
apply, as opposed to the union of the patch sets.

Proposed guidelines for maintaining the stable branch:

  - Each bug fixed in the stable branch must have a corresponding
    bugzilla bug.  The ChangeLog entry must reference the bugzilla bug.

  - For each point-release there must be a tracker bug.  Every bug
    fixed on the 6.8 branch should be added as a dependency of the
    currently open tracker bug.  This will make it easy to track what
    exactly has been fixed, and will be a big help when preparing
    release notes for the release.

  - When fixing a bug in the stable branch, the bug must be fixed in
    head as well; it doesn't need to be the exact same patch of course
    (and indeed, that may not be possible), but we should work to make
    sure that there will be no regressions from the next major release
    to the latest point release.

  - There should be no obligation to commit a fix to the 6.8 branch
    when comitting to HEAD.  This is encouraged and appreciated, of
    course, but the motivation here is that mainly the distributors
    benefit from the stable branch, and thus, they should take on the
    work.

And as discussed elsewhere on the xorg list, the version numbers for the 
maintenance releases would be 6.8.x for releases based on the 6.8.0 
release.  Specifically, the next maintenance release would be 6.8.2.

One question that remains is when to ship a maintenance release. 
Obviously, if a security issue comes up, a release should be made to 
take care of that, but the hope was that we could release a maintenance 
release once in a while, even when there is no immediate reason to do so.

Let me know what you think,
Kristian