> 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?) Thanks for starting this. I'm not aware of a ticket or a responsible party at this point. +1 to working towards formalizing this. > 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"? FYI - we had to put some initial SL values into the database to seed the branch migration. Our existing 'master', fedora, and epel branches needed values in the new database. Here are the ones we added: - rawhide - Our thought was that the 'rawhide' SL would signal whatever rawhide means today: more or less tracking upstream. The master branch of all packages got this SL applied in our migration. - bug_fixes - See security fixes below. - security_fixes - This, along with bug_fixes, was a generic SL that got applied to all "fedora" branches (f26, f25, etc..). - stable_api - This one got applied to all of the epel branches. https://pdc.stg.fedoraproject.org/rest_api/v1/component-sla-types/ The real meaning of these values isn't documented anywhere and so they should be taken with a grain of salt. They are something that we can and should change if FESCo (or releng?) or the packager group at large decide to organize our SLs along some other basis. > *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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
