Xfce development and release model

[Jannis Pohlmann]

On Thu, 28 May 2009 12:59:32 +0200
Nick Schermer <nickschermer at gmail.com> wrote:

> 2009/5/28 Brian J. Tarricone <bjt23 at cornell.edu>:
> > 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.)
> 
> I'd prefer this, commit in master test it a bit (buildbot) and then
> cherrypick into the stable branch. (Ofcourse only if the bug applies
> to master, code could have changed in master by a feature branch).
> 
> >> - 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.
> 
> But a maintainer is also allowed to do independent releases, so assume
> I'm releasing a devel version of the panel for a new experimental
> feature that needs testing, then I don't want that to show up in the
> pre or final release.

Don't release then. Only release what's finished (I'd even say only
merge into master what's finished) and what you really want to be part
of the next release.

> >> - 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.
> 
> O yeah sorry, misreading. I now get the code-freeze thing.

Cool. Another thing about the code freeze: I could imagine that it
would be nice to have a special permissions hook script for code freeze
which only allows commits signed off by the release manager. It's
really easy to implement and could keep us from becoming sloppy and
less strict about the code freeze.

I've added this to the document: "The code freeze and its exceptions
are supported by commit hooks. There is an update hook which doesn't
allow any changes to master unless they are signed off by the release
manager."

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