Re: Planning for a release, for real

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]


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.

>   • Get base binaries on all supported architectures in a timely
>     fashion, or drop some of the architectures.
>
>     Namely, ‘make assert-binaries-available’ is currently failing.  It
>     uses a manifest that encodes what we consider to be the basic
>     requirements for each architecture; it’s not demanding for
>     aarch64-linux, even less for armhf-linux and i586-gnu—yet we’re not
>     meeting these criteria yet.
>
>     We need to look at missing substitutes, address build issues and
>     build farm issues that cause them until we get to zero failures.  If
>     after some effort we fail to get to zero, then we should consider
>     dropping architectures (I’m looking at armhf-linux and i586-gnu
>     specifically).
>
>     Again we need a champion to keep track of this and ping people so we
>     make progress!

Is there a reason why ‘make assert-binaries-available’ is just checking
ci.guix.gnu.org? One of the main reasons why bordeaux.guix.gnu.org
exists is to address the lack of substitutes, and if you do check the
mainifest against bordeaux.guix.gnu.org you do get a slightly higher
percentage.

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.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]