[haiku-development] Re: Package-builders-build-off 2015
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 2 Dec 2015 00:43:16 +0100
On 01.12.2015 08:32, Axel Dörfler wrote:
How far are the solutions from actually taking over the task of building
all packages for a Haiku release?
Are all recipes still fetched from haikuports master?
Getting that right would then be next on the list, right?
The tooling is basically complete in my case, including repository building.
As you say, what we actually need to come up with is a plan as to how
we're going to manage the whole process. Right now we manually maintain
the available packages through commits to Haiku itself. This gives us
full control over the set of packages and also establishes a 1:1
relationship between any given hrev and a set of packages. By automating
the package building and removing the manual handling within the Haiku
repository we lose this 1:1 coupling. Managing the generation of a
predictable and consistent set of packages then needs to happen through
the HaikuPorts repository.
For releases this will probably mean that we have a branch for each
release (for example R1) and manage what ends up in the package
repository by merging things from master or a staging branch,
automatically building the packages for the changed ports and updating
the corresponding repository. The builders for the generation of this
set of packages would then always be running that release of Haiku.
At some point there will be a point release updating that particular
Haiku version (i.e. R1.1). What happens then depends on our support
strategy. It either means the original release remains supported, which
would imply a new branch for R1.1 is created and new builders running
R1.1 would build packages for that release while the old builders still
running R1 would continue to build packages for R1. If we stop support
for R1 as soon as R1.1 is released (which would make sense to me) the
builders could be update to R1.1 and start building for the new version.
What should happen for the nightlies? Obviously it's not feasible (or
desirable) to have a branch and a set of builders for each new hrev.
Since nightlies don't come with any support, this isn't necessary
either. But how is a given hrev matched with a given HaikuPorts package
repo? Do they need to be matched at all or is it enough to start
matching them once (pre-)releases happen (with the process above)? Which
packages end up in the nightlies would then just be decided by when they
are built and therefore what packages are available at that point in
time. What hrev of Haiku is used on the builders (and therefore is
encoded as the required version) is another question. Should they simply
always update to the newest available nightly? Keeping them at a certain
hrev for a certain time could be sensible if some particular hrev proofs
to be stable. Then again that would mean someone would have to regularly
decide what hrev to use, which would introduce manual labour.
Regards,
Michael
Other related posts:
