[haiku-development] Re: alpha release window ?
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 10 Aug 2009 12:13:55 +0200
Hi,
2009/8/10 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>> On 2009-08-07 at 15:22:34 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
>> > wrote:
>> > Since Philippe seems to be MIA, and we should go forward with this
>> > at
>> > least with some pace, I would volunteer to take over this job,
>> > although
>> > I will probably be short on time over the next few weeks.
>> Since you volunteer for the job, you probably also have an idea what
>> tasks
>> and privileges of our Release Coordinate entail. I would be delighted
>> to be
>> told. :-)
>
> Not that I would have any idea, but this is what I thought I would have
> volunteered to do:
> - collecting a list of all the things we need to do
> - making a schedule for these things, too
> - finding people who are willing to take over responsibility for some
> things
> - adjust and update the schedule as needed, trying to be vocal about it
>
> Since this is going pretty slow, I guess September 1st might indeed be
> too tight, but I had hoped you would be here to be part of this, too :-
> )
> The alpha release should also be a test bed for later actual releases,
> IMO.
I want to offer my assistance to help run the non-code part of this
release as I guess your time would be better spend trying to polish
the alpha :)
As for my experience with release managers in another open source
project (KDE), the release manager is a temporary chosen dictator (the
benign one), who's sole responsibility it is to make a release happen
in a proper fashion meaning:
- the code is in good shape
- the marketing cogs are spinning
- the distribution of the software is well-taken care of
At KDE the release manager was in charge of things like the schedule
and coordinating the web/marketing teams. I don't remember the
coordinator explicitly meddling in with developer decisions (the
coordiinator was always a respected developer and he usually voiced
his opinion in this role), but I do remember that he had a sort of
(unofficial) veto power when it came to changes that might threaten
the stability of the imminent release.
>> > So, without further ado, I would propose August 15 as code freeze
>> > (no
>> > changes are made other than bug fixes, testing is intensified), and
>> > September 1st as the actual release date. I would also propose
>> > to branch the release only after the actual release, since I guess
>> > everyone should be able to work on this, and only on this for two
>> > weeks
>> > straight.
>> -1, if everyone would be able to do that, we could as well branch
>> first and
>> everyone could work in the branch. In the likely event of people also
>> working on different stuff, creating a branch is mandatory.
>>
>> That aside, let me reiterate a point I already brought up months ago:
>> An
>> alpha release of a software is a not fully feature complete pre-
>> version
>> that is known to be buggy to a certain extend.
>
> IOW an alpha release is usually not worth making a freeze at all. I
> think the way we're developing now (actually using trunk to develop on)
> keeps the current version mostly stable, and in good shape for alpha
> releases. I am not really aware of any problematic work that is not
> already in a branch, anyway.
>
> This is, btw, what OpenBSD does for all their releases, but I guess
> it's more common for them to develop certain things completely outside
> of trunk.
I would propose to have a freeze nonetheless. If we have a
feature-freeze (for 1-2 weeks) I would like to see if we can get all
developers in bug-fixing mode (to test the effectivity of that).
I will propose a release schedule in a new thread.
Kind regards,
Niels
Other related posts:
