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_stream_and_version > 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@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
