Re: ftp.debian.org: [rfc] improving point release workflow
Hi,
On Sat, Sep 17, 2016 at 01:52:30PM +0200, Julien Cristau wrote:
> during point releases ftpmaster and SRM spend quite a bit of time
> waiting on each other. It would be nice if we could avoid that. One
> idea would be to have a "stable-staging" suite (or some such), not
> mirrored except on coccia (I guess), under SRM's control (via
> control-suite / import_dataset), where we could dump the bits we want
> from proposed-updates, ideally also run cruft-report / dominate / gps2,
> and do our checks in advance, so that on release day ftpmaster could
> just either copy that to stable, or still do the same dance as today,
> except that SRM's double checking would be much easier since we would
> already know the expected final state of things.
>
> Comments / ideas / opinions?
I think we should give it a try.
If ftp-master creates a 'buster-staging' suite after the upcoming point
release, that can be set using control-suite, we can try to see if this is
useful. I can set up a britney instance that fills this suite based on stable
and pu, and keep an eye to see if something needs to be added to the dak
config for this. As Julien noted, this should allow checking the contents of
the upcoming point release before it actually happens.
If it turns out this is useful during later point releases, it can be kept. If
not, it can just be deleted again. Having this suite doesn't prevent doing a
point release based on stable an pu, as it is done now.
If we try this, I don't think buster-staging should be on the standard mirrors
right now. As we haven't tried this before, it's unclear how this would work.
Publishing it to the mirrors requires documenting the role of this suite to
users, which we shouldn't do at this point. If the suite is available on
respighi (for britney), that should be enough. If we decide to keep long term,
we can work out how/where to publish the suite and how to document it.
An important consideration is that there is a (real) risk that some versions
would go backwards in this suite: when a new version is added to
buster-staging, but issues are discovered before the point release, that
prevent the new version from going into stable, this has to be reverted in
buster-staging. For a (semi-)private suite, this isn't really an issue. Even
if the suite is used for (automated) qa, that shouldn't be a big issue. But if
users start installing it on 'real' systems, this would need attention. If we
publish this suite later on, we should think about a way to deal with this. I
don't think we should try to solve this issue right now.
More comments still welcome. Any objections?
Thanks,
Ivo
Reply to: