Re: Xfce development and release model

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
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev