Xfce development and release model
Brian J. Tarricone
brian at tarricone.org
Thu May 28 06:41:15 CEST 2009
Jannis Pohlmann wrote:
>> So, without further ado, here's the document:
> Oh, yeah, and please, please, please give comments and feedback!
Seriously, though... this looks really well thought-out. When I read
the bit about the ELS, I was a little hesitant, but it makes sense.
We've never really done a proper code-freeze before, and that's
definitely made the release process harder on the release manager at times.
Personally, I'd probably rearrange that to eliminate the ELS branch
(branch xfce-x.y at code freeze, xfce-x.y only gets i18n updates, final
release is tagged from xfce-x.y, and master gets bugfixes, which are
merged into xfce-x.y after final release). But with that setup you have
to commit i18n updates to both master and xfce-x.y between code freeze
and final release. So it's really one thing or another: either you have
an extra branch to worry about, or you don't have the extra branch, but
you have to check i18n updates into two branches at once for a little
while. I guess since git branches are so easy, the extra branch method
is probably easiest to keep track of overall.
(I think "Early Lifetime Support" is a kinda silly name, but that's just
* Core components:
1. I know this is a touchy subject, but I think we should get this out
of the way sooner rather than later.
2. Non-core components are of course free to "play along" with the
release process and time their major feature release with an Xfce x.y.0
* Planning phase:
1. What happens if a maintainer doesn't have time to finish all the
2. What happens if a maintainer "under-plans" and has time to add
features thought of after the planning phase is over?
3. What happens if a maintainer isn't available for the planning phase?
Certainly we can work around the expected things (like vacations,
business trips, and exam periods), but most/all of us have other
jobs/lives outside Xfce and it's possible that things might come up that
could take us away for a week or more.
* Development phase:
1. What happens if components A and B depend on component C, and
component C is going to have an API break during development? Say the
maintainer of component A does a release to use the new API at the same
time component C gets released, but the maintainer of component B is
unable to for whatever reason. How do we handle this? (Ideally all
dependencies allow parallel installs of incompatible versions, but I
don't know if we can rely on this, esp if component C isn't an Xfce module.)
* Release team:
1. What happens when we can't find enough people to do all these jobs?
(QA Official might be difficult; it's a thankless job that isn't
really interesting or fun.)
* Blocking bugs:
1. Might want to discuss what happens if a blocker can't be resolved in
a timely manner. Do we try to back out the entire feature that we think
might be causing the bug? What if a bisect puts the offending commit
*very* far back in the history such that backing it out is difficult?
(Ideally this wouldn't happen; one would think that a bug bad enough to
be a blocker would be noticed soon after it enters the tree.)
* Maintenance process:
1. If maint releases are required to be API/ABI stable, are we
encouraging major feature releases to break API/ABI? At least since
4.0.0, the only ABI breaks have been unfortunate accidents that we
couldn't fix after the fact.
That's all for now, I guess.
More information about the Xfce4-dev