[haiku-development] Re: Package buildbots

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 18 Oct 2016 10:09:42 +0200

Am 18/10/2016 um 09:57 schrieb Adrien Destugues:

Well, that's where it ultimately belongs, doesn't it?
We will need policies on who can push to that branch and what the
process is. Since the build of package repos will ultimately be
triggered by pushing to that branch, we need to be reasonably sure
that we don't push too broken things there.

I would say we'll need a staging branch, and push to the release branch automatically when the buildbots can build it completely. Probably even with manual testing and approval, too (possibly with a second branch, ie. staging -> testing -> release).
We should have buildbots on all three of them, and as a user, you could then decide if you want to use "testing" or "release" (staging might be broken and should not be used, although it'll be the same as "testing" as long as it can be built completely).
Does that sound reasonable?

If the Haiku project is fine with leaving this in control of the
HaikuPorts project, I'll move the discussion there. Otherwise, we
could put that branch on Haiku's github repos instead and keep some
control on it.

I wouldn't mind either way, although I think that it should stay with haikuports.

Also, this morning I've set up a first bot, provided by Arfonzo. It's
currently (slowly) running over the current package list.

From the previous builds I remember some issues we will need to fix:
- gcc_6809 is broken. I suggest removing it from the depot since I'm
likely the only user. I'll fix the recipe later. - avr_gcc is also
broken. It would be nice to fix this one as it is used for Arduino. -
there is a mismatch between mesa_x86 and llvm_x86. I suggest
downgrading llvm to fix mesa build, or updating mesa to match the
current llvm version. Possibly the llvm libs need a version prefix.

On the TODO list is also making more improvements to the build status
page, and moving some of the logic server-side (the current page
downloads several megabytes of JSON and process it in javascript on
user side, it is slow and bulky). We may be able to reuse some of
Kallisti5 and waddlesplash's work here, and maybe put some GCI
students on the job.

Sounds good.

Bye,
   Axel.

Other related posts: