Xfce development and release model

[Brian J. Tarricone]

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

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.

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

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

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.

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

	-b