Xfce development and release model

[Jannis Pohlmann]

On Wed, 27 May 2009 21:41:15 -0700
"Brian J. Tarricone" <brian at tarricone.org> wrote:

(snip)

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

This is addressed in the current state of the document (see my other
mail).

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

I added the following paragraph to the development releases section, I
hope that is more clear:

"New features breaking APIs or other core components should be
communicated. Maintainers are suggested to prepare other components for
these features in a separate branch before including the features in a
new development release. That way the other components retain their
release-ready state."

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

Only release manager and QA Official are mandatory. But I doubt we'll
have any problems in finding people to help out with the website or
other little jobs as release assistants.

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

I'd say that's about the only situation where a blocker could delay a
release.

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

I've changed that the description to say "there may be no API/ABI
changes in maintenance releases compared to the corresponding final
release of the Xfce core desktop."

Of course there may be functions added to libraries in development
releases. Dunno if that was what you were referring to.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20090528/e64e0026/attachment.pgp>