Xfce development and release model

[Jannis Pohlmann]

On Thu, 28 May 2009 03:43:39 -0700
"Brian J. Tarricone" <bjt23 at cornell.edu> wrote:

> On 05/28/2009 02:33 AM, Nick Schermer wrote:
> > Few notes/questions:
> >
> > - In the branch image there is 'No change', looks a bit weird. You
> > can still commit bugfixes and translations in master while working
> > in a feature branch right?

That's just an example. The Feature2 branch is just a short lifetime
branch while there are commits made to master during Feature1. 

> That raises another question: do we have (or want to have) a bugfix 
> policy during development cycles?  Should:
> 
> 1. Bugfixes first be checked into master, and then be pushed out to
> the xfce-x.y branch after testing?  (Only viable if master hasn't
> diverged too much from xfce-x.y.)

I think I prefer this one. Usually, small fixes are only committed if
they seem to actually *fix* the problem. But in case of more
complex fixes, a bit of testing before merging it into the stable
branch can't hurt.

> 2. Bugfixes be checked into both master and xfce-x.y (assuming they 
> apply to both) at the same time?
> 
> 3. Bugfixes be checked into xfce-x.y only (assuming that bugs are 
> reported against the stable release), and then periodically merged
> into master when convenient?
> 
> This might just be "maintainer's preference," but it might be useful
> to discuss pros and cons of the various styles.

Yeah, agreed.

> > - There is, 'The release team always picks the latest available
> > development release of each component for pre-releases and the final
> > release', should be latest stable release I guess?
> 
> No, I think that's right... we're talking about gearing up for a new 
> xfce-x.y.0 feature release.  The pre-releases for that should come
> from devel releases (which are made from master), since that's what
> will get released as xfce-x.y.0 final.

Yep, it's correct. I changed it to "Each of these releases has to
include the latest development releases of all components (or stable,
if there were no development releases since the last stable release) of
the Xfce core desktop."

> > - I'm not really a fan of the ELS branch, personally I would prefer
> > a small period after the final tag where only bugfixes and
> > translation updates are allowed, like we did with Xfce 4.6.0 ->
> > 4.6.1, then create a stable branch from the 4.6.1 master.

I don't really like that. I don't feel like pausing the entire
development for two or more weeks (in case there are any blockers) just
because we don't branch earlier.

> Well that's something else entirely...  what you propose is to do
> away with the code freeze entirely.  The idea of ELS is to collect
> bug fixes while master is in code freeze.

Yep, exactly. It's a very nice way to work on fixes in parallel to the
release being performed (possibly by someone else).

> > - Maybe mention the buildbot somewhere, which monitors the master
> > branch all the time. Maybe even an (unofficial) rule that no feature
> > branches are merged in master while the buildbot reports a broken
> > master (fix before you continue!).
> 
> Yeah, good idea... heh, though I wonder how useful it is for the 
> buildbot to only monitor master.  Seems like it's going to be doing a 
> lot of busywork since master should remain mostly untouched (aside
> from bugfixes) during dev cycles.  The only time master gets any
> changes that are probably worth build testing are when a feature
> branch gets merged in.  It might be nice to monitor feature branches
> while they're being worked on in order to catch issues earlier.
> Dunno how feasible that is, though.

Hmmm, maybe. I think I'd prefer to just let it build master because
that's what we're using for releases and the 10 weeks release phase
should be more than enough time to fix compile issues reported by
buildbot.

  - 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/f2cd31e7/attachment.pgp>