[haiku-development] Re: Proposal: Release Schedule
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 10 Aug 2009 15:31:07 +0200
Hi,
2009/8/10 PulkoMandy <pulkomandy@xxxxxxxxx>:
> I don't really agree on this.
> If you look at the bugtracker, there is almost no bug left in the
> R1/alpha list. And it's an alpha, so there is no need to fix all bugs
> in the R1 milestone now. Just tag the trunk as it is now as "alpha",
> package it and release it. Of course, by waiting a week more you will
> have more bugs solved, but then, by waiting another one you'll get
> even more and so on. So just leave them as is and release this alpha
> version.
I would agree that a 'normal' alpha could be a random svn tag, however
there are two unique aspects about this situation: #1 is that this is
our first release and there is a large anticipation, and #2 is that we
do not have any rigid way to test the images. Because of #1, we should
not randomly sling a release into the air and see whether it will
stick.
Big paragraph below. I am going to respond in pieces.
> I think the code is ready for an alpha. (...)
1. To a large extend yes. But as I mentioned above, there is a good
chance it will get a lot of exposure. In that sense it cannot hurt to
polish it a little bit (more than you would usually do for an alpha).
It is also a chance to create a release infrastructure.
> All the big work is already done
> in branches (tracker refactoring, locale kit, gallium, ...). So the
> Haiku source tree switched to a release schedule on its own without
> any coordinator driving it.
2. I hope to think that one of the driving forces of this
self-regulation has been the voting for the proposals a few months
back. [1]
> As proposed, wait for the end of GSoC so
> the mentors (and students) get more time to work on the alpha release,
> and schedule it not on code features, but on the website, iso building
> and hosting, and marketing part.
3. I believe the proposed schedule accounts for the end of the GSoC.
It is for the web team to decide whether the schedule has enough air
for them. I think we will be able to pull of marketing.
> I think the better soluion is to
> release it just before BeGeisert in this aspect. So make the
> announcement there. We have two month (september and october) to get a
> nice website, build the ISOs and host them.
4. I am not really convinced that releasing Haiku just before
BeGeistert would have any advantages over mid-September. Feel free to
elaborate though.
> once the iso is built, the
> development can continue in haiku trunk as usual. there is no need for
> a special branch for this alpha. The branches should be made for all
> the features that are in the "Maybe R1" and "Unscheduled" lists on the
> wiki, while R1 features should be developped in the trunk itself. This
> is how haiku's svn always worked, and doing a release is not a valid
> reason to change that.
5. I do not propose to make a special alpha branch. I do want to have
a small experiment with getting all developers on board to exclusively
spend a week on bug-fixing (which is actually a short while). The
reason I want to call of a feature freeze is that I want the building
team (to be selected) to have the time to test various build
configurations without having to work on a moving target. A minor
feature change could have a big impact on the workings of the image.
So there will not be an alpha branch. Technically speaking, the Haiku
repository will be closed for big checkins for just a week.
> Then... I'm not the release coordinator, so feel free to ignore what I said.
No need to cover yourself.
Regards,
Niels
[1] http://dev.haiku-os.org/wiki/R1/AlphaStatus
Other related posts:
