[haiku-development] Re: [haiku] Re: Future releases? Recommend nightlies? gcc2?
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 01 Dec 2016 16:08:22 +0000
Through all of these conversations, i've never once said to "get rid
of gcc2 (at least until R2 and beyond ;-)) In my eyes having
x86_64 + gcc2 would be ideal for R2 (but we need to work on running 32-bit
code on 64-bit systems)
for people who want Haiku for other reasons than BeOS compatibility, we can
recommend x86_64. This should cover a quite wide range of users at this point.
We can keep gcc2h for people who need BeOS compatibility, as it has the maximal
compatibility.
R1a4 was 32bit only, but I think we can make beta1 the first release to
officially support 64bit. This kind of solves the gcc2 problem by itself.
The main blocking point is still setting up the package repos so we
can create an R1 branch and have it use a different set of packages
than the R2 branch. I have solved most of the issues with the
haikuports recipes. Now, we need:
- More buildbots for the packages, especially if we want to support
gcc5h or x86_64 for beta1 (all bots currently online are gcc2h).
We already have a few MacMini's set aside for this. We just need someone
to coordinate and provide setup instructions. I tried to form this but
found myself staring at the rabbit hole of work that you eventually went
down and finished. (nice work btw)
We just need them to run a recent Haiku install, and be available through ssh
or a reverse ssh tunnel. From there it's easy to log in remotely and set things
up.
We also need to move the buildmaster from where I host it to some proper server
(you really don't want Haiku to rely on my home network infrastructure).
- Someone to set up the repos on Haiku servers (I'm not admin there
and don't want to be).
The idea of having repo servers in multiple geographic regions has come
up before, would this be a good time to look into that? Our current
infrastructure is pretty slow outside of Europe.
How big is the repo potentially? I assume we won't keep "all the builds"
like we do on the nightly servers.
Maybe 2 or 3 geographically diverse repo servers for "release repos"?
We already have mirrors for releases, I don't think there is a problem with
hosting the package repo there. And yes, as the API for the underlying OS
should be stable, no need to keep separate repos for each hrev in the R1
branch, that will save a lot of space.
I think the repo will be a few gigabytes, at most. It is served over HTTP which
makes it easy to use our standard mirrors here, not dedicated machines. IIRC
they are synced periodically from the master copy of the download dir on
www.haiku-os.org, so it is just a matter of exposing the repo at the right
place.
With that solved, we can create the R1 branch, point it to these new
repos, and then let the trunk open to all the R2 stuff. I don't know
if that will make it more active, we'll see. On the R1 branch we can
work on fixing or hiding the most annoying bugs and go for a release.
It won't be perfect and bug-free, but hey, it's only a beta.
I like the idea of branching B1 off and releasing R1 from the same branch,
puts a bit of focus on getting R1 out quickly. I don't think master will
see any "huge changes we don't want in R1" for a while though. All my
belly-aching has simply been about recommending gcc5h over gcc2 :-)
Well, at least it makes sure people think twice before messing with the branch,
and makes a stronger "feature freeze" on it. Then we can backport stable and
tested bugfixes from the R2 branch, until there is an R1 release, or everyone
stops caring about it and BeOS compatibility. We will also be able to make
releases whenever we want, as there will always be a branch ready for that.
--
Adrien.
Other related posts:
