On 31 August 2017 at 22:09, Matthew Miller <mattdm(a)fedoraproject.org> 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".
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia