On Thu, Jun 29, 2017 at 11:07:10AM -0400, Matthew Miller wrote: > 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. Okay. Then it needs to be worded differently. > 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 EOL's not part of modulemd today for the reasons I mentioned in my previous email (we don't know if that's the way to go) but can be added if we finally make that decision. The extra tags are meant to be part of the stream name today. The intention was to have stream names more descriptive and less version-y. Splitting streams into main package versions and some additional tags would require some changes to how we handle dist-git-branch-name-to-modulemd-fields mapping. > > > * 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. Given the response above it appears you understand streams somewhat differently. Until now we've been operating with the assumption (and everything is coded that way) that streams map directly to branch names. If you have a "latest" stream, you develop it in a branch called "latest". If a user consumes this stream, their automatically get breaking changes because the "latest stable version" means different things at different times. Hence the comparison to Rawhide. And I knew you would respond to the babies bit ;) > > 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. I don't know how to respond to this. > > 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. Making people switch between update streams if the content they already consume becomes supported for longer doesn't feel like the best UX decision. EOL shouldn't be tied to stream names. > > 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. Works for me. Right now we use it for random development but that's because we're just starting with all this. > > > * 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.] Ok :) P
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
