I'm looking at:

    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 

* 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

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
Fedora Project Leader
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to