Xfce development and release model

[Stephan Arts]

On Thu, May 28, 2009 at 6:41 AM, Brian J. Tarricone <brian at tarricone.org> wrote:
> 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?

Then the feature doesn't get merged, we release, and it will probably
enter the next X.Y release. You simply can't force people to work on
things they don't have time for. And since we can't anticipate when we
are going to have time, having partially finished code in a branch is
less of a problem then having it in master. (like what used to happen
with svn-trunk)

>
> 2.  What happens if a maintainer "under-plans" and has time to add features
> thought of after the planning phase is over?

That's really up to the maintainer, he can implement the feature in a
branch, and decide if he wants to merge it before the feature-freeze
or let it rest there until after the X.Y release. Personally, I prefer
the last approach, because we have seen the occasional 'ooh, this
feature should go in too' last-minute breakage... And with a tight
schedule, it is not a real problem if it doesn't get in, with 3
releases in 2 years, that feature will be released sooner then it used
to anyways ^_~


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

We could have a 2w 'transition-phase' where, in case a developer
wasn't around during the planning-phase, he can still propose a
different set of dependencies based on the features he wants to
implement.

If no consensus is reached, or these 2w have passed. The feature
should be optional, like we have sound-settings now, which only work
with libcanberra+gtk2.14.


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

If one of us is the author of C, then we can anticipate the breakage,
reducing the risk of a useless component B. If we are not the author
of C, then there is probably little we can do about it. But the same
is true today, if someone breaks GTK+ or D-BUS, we're screwed.

-
Cheers,
Stephan