Xorg 7: The new world order

[Adam Jackson]

On Thursday 22 December 2005 02:21, Kean Johnston wrote:
> If you can precis what exactly the RM job will entail I'd be
> interested in stepping up to the plate.

Good question!

A lot of this will depend on the style of the RM themselves, but I think 
there's some themes we can identify here.  From sort of the management level, 
it looks like:

- Set a schedule
- Compile the set of appropriate fixes
- Manage marshalling them into the tree
- Establish a testing process
- Press release, wiki updates, etc.

Scheduling is something of a black art.  Since the stable branches are 
probably going to go into updates/service packs/etc. for the different 
distributors, there may be a common timeframe that works well for the 
majority of the interested parties.  The RM will probably need to figure that 
out, which can be tricky since those schedules aren't always public 
information.  The advice I'd give here is pick one and stick with it, and if 
that means rejecting some patches or being inconvenient for someone's 
schedule, oh well.  Distro versions are always going to diverge anyway.

The usual approach taken for stable series' is that if there's not a patch 
around to address the problem, then it's not serious enough to try to fix in 
the stable tree.  For 6.8.2 we did a lot of diff reduction relative to the 
various vendor trees.  Debian, Red Hat, SuSE, etc. all had long lists of 
patches they applied to their released versions, and many of them had been 
shared back and forth over the years, so those sorts of fixes went in without 
much contention.

So the hard part is determining what sorts of changes are sufficiently 
low-impact for a given release train.  Security updates pretty much always 
qualify, as do fixes for crashes, nonconformance, etc.  Device support is a 
bit of a gray area, it sort of depends on how much impact it would have on 
the rest of the tree.  Personally I'd say 6.8.x shouldn't be seeing any new 
device support, and 6.9 should only get new device support if adding it is a 
matter of just adding the PCI IDs, but I'm hardline like that.  Again, some 
politics here to work out what's acceptable to all the players.

You'll need some sort of workflow for getting these issues tracked and merged.  
My suggestion would be to use the patch approval flags in bugzilla, with 
unique bug IDs for each bug (ie, not the same bug for both HEAD and 6.9.1).  
Bugzilla 2.20 has a lovely "clone" feature that makes it easy to take an 
issue relative to one release train and retarget it at another one, and I'd 
like to get 2.20 installed in the next month or so.  In the absense of that, 
just open new bugs pointing back at the original one, either in the URL field 
or in the initial description, with the Milestone field set to 6.8.3 or 6.9.1 
(if the appropriate milestone doesn't exist, poke me and I'll make it exist).

To avoid regressions, all patches (or their moral equivalent if the 
implementation has moved) should be applied to all the later branches first.  
This means nothing in 6.9.1 until it's been fixed in the appropriate new 
world module, and nothing in 6.8.3 until it's been fixed in 6.9.1.  Again 
this sounds harsh, but it should serve to keep each train successively more 
conservative.  This probably means doing 6.9.1 before 6.8.3, which I think is 
fine, no one's been pushing too hard for 6.8.3 yet.

So much for tracking.  6.8.2's merge process was that Roland was the only 
person allowed to commit.  I don't think that scaled very well, personally.  
I would prefer to have a known stable team for each release, and as various 
bugs get approved by team decision they get assigned to whoever's free.  
Again, style issue, you might have a better process.  If you want to enforce 
gated commits we can probably hack that into the commit_prep script, but I'm 
of the opinion that social pressure works better there.

The testing process is still up in the air, even for 7.x.  I would suggest 
something along the lines of comparing xts5 results from the .0 release 
against those of the branch, with xts5 being considered a moving target (ie, 
as tests get added, update the results profile of both the .0 release and the 
tip of the branch).  We really need to start expanding the test suite to 
cover both the bugs we fix, and the larger code profile of R6.9 relative to 
R5 (Render and such).  If I were being really hardline about it, I'd insist 
on a testcase in xts5 for all non-hardware bugs before the commit could be 
approved, but that's probably insane.  But again, this is social, figure out 
what level of assurance all the players require to be comfortable with the 
release and work towards that.

Doc updates should be more or less mechanical by now, kem and alanc can give 
more detail on what's required for that.  Personally I'm not completely clear 
on how we go from the SGML source to HTML/PDF/whatever else.  Wiki updates 
are mostly about finding all the mentions of that release train and adding a 
link to the description page for the next one.  I don't know that stable 
branch releases really warrant a press release, they should be utterly boring 
events, but PR is so very not my thing so feel free to do one if you want.  
Leon has handled that for all the Xorg releases since at least 6.7, so he'd 
be the guy to talk to.

I don't know if that answered your question or not, but hopefully it helped a 
little.  If there's anything I left out please let me know.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20051222/bb8edfb8/attachment.pgp>