Hi there,
So, let's talk about this Beta1 release everyone is waiting for.
We now have buildmaster running and creating Haiku packages, publishing
repos automatically as recipes are added to haikuports. For the past few
weeks I started using these repositories, and things seem to work fine
so far. When a problem is found, usually it is fixed quickly enough, and
being able to just push a recipe to haikuports to get it into the repos
is very convenient.
The repos are at
http://eu.hpkg.haiku-os.org/haikuports/master/repository/ if you want to
try them.
Knowing that, let's discuss on the next steps to go towards the beta1
release.
On the existing Haiku-managed repo
==================================
The existing repo at download.haiku-os.org is used when building Haiku
from sources. This is where we download package files from. It is
managed using jamfiles in Haiku sources and the "upload-packages" jam
target.
It was set up this way because it automatically keeps an archive of old
repo states, allowing people to build Haiku from old sources and get a
working image (useful for binary searching regressions, for example).
The new repo does not provide anything like that, it is more of a
rolling release with only a "current" branch.
My suggestion here is to keep things as they are, but:
- Strip the repo used to build Haiku to strictly the things needed to
build Haiku. This means it remains used at build time, and we still
need to manually upload packages to it, but much less often as it is
only for the core libraries.
- Make the images point to the eu.hpkg repo by default. This means on
first install, people will have a lot of updates to install already,
but then they can easily keep their system up to date.
This way, we keep the strict control policy on the repo used to build
Haiku (this is core stuff, only Haiku devs should be allowed to mess
with it), but have a more flexible approach at Haikuports.
On the haikuports/buildmaster side, we may need a "testing" repository,
however it is also quite easy to test things locally (build a package,
install it, make sure things still work).
Packages and R1 branch
======================
The current plan for beta1 is that it is the branching point for the R1
branch. This means, once beta1 is out, there will be two live branches
in the Haiku repo. The R1 branch with the goal of fixing bugs in beta1
(no new features), and the master branch where works towards R2 could
start.
Doing things this way means the master branch will start to break binary
compatibility at some point. This means we need a different set of
packages and packages builders for it.
Our options are:
- Set up haikuports & buildmaster to handle this and publish two
separate repos. We may need to extend haikuporter to be able to tag
recipes as "R1 only" or "R2 only", I guess. It should be possible to
use the haiku version for that (haiku >= R1~beta1 or haiku >= R2 or
so).
- Give up on creating the R1 branch now and delay that to beta2. This
allows us to get the beta1 release sooner and work on these
infrastructure things a little later.
It depends on what the plans are for R2. I don't think there is much
code breaking binary compatibility in the works yet, so maybe the delay
creates no problems and we can continue with a single branch for some
time? In that case the beta1 branch would follow the same lifecycle as
previous release branches: a few weeks/months of stabilization, then the
branch "dies" when the release is made.
On using Gerrit
===============
After years of requesting it, the sysadming team finally found time and
hardware resources to set up a Gerrit instance. It is up at
review.haiku-os.org.
From my experience as the alpha3 release coordinator, a huge amount of
time was spent reviewing and merging patches. This is when I started
pushing for Gerrit as a more convenient tool for that task.
I think we should start using Gerrit for the beta1 branch. All commits
to that branch should go through the review process on Gerrit, with a
policy to define (for example, "needs at least two +1 and no -1 from
reviewers"). This will allow sharing the work of reviewing patches and
reduce a lot of the effort needed to be release coordinator, making that
role easier to handle (remember the initial release workflow was defined
with Ingo working full-time as the release coordinator, which allowed
him to spend more time on it than I can allocate).
Wether to make Gerrit mandatory for commits to the trunk is another
question. I know some people want to keep direct access to the git repo
and bypass the review process, and others prefer their code to be
reviewed before it's merged. I think we don't need to make the process
mandatory, and should let people decide wether a change deserves review
or not. We can then blame people who bypass it and break the build or
introduce regressions until they agree to use Gerrit review ;).
We do need to spend some time toying with Gerrit and documenting how we
plan to use it and configuring it accordingly.
On the timing
=============
On my side:
- October: GSoC mentor summit + 1 week vacation
- November: KDC coding sprint organization
- December to January: Google Code-In
As usual a quite loaded schedule but it looks like I can't expect a more
idle time anyway (just GCI + GSoC keeps us busy for most of the year
already).
So, I see no real reason to delay the release further.
The only remaining blocker bug is #10336 (fstrim destroys data), but we
can just remove the fstrim command from the release. #10279 (random
binary crashes) is also worrying, but my machines are not really
affected so I can't help with this one.
Are we ready for a release? How long should the beta1 branch be
accepting bugfixes until we ship?
--
Adrien.
