[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-development
Subject:    [haiku-development] Re: Package-builders-build-off 2015
From:       Adrien Destugues <pulkomandy () gmail ! com>
Date:       2015-12-02 6:06:37
Message-ID: 20151202060637.GA23647 () pulkomandy ! tk
[Download RAW message or body]

On Wed, Dec 02, 2015 at 12:43:16AM +0100, Michael Lotz wrote:
> 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.

That sounds fine.

> 
> 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.

I think we could try to use the latest release for building these as
well. If this doesn't work (because some package start depending on a
feature only available in the nightlies, for example), it means we should
do a new Haiku release.

For the 1:1 coupling between nightlies and package set, this can be done
by the buildbot. It would mirror the haikuports repo before starting a
build, then use that mirror to build the nightly. I think this would
provide enough "reference points" to also build any hrev with a
package repo reasonably close to what was available at the time. This is
required, because we want to be able to build old revisions when binary
searching for the introduction of a bug.

-- 
Adrien.

[prev in list] [next in list] [prev in thread] [next in thread]