[haiku-development] Re: R1/A3 -- Third Time's the Charm(?)

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 23 Jan 2011 21:51:35 +0100


On 23 January 2011 16:57, Matt Madia <mattmadia@xxxxxxxxx> wrote:
> Since entering the Beta stage is not in the near future and a possible
> Google Summer of Code 2011 is approaching, could we release another
> alpha?

Great idea!

> The last R1/A3 thread was back in Nov. [1]
> Summing up that thread, here are the components that may raise concern today:
>  * Locale Kit / ReadOnlyBootPrompt
>  * print_server crashing on shutdown (status?)
>  * CD read errors while installing (was mentioned on [haiku]) [2]

I have taken the liberty to upgrade  #5786 - ReadOnlyBootPrompt to the
'blocker' status. I have moved #6723 (CD problem) to R1/alpha3 and
made it a blocker. The print_server issue was resolved in r39685 (see

> As noted in the first thread [1], here's the bare minimum for doing a release
>  * Adjusting versioning to R1 alpha 3 (r36348)
>  * updating gcc to r1a3-version (r36378)
>  * disable serial debug output (r36721)
>  * enable HAIKU_OFFICAL_RELEASE (r36768)
>  * user guide (r36743, r36744)
>  * rebuilding pre-built packages used in the build system

Who is going to manage this release? And will we have the same person
doing the dev and non-dev tasks of getting this release out of the
door? Or will we split the tasks? I am available for the non-dev

> Here's also some snippets from Ingo, which are worth repeating: [4]
> ---
> IMO filtering what goes to the release branch through a single person is a
> good idea, as that allows to implement a simple policy and prevents
> misunderstandings. AFAIK that's also how other bigger projects handle
> releases.
> * The reviews took a lot of time. So either we drop the review idea
> completely or at least we don't require reviews anymore. A patch could
> have, say, three days for a review to be made and, if none happened, the
> decision whether to commit it to the branch or not would be made anyway.
> This way unreviewed patches wouldn't be pending for a long time and the
> pressure on the release branch manager to do most of the reviews would
> lessen.
> * There should be a longer branch life time with a stricter merge policy.
> Like two weeks with only small changes and two more weeks with only very
> small cosmetic changes or changes that fix serious issues. This would give
> the almost final version a lot more time for being tested without risking
> significant regressions at the same time.

I don't completely understand why we need such a strict review policy.
I think that we could try to have committers mark a changeset
themselves for inclusion in the alpha. We can publish some simple
guidelines to help them determine whether it is up for inclusion. The
inclusion itself can be marked using keywords (like +alpha3 or
-alpha3; perhaps a ?alpha3 if unknown). If the keyword is not present
in the log message, the commit is rejected (with an error message that
prints these guidelines). The release manager will have a final say
over the changeset.

This might be an improvement over the situation where there was a lack
of interest in reviewing changesets.



Other related posts: