[haiku-development] Re: Package buildmeister
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 10 Jul 2016 16:09:50 +0200
On Sun, Jul 10, 2016 at 01:50:40PM +0000, Alexander von Gluck IV wrote:
July 10 2016 2:47 AM, "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx> wrote:
Hi there,
I have setup a branch on my fork of HaikuPorts, with only the recipes
currently available in our package repositories (all architectures).
This can be used to experiment on a smaller and hopefully self-coherent
(aka builable from scratch) set of packages.
I can't help to feel this is moving in the wrong direction. Ideally we
*really* don't want to maintain yet another set of recipes.
It's not another set, just a strict subset of our existing recipes.
If we've decided that everyone wants to move forward with the haikuporter
buildmeister, then shouldn't we be adding some features to haikuporter to
accept a "todo" list of packages or something?
Why not store them in a git branch? It allows to keep a clear history of
the changes and keep track of what's going on.
Since we are populating the main Haiku repos from this (something that
will be included in Haiku releases), we want the branch to match the
high QA level of the Haiku project. This does not fit well with the more
relaxed way things are handled at HaikuPorts (nothing bad, haikuports is
moving faster thanks to this).
So, either we use a separate release branch like this, or, we will need
a much stricter review of anything that gets into the main branch (this
includes making sure the revision is bumped whenever a recipe changes,
making sure it builds on all archs, that it doesn't break dependencies,
etc). Since all the things we will want to check require a lot of work,
people would end up setting up some kind of staging area for that. And,
we don't want the staging area to be thousands of pull requests - a
single git branch is a better choice.
It is known that using the repos populated from mmlr's buildmaster was a
source of problem - for example you would get an updated ICU or ffmpeg
before Haiku packages able to use them would be available.
In any case, even if we go with another solution where buildmaster
builds from the master branch at haikuports, there need to be a
transition phase. Starting by getting buildmaster to build the exact
same set of packages we had before, and removing the "jam
upload-packages" infrastructure from Haiku, seems like a good first
step. Then we can see about pointing buildmaster to some other branch
and see what happens.
But if you start by building whatever is in trunk now, and then trying
to run haiku off that package set, you're in for a lot of debugging of
everything at once (switching Haiku to a new repo + fixing issues with
the recipes).
--
Adrien.
Other related posts: