[haiku-development] Re: Release management & commit access
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 26 Jul 2014 10:08:06 +0200
> - "We might not be able to recreate the prebuilt HaikuPorts packages"
> This one is true. However, in recent weeks, I've rebuilt packages during
> the KDELibs porting process and uploaded them and nothing has broken so far.
> Francois has done the same with no catastrophes either. The only real
> problem then is the fact that FFMpeg does not build on GCC4, which I'm
> working on currently and should have a fix for soon enough.
There is more to it. The problem here is we are going to ship the alpha
with a fixed set of packages, and we want to make sure all of them are
installable and work as expected. Our package base is much bigger than
in previous releases, so this needs a lot more QA. You're right, this is
only an alpha, but we are also testing our release process with these
alpha releases. In this first release to include PM, we need to find a
way to make sure all the packages we provide as defaults are
installable, and that they work well enough so we don't start to tell
people to use nightlies again just two weeks after the alpha is out.
I think the requirements are as follows:
* All packages that Haiku depends on must be provided and tested. Oliver
has started working on this in his "release" branch of Haikuports.
This allows making the version of these packages stable, and something
people can rely on in this alpha release.
* Whenever possible, the alpha should be used as the reference release.
That is, all packages in the haikuports repos should be built against
it, so people running alpha5 can use the "current" HaikuPorts repo and
install the packages from there, without having to upgrade their system.
So we need the release to be stable especially when using it with
haikuporter.
Missing those requirements will make the release little more than just
another nightly for us. It may make the community happy, but it doesn't
bring us much further towards R1. So I think it's better to block the
release on this, even if that means it takes a few months more to get it
out.
The result will be a more solid release that can serve as the reference
for the year to come. We can then focus on getting Beta1 out without
having to do an "emergency fix" release because alpha5 has unacceptable
bugs.
--
Adrien.
Other related posts:
