Xfce development and release model

[Brian J. Tarricone]

Jannis Pohlmann wrote:
>> So, without further ado, here's the document:
>>
>>   http://wiki.xfce.org/releng/release-policy
>
> Oh, yeah, and please, please, please give comments and feedback!

-ETOOMUCHTEXT  ^_~

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 
bike-shedding.)

Some questions/comments:

* 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 
release.

* Planning phase:

1.  What happens if a maintainer doesn't have time to finish all the 
features planned?

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.

	-b