Xorg 7: The new world order
ajax at nwnk.net
Thu Dec 22 11:37:45 PST 2005
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.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg