On Fri, Jul 8, 2011 at 11:22 PM, Sam Spilsbury <[email protected]> wrote:
> Hi Everyone,
>
> I'd like to propose a new set of rapid-release milestones for the
> Compiz project over the next few months for the upcoming 0.9.6
> release. The reason I'm doing this is to create a more stable
> environment for prospective contributors and a more stable environment
> to work from for distribution packagers. Our current model in the 0.9
> series of "release when its ready" isn't working out for us because of
> the rolling nature of the way bugs are being fixed and features are
> being added. With a structure which focuses on a series of smaller
> milestones we'll be able to better priorities what we want to do and
> give ourselves more time to maintain those fixes and make sure there
> aren't any regressions.
>
> So without waffling on too much further, here are the dates and
> release version numbers I'd like to propose. If nobody has any serious
> objections to these dates, I'd like to set them and stone and move on
> from there since the dates aren't really as important as the
> procedure:
>
> 0.9.5.0 - 12 July 2011
> 0.9.5.2 - 26th July 2011
> 0.9.5.90 (beta1) - 09 August 2011 - FEATURE FREEZE
> 0.9.5.92 (beta2) - 30 August 2011
> 0.9.5.94 (rc1) - 13 September 2011
> 0.9.5.96 (rc2) - 20 September 2011
One small correction: This should be 0.9.6 and 0.9.7.0 respectively
> 0.9.5.6 (final) - 27th September 2011
> 0.9.5.7 - 11th October 2011 (All new features get merged in)
>
> The point is with these milestones that the most disruptive changes go
> in at the beginning of the major cycle and don't go in at the end of
> it. Which means that changes which are more likely to have
> far-reaching effects are not going to be merged in when we're in a
> critical area. So, eg, we're not going to allow features past feature
> freeze, bugfixes which change a lot of code past beta2 are not going
> to go into that release series etc. I'd also like to target particular
> bugs for releases so that people know what the priorities of the
> project are and what people can help out with if they're interested in
> helping out.
>
> For each subcycle, I'd like to propose something similar to the following:
>
> First of all, we make a git branch for that release series, eg
> compiz-0.9.5.0 . All work for that subcycle happens in master, which means
> that people who prefer to run from git can just checkout the latest
> micro release
> branch (we can consider whether to make this the default ref) and aren't
> potentially running broken code.
>
> First 5 days of the cycle are when features and bugfixes for targeted
> things get merged in. Ideally those will be going through a pre-commit
> code review, but I think that for now we will just allow people to
> commit to a series and revert their commits if they are causing
> problems or don't make sense (obviously with explanation of *why* that
> happened which would be very very very rare, because ideally we'd have
> enough time to fix problems before the target). Then we open a call
> for testing on that series and fix the problems that those merged in
> fixes or features are causing or revert them if they are causing too
> many problems. By the next 5 days, we do a release, merge that branch
> into master, tag it, do the release mail and open the next sub-cycle
> series.
>
> This has the run-on effect of encouraging people who are doing big
> items of work to work in separate branches, polish their features or
> bugfixes and then merge it in on each sub-cycle merge window, rather
> than working directly on master.
>
> As for the infrastructure work, I've recently merged in the cmake work
> necessary
> to make releasing as easy as possible, now every single module has a VERSION
> file and can also be built with CMake and every single module has the
> following targets:
>
> * release-prep: updates AUTHORS, ChangeLog, NEWS
>
> * distcheck: creates a .tar.bz2 archive of the current HEAD which can be sent
> out for testing during the call for testing of the release, builds it, runs
> make test (for unit tests)
>
> * release-signoff: applies the changes to AUTHORS, ChangeLog, NEWS to HEAD,
> and commits them, tags this commit as the "compiz-${VERSION}" release, creates
> a branch from this commit called "compiz-${VERSION}-series",
> creates a file called RELEASED with the contents of VERSION, commits that,
> re-creates the tarball of HEAD, asks for a new VERSION, signs and
> sha1's the tarball
>
> * release-push: actually pushes the created branches, tags and objects
> to the upstream git repository
>
> * release-upload: actually uploads the signed tarball to releases.compiz.org
>
> Obviously, release-push and release-signoff can't just be run by
> anybody, you must have access to releases.compiz.org and
> git.compiz.org and the repo in order to use it.
>
> If nobody has any objections to this, then I'd like to set the date
> for the next release to be 12 July 2011 and consider this process to
> be effective from that date
>
> Regards,
>
> Sam
> --
> Sam Spilsbury
>
--
Sam Spilsbury
_______________________________________________
dev mailing list
[email protected]
http://lists.compiz.org/mailman/listinfo/dev
