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
