8:26 a.m.
On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote:
Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.
An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26). For
modules which correspond primarily to a single piece of software (and
associated stuff), it makes sense for the stream to match the major
version of the software: module nodejs might have streams for 8 and 10,
and httpd might have streams for 2.4 and 2.6.
In fact, let's make that a guideline. I believe the existing
https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_st...
doesn't have any rules, so let's make one. Specifically:
I see those guidelines need to be updated to match reality.
/me makes a note to review them.
* 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 agree there should be some recommendations on stream naming
but this feels far too strict for no reason.
* 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 ;)
So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.
+1
On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:
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".
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?
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.
It also affects many other things all over the place such as
UX, system profiles or extended module dependency selectors.
It's not as simple as it may sound.
Each such "collection" module MUST have one or both of the
following:
* 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/.
Just bikeshedding.
* 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
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 know there is some work on stream-to-stream upgrades in
modularity;
that work could take advantage of this convention.
So, we'd have:
httpd 2.4
httpd 2.6
nodejs 8
nodejs 10
sysadmin-tools latest
sysadmin-tools f1812
sysadmin-tools f1906
Does this make sense? Do you have improvements or entirely better
ideas?
I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.
I like simple integer approach and it feels natural from an
engineer's point of view. I think. I can also imagine using
years or years.months, depending on how often the module
maintainer decides to release a new... thing.
Like "tools 2017", "tools 2017.6". *shrugs*
But I don't really have a preference.
I wouldn't include EOL directly in the stream (i.e. branch)
name but I totally agree it needs to be prominently displayed
in any user interface that deals with modules. No matter where
the tools get it from.
":" is one of the symbols still considered for name:stream
separation, if it's going to change from the "-" used currently.
I also like the idea of a stable marker. Not only users but
even the pipeline needs to know.
Anyway, thanks for doing this,
P
With this alternate proposal, we'd have:
httpd 2.4:stable
httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
nodejs 8:f1912 (because that's upstream eol)
nodejs 9:f1806 (if someone wants to do the work for a non-lts release)
nodejs 10:f2106 (or maybe e2012)
sysadmin-tools 1:latest
sysadmin-tools 1:f1812
sysadmin-tools 1:f1906
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org