Re: Planning for a release, for real

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Christopher Baines <mail@cbaines.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> We need to plan and coordinate.  Releases have to be a group effort;
>> some of the most important work won’t be coding but coordination.
>> Coordination is key.  I don’t think I should be spearheading that
>> effort, but I’m happy to be part of it.
>>
>> Who’s ready to commit time towards that goal for the coming weeks?
>>
>> Here’s a list of things to do to get there:
>>
>>   • Merge ‘staging’ (?).  What’s the status of that one, it seemed ready
>>     a couple of weeks ago, but then I lost track of it.  Marius?
>>
>>     We need a ‘staging’ champion to keep track of what’s left to be
>>     done, reports progress, pings people, etc.  That person does not
>>     have to be hacking like crazy, on the contrary!
>
> I'd like to get qa.guix.gnu.org to the point where it's useful for
> getting branches merged. Currently, it's possible to submit builds for
> branches, which is happening currently for staging.
>
> While that's great, the substitute availability for the branch is still
> poor [1], the builds are happening, but there's just not enough hardware
> behind bordeaux.guix.gnu.org currently to keep up with both the large
> number of builds on the master branch as well as building staging
> quickly.
>
> 1: http://data.qa.guix.gnu.org/repository/2/branch/staging/latest-processed-revision/package-substitute-availability
>
> I know that's not what you're asking for here, but I think a big problem
> when it comes to merging branches is that of checking what's broken, and
> that's what I'd like to make easier.

Yes, definitely!

> Is there a reason why ‘make assert-binaries-available’ is just checking
> ci.guix.gnu.org?

It’s mostly that ‘guix weather --display-missing’ is not really helpful
when passed more than one URL: it reports all the things that are
missing on at least one of the URLs (this is what the comment in
‘Makefile.am’ suggests).

The goal of this command is to check that “basic packages” build and are
available, and we can expect basic packages to be available on both
build farms so I think it’s OK to check just one of them.  (When I first
wrote that manifest, I naively thought we’d be at 100% at any time since
this is really the baseline…)

> i586-gnu is a shared problem though, I'll try and see if I can get some
> childhurd VMs working, although I'm not sure this'll be timely enough
> for the upcoming release.

For i586-gnu the expectation is really low right now: see
‘%base-packages/hurd’ in ‘etc/release-manifest.scm’.

Ludo’.