I'm looking at: https://fedoraproject.org/wiki/Module:Guidelines#SLs_and_EOLs While not a part of the modulemd specification yet, modules will eventually carry a Service Level (SL) value and an End of Life (EOL) value. The work in Changes/ArbitraryBranching will enable packagers to select independent SLAs and EOLs for both their rpm branches as well as their module branches. Both of these values are associated with the branch in a dist-git repo, but not with the modulemd or spec file contained therein. Packagers will have to choose from a set of pre-defined SLs maintained by Release Engineering. More info coming soon! Is there an active plan on figuring out these Service Levels? Is there a ticket? Is there a specific person who owns this? I think we need at least a preliminary understanding of what goes here for the F27 beta (freeze on Sept. 9th, so... I guess by then?) I'm assuming "Service Levels" will include options like: * This module strives to be very stable and we will backport patches * This module tries to be stable but occasionally we may make breaking changes with FESCo approval when it's the only option for a security update (this matches the current Fedora updates policy at https://fedoraproject.org/wiki/Updates_Policy#Security_fixes) * This module promises only a subset of functionality to remain the same. For example, it will include a certain command line program but doesn't promise that output of that program will aways be identical. * This is a development-stream module which makes no promises! (E.g, it is Rawhide.) Is that the kind of thing others are expecting? Or was this to be more like "security", "security+bugfix", "security+bugfix+enhancements"? *Or*, is it something like "best effort", "sig maintained", "core critical path", "edition critical path", "spin critical path"? I can see the first idea (the * points above) as most useful to end-users. The third idea is more useful for *us*. I'd also like to propose a policy for EOLs. I assume that some modules will have undefined EOLs, and I think that's okay. There should be some mechanism and rules for adding one (amount of notice expected, what to do if we can't meet that expectation, how the tools will present the addition of an EOL). When a specific EOL is given, though, I'd like a rule which says that that EOL is aways a month after the planned traditional Fedora release dates — so, June and November, basically. (We could choose something like "The last Tuesday in June or November"; I don't care specifically.) Also, EOL should be treated as a "no sooner than" date, so if we slip the corresponding release, we could add a week or two to the upcoming module EOLs. That way, users and admins aren't treated to an explosion of arbitrary days where action is needed to stay on a current stream. Instead, they can plan for annual upgrades as we do now. (I also expect the "platform" module to follow the current Fedora release cycle, right?) Perhaps there could be an exception made to this rule for modules with the "development stream" Service Level. Or, maybe those would just have no defined EOL — like Rawhide today. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
