[Xfce 4.8] Improving the Release process

[Jannis Pohlmann]

Hey,

On Mon, 2 Mar 2009 11:14:30 +0100
Stephan Arts <stephan at xfce.org> wrote:

> One of the problems Olivier rightfully adressed during the
> release-process of xfce 4.6 was that a 2 week window between releases
> is too small. By the time we release a new version, the bugreports on
> the old version have just started to enter bugzilla. Then we have no
> time to fix those issues and users get the impression that no progress
> is being made. Both results makes you wonder why we released in the
> first place. To solve this in the future, I'd like to propose a 4 week
> minimum between releases.

Agreed. But if we do that, we need to cut down on the number of
pre-releases. If we do as many alpha, beta and RC releases as we did
this time, the release alone will take six or seven months which is
something we don't want. Given a 9-10 months cycle that would give us
only about 2-3 months for adding features. 

With extensive use of branching for new features that might be ok, but
I'd still favor a bit more time and a shorter release process (more
like 4-5 months).

> Second, releases were delayed time and time again for several reasons.
> First, we had the xfconf migration. Now, this was a big change, and it
> took quite some time to get it right... so lets not make a big deal
> out of that. Then, everyone had his 'pet' bug that was too important
> to have in a release. By doing releases more often, 'pet' bugs should
> not be an issue. 

The key to a better release process is to think about what the major
issues in the last release cycle were. Doing the relases was painful
and we should find a way to improve this but what actually caused all
of our problems was that new features delayed the release for months.

So we have two things to discuss: 

  1) How do we avoid major changes to the code base to affect/delay the
     entire release? How can we meet deadlines?

  2) How often and in what way do we want to perform releases in the
     future?

1) is mostly a question of how to utilize the source control
management infrastructure to make releases less dependent on changes
to the codebase. 2) is mainly a question of responsiblity and time
management.

Here are my answers to the two:

  1) To make the release less dependent on changes in the code, we
     should try to keep trunk (I'll call it master from now on) ready
     for releasing all the time. Whenever you work on something, create
     a branch (local or public) and only merge it back into master when
     it's somewhat stable and only waiting for bug fixes. (Same goes
     for strings added along with code changes: only merge back into
     master if they meet our quality requirements.) 

     With master meeting these criteria, we can pick it up for release
     any time without having to wait for features to be finished.

     Personally, I think that if we don't know how to meet deadlines,
     discussing release schedules is pointless. The above approach
     could be what we need.

  2) Once the the problem of meeting deadlines is solved we can think
     about how our release schedule should look like and how we want to
     distribute the responsibility for releases.

     I'd be fine with a release cycle of about 9-10 months. I'd also be
     fine with doing a release almost every month. For that to work we
     need to decide on how to distribute the release effort among the
     team. We've mentioned the idea of making each maintainer
     responsible for uploading the tarballs, NEWS, ChangeLogs etc. for
     his components and I think that's the way to go.

     IMHO we have to define the number of release candidates or
     pre-releases prior to entering the release cycle. If we say "we'll
     do as many RCs as the code needs to become stable" we won't be
     able to keep up with the schedule. But again, 1) could solve this
     problem.

> By releasing Alpha's and Beta's more often, each
> release is less of a milestone by itself. Making it less troublesome
> to release development versions that have bugs. We sometimes seem so
> committed to do 'perfect', that we are blind for the 'good enough'
> state we currently have.

I'm curious about how doing alpha/beta releases more often could work
together with having a longer time distance between the releases.

> Then we come to the labels, which indicate the maturity of the
> project. We are all familiar with ALPHA, BETA and Release Candidates.
> With 4.6, we did 1 ALPHA, 3 BETA's, 1 RC and 1 Final Release. All of
> these were predefined. I think we can say that this did not work out
> very well. As a different approach, release anyway. But if it is not
> BETA quality, just release another ALPHA. Releases makes people
> excited, why withold bugfixes just because we'd rather release it with
> one more fix. And when we know the next release will be done next
> month, and does not necessarily have to be a RC, this is not really a
> big deal anylonger.

I don't really get how that works together with having a predictable
release schedule. Distributions need that.

> When it comes to the labels. I want to make that easy. Feature-freeze
> when we start the BETA's, and String-freeze when we start doing RC's.
> With a minumum 4 to 6 week period between the first RC and the final
> release. I think the translators plenty of time to update their
> translations.

Fine with me.

> Now, back to the 'general' release schedule... with this approach we
> can not say when 4.8.0 will be ready (at least not in during the
> following weeks). So it would mean going somewhat back to the 'old'
> release when its ready approach. But, I believe that this way, 4.8
> might be ready sooner and it will be more fun to work on the
> development. (More releases, more feedback, more fun :-))

I strongly vote against "release when it's ready". It would add much to
the advantage of Xfce if we had a predictable release schedule.

But before we can have that, we need to figure out 1) IMHO. And that
means to prepare the move to a DVCS.

Cheers,
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/20090302/77c65829/attachment.pgp>