On 31 August 2017 at 22:09, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Aug 31, 2017 at 08:11:56PM +1000, Nick Coghlan wrote: >> > I'd think the solution is simply to mark your module with "Service >> > Level: alpha" (and then we'd want some tooling where SL-alpha and >> > SL-beta modules only show up for those who ask for them.) >> If the definition of active stream (for stream expansion purposes) >> were to exclude SL-alpha (and maybe SL-beta) streams in addition to >> EOL ones, then yes, I think that would handle my/our concerns, as then >> there would be a way to indicate that a *new* streams should be >> considered inactive without needing to set a misleading EOL date. > > I think we'd probably _still_ want it active, because even if it fails, > it's nice to know that sooner rather than later. The case we're concerned about is the one at the start of bootstrapping a new Python feature release where some of the virtual environment management features are missing because the package management tools haven't been built for that stream yet. While the stream is in that state (which is only temporary, but still a non-zero amount of time if we want to avoid relying on binaries built from a previous stream), other build failures are reasonably likely to be due to the bootstrapping being incomplete, which means higher level module builds won't provide useful compatibility information until the bootstrapping is complete and the stream is in a "OK, this is expected to work normally now" state. I believe this problem technically already exists with Rawhide today, but hitting it requires folks to be submitting new Rawhide builds for Python packages precisely while the Rawhide Python stack is in the middle of being rebased. If I correctly understand how it's going to work, the potential ripple effect with the module build system is much worse, as the sequence of events will be: * partial build gets published while bootstrapping a new stream * stream expansion detects a whole lot of higher level modules now missing and submits builds for them * those automatic builds all fail because the new stream wasn't ready for them yet So the request is for there to be a way to indicate that a stream is available for explicit dependencies, but *shouldn't* be taken into account for implicit stream expansion yet. Then, once the low level stream is stable, *then* its maintainers can flick the switch to say "OK, this looks healthy, start building new variants of all the modules that depend on this one". Cheers, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
