On Sat, Aug 5, 2017 at 1:17 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > 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. I kind of disagree with this. It's tying modules into a collection we call a release, which means having independent EOLs is essentially pointless. If we allow modules to help implement a rolling release, then they need independent module lifetimes. > 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?) I think that's short-selling users and admins ability to understand what is supported and how to deal with it. Rather than knee-capping modules, I think we should aim for a tool that easily informs users how long each module is supported for. Admins already deal with varying EOLs today on Enterprise products (e.g. RHEL is supported for 10 years, but some Openstack versions are supported for 1 and some are supported for 3). josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
