On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
> > * Modules which correspond primarily to a single application or
> > versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
> > use a stream label corresponding to the major version of that software
> > (e.g. 2.4 or 8)
> So if I'm reading this correctly, you're proposing Fedora should
> forbid packagers from creating alternative streams for the same
> major release of such software? I can imagine different variants
> of httpd 2.4, built with different compile time options, bundling
> different components, having different module metadata and such.
I think alternate versions are okay, but those should come after a
primary version -- there should be *at least* this and then there could
be others.
In thinking a little further, I think there are three basic bits of
metadata that need to be easily visible per-stream. Whether it goes
into the stream label or into other metadata is an implementation
detail. They are:
* major identifier (in the case of modules with a primary piece of
software, probably the major version of that software)
* lifecycle / eol identifier
* extra tags describing alternate options
So, for example:
nodejs 8:e1912 (or maybe 8:e1912:main, but I don't like that)
nodejs 8:e1806:turbocharged
nodejs 8:e1912:lite
httpd 24:stable
httpd 26:latest
httpd 24:e1812:spdypatches
> > * Such modules MAY additionally have a "latest" stream, which would be
> > "rolling release" of the latest stable version (as opposed to master,
> > which corresponds to rawhide and may be unstable).
> Sounds like the no-more-alphas Rawhide. Such "latest" streams
> would drop major changes/rebases on the end users' systems.
> It makes sense to have this, especially for developers, but
> we should warn people that it's not the best choice for stable
> systems and that... it will eat their babies ;)
No, this should definitely not eat babies. (Even Rawhide doesn't do
that anymore. Usually.) And while automatic gating would be fine, it
wouldn't need to be.
> There are still some open questions regarding EOLs.
>
> For instance:
>
> Are they bound to the artifact or could that depend on the
> context? Like "this module will go EOL next year for standard
> Fedora and nobody will care to make it work with the latest
> Platform but we'll still support it in the context of this LTS
> spin / derived distro / whatnot".
If this is a thing, modularity hasn't really succeeded.
> Can EOL be extended for already released artifacts and if so, do
> we need to issue an update to let users know through refreshing
> their metadata?
This is partly why I described EOL as "EOL no earlier than" (thanks to
Langdon). I think the best thing to do in the case of a long extension
would be to create a new branch/stream with the new EOL. That's part of
why I think modules need to carry their own succession information,
too.
> Answers to these questions help us decide whether EOL metadata
> should be bundled with the module, inside modulemd in the
> repodata, or whether it belongs in an external system such
> as PDC.
Right. :)
> > * A "latest" rolling stream (As above, this would be separate from
> > "rawhide", as "latest stable", but could update frequently and
> > arbitrarily.)
> By the way, should rawhide streams be called rawhide or would
> master be fine? Stream names come directly from dist-git branch
> names but of course there could be a hardcoded exception in
> MBS that does s/master/rawhide/.
There's two big things here. First, it absolutely shouldn't be rawhide.
That's the same as having f26 or f27 branches: tied to a particular
base.
Second, though, if we have all the various different variants per
stream as you describe above, does it even make sense to _have_ a
master branch? Which variants would it be the master _for_? This might
suggest that long-lived and very distinct streams should actually have
a different _name_ and live in a different repo in dist-git, with
streams in the same repo required to be closely linked in some way.
I'm not sure I like that, though, and it seems very contrary to the
current design. I guess one option would be for master to automatically
correspond to "latest major version, rolling release", but that
seems not as helpful as being explicit. Maybe "master" should just
contain a readme describing the various branches.
> > * One or more streams corresponding to "end of life no earlier than",
> > in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for
> > 'until'? Or "fYYMM" for 'fedora' — which might make sense if we get
> > to my dream of mixing and matching with CentOS modules....)
> See my EOL-related points above. Plus this would be ugly :P
Uglier than a bunch of random names with no semantic relation? I'm not
so sure!
> > Additionally and for all of our sanity, I suggest:
> > * Valid module end-of-life dates are always either June or December,
> > corresponding to the Fedora schedule of early May / late October
> > base releases. So, f1806 or f1812, but not f1810 or f1901.
> Sounds like a valid recommendation rather than a necessary rule.
I'm gonna argue for rule. As a user, a situation where modules are
arbitrarily EOLing every day seems nightmarish.
[And I'm going to reply to the second half of this in a separate
message.]
--
Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
