[haiku-development] Re: Haiku R1A4 Postmortem
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 08 Dec 2012 10:18:24 +0100
On 2012-12-08 at 01:26:06 [+0100], Sean Collins <smc.collins@xxxxxxxxxxx>
wrote:
> to many users, and supporter, that Haiku is getting stuck in a release
> hell cycle.
Well, this is not because of delays inside the alpha release process
itself. This works fine and I think it's fast enough. The problem is
entering the process by setting a date ("6 weeks from now" if I take the
latest estimations) and having a release coordinator to manage stuff during
the 6 weeks.
To get this working better, we should pick a release coordinator now, just
after Alpha 4 is released. He should then watch trunk status and decide
when it has enough new features and is stable enough to justify the effort
of making a release (with release notes that don't sound too empty).
With dumping random builds from trunk and tagging them as releases we have
several problems which would get us in another release hell. We risk
releasing a low quality release with critical bugs. This leads to a hotfix
release that's done the same way. Maybe this one has even more critical
bugs, which leads to yet another release, etc. The effort for making this
point release is developers not spending their times on features to get R1
closer. Now, this could work better after we enter beta stage, since then
there should be no new features.
Maybe what we can do is delay the branching of the alpha as much as
possible. Start with a trunk nightly image, and ask people to test that.As
bugs are identified and uncovered, fix them. Do not accept commits that
(could) break everything in trunk during this period. Do not make it too
long so the amount of code in branches stays manageable.
Btw, I'd like to suggest (again) setting up an instance of Gerrit. It's a
code review tool that builds on git and it is quite nice to submit patches
for peer review (we currently use Trac to store the patches and mailing
list to peer review them after the fact).
Here's one example instance: http://openocd.zylin.com/
Since this is built on git, the patches are automatically kept up to date.
People can contribute updates to existing patches, and applying them is
quite close to the often requested 'apply patch' button. It is also very
easy to get and try a patch when you have a git tree at hand.
The only problem I see is it forces people using git to submit their
patches, and this is not the most user-friendly way.
>
> The 10,000 foot view right now from many outside observers ,and I do
> watch the FOSS community commentary, is that many of them feel Haiku is
> far more mature then the current Alpha label placed upon it. Many do not
> understand why Haiku still has alpha status, considering that it is
> frequently more stable then many other FOSS systems of comparable
> features and quality.
That's only a misreading of the alpha label. It is not Haiku Alpha, it is
Release 1 alpha. There will always be alpha releases, for R2, for R3, and
so on. This doesn't reflect the state of the whole project, only of the
next release. Read more about the Alpha meaning and origins :
http://en.wikipedia.org/wiki/Software_release_life_cycle
Also, people expect alpha to mean "full of bugs everywhere", but it
actually means "not feature complete". We know exactly what's missing
before we go beta.
Some open source projects would label these version 0.5 and 0.8, before
releasing 1.0. But then, the alphas and betas for R2 would be labelled 1.5
and 1.8, misleading people in thinking that :
* They are straight upgrades to R1 (whereas we could break things, and are
another major release)
* They are stable releases (whereas our API will be in development and
incomplete)
We could use versions like R1.-9, R1.-8, ... but that limits us to 10
alphas/betas/RC. I hope we won't do so much, but having 24 letters from the
greek alphabet sounds safer (and means we could have a Zeta release of
Haiku as well).
> Now, to my last little note in this email. The Haiku team needs a QA
> process, its allot of work. How can the supporter help you with this. It
> goes beyond trac and if the opportunity existed to assist in many would
> gladly help.
Diver has been doing a huge work on testing stuff and finding all the
regressions and possible improvements for years. Sinc ehe's now becoming an
Haiku contributor, I'd suggest getting in touch with him to get that set up?
If you think some more tools are needed, one way is just setting them up on
your own server so we can start experimenting and see if it actually works.
--
Adrien.
Other related posts:
