Re: [Modularity]: Service levels and EOL expectations?

[Matthew Miller]

On Thu, Aug 17, 2017 at 11:19:53AM -0500, Adam Miller wrote:
> >> Service Level: 6 months (effective SL: 3 months/EOL: 2017-11-08 due
> >> to dependency on openSSL)
> >
> > Ouch. Yes, but I think that that should be a warning sent to the module
> > maintainers (and collectively to devel list) rather than show to end
> > users.
> I think this data needs to be displayed to users. As a sysadmin, I
> would absolutely want that information available to me similar to how
> I am able to check/view security update information with 'dnf
> updateinfo'.

I mean that the message for end users should be: 

  Service Level: 3 months

and maintainers should get a warning mail.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Adam Miller]

On Tue, Aug 8, 2017 at 10:21 AM, Matthew Miller
 wrote:
> On Tue, Aug 08, 2017 at 10:38:15AM -0400, Przemek Klosowski wrote:
>> >Yeah, that would get crazy fast. The 6 month granularity proposal
>> >should help*some*, and we should probably go into this carefully.
>>
>> Technically, the SL for the module could have the narrow meaning
>> referring to the module only, and the tools could follow the chain
>> of dependencies and display it as:
>>
>> Service Level: 6 months (effective SL: 3 months/EOL: 2017-11-08 due
>> to dependency on openSSL)
>
> Ouch. Yes, but I think that that should be a warning sent to the module
> maintainers (and collectively to devel list) rather than show to end
> users.
>

I think this data needs to be displayed to users. As a sysadmin, I
would absolutely want that information available to me similar to how
I am able to check/view security update information with 'dnf
updateinfo'.

-AdamM

>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Matthew Miller]

On Mon, Aug 07, 2017 at 11:48:53PM +, Langdon White wrote:
> I guess I am not sure how this is different with modules than with Fedora
> today. We promise a 13 month lifecycle on openssl (and everything else)
> already. I think the difference here is only that the "position" is
> explicit. However, this is not the "real" point to my reply.

Well, right now, that implicit SL/lifecycle is the same for every
package -- or given a specific exception
https://fedoraproject.org/wiki/Updates_Policy#Exceptions.

If we add the ability to make it explicit, we need to now be
clear on which choices are acceptable in Fedora. If we make it "you've
got to have the exact SL and lifecycle as always before", we lose quite
a bit of the power. If we make it "sure, go EOL every two weeks with
your core package!" we lose the benefit of being a distro at all.



> I agree it is true that the lifecycle of a given *binary* is locked to the
> lifecycle of the module binaries it depends on. However.  this does not
> necessarily mean that a *stream* is locked to the those lifecycles. In
> other words, wordpress doesn't expose glibc or openssl APIs to its
> consumers (to my knowledge ;) ). As a result, it is perfectly valid for the
> wordpress-4 stream to be built against base-runtime-f26 (brt) or
> base-runtime-f27 or both. If the lifecycle of base-runtime-f26 runs out,
> that doesn't mean wordpress-4's lifecycle has run out, it just means that
> the user must upgrade the base-runtime stream but their application that
> relies on the wordpress-4 API will continue to operate unchanged.

Sure. But from a user point of view, if this juggling happens on
arbitrary dates many times throughout the calendar year, we've just
delivered something with all the disadvantages of a rolling release
*plus* a lot of extra complication. 

But let's not even go that far out. Just within base runtime itself,
there are hundreds of packages. If *those* are aribitrarily EOLing all
the time, the maintainers of the base runtime module are going to have
to spend significant time juggling that.
 
As what I read this


> As we are able to increase the bundling of components, the 99% continues to
> add 9s after the decimal. At present, we must consume the openssl-1.1
> branch in brt/shared-userspace because dnf/rpm can't tell that the binaries
> provided by different modules are functionally the same. However, as we
> improve that or find other methods around this problem (private
> namespacing, containers, rpathing, etc), we could have the openssl-1.1
> sources in dist-git be included in multiple modules. When the openssl
> maintainer elects to add the openssl-1.2 stream, wordpress-4 could decide
> if it is appropriately backwards compatible for their use case and consume
> it (by changing their modulemd to point to the new stream).

... a lot of that juggling is going to be discovering every week that
some important component has shifted and now the module maintainers
need to find someone to maintain a compat branch of the older package.
That could include packages which are just under the hood but
incompatible or could be packages which have a knock-on effect and
change the exposed module API. Following all of this seems like an
unrealistic explosion of work. Right now, if I want to maintain Apache,
I can rely on the 13-month implicit API for OpenSSL. I can concentrate
on the thing I have expertise and interest in and trust that others
in the community have made commitments for the dependencies. It's great
that modularity offers me the ability to take on more if I want to, but
if I *have* to in order to make a module with even the same promises as
current Fedora, that's worrisome.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Matthew Miller]

On Tue, Aug 08, 2017 at 10:38:15AM -0400, Przemek Klosowski wrote:
> >Yeah, that would get crazy fast. The 6 month granularity proposal
> >should help*some*, and we should probably go into this carefully.
> 
> Technically, the SL for the module could have the narrow meaning
> referring to the module only, and the tools could follow the chain
> of dependencies and display it as:
> 
> Service Level: 6 months (effective SL: 3 months/EOL: 2017-11-08 due
> to dependency on openSSL)

Ouch. Yes, but I think that that should be a warning sent to the module
maintainers (and collectively to devel list) rather than show to end
users.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Matthew Miller]

On Tue, Aug 08, 2017 at 02:13:38PM -, Ralph Bean wrote:
> 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'll make one if no one else has. Should we start at a rel-eng ticket,
get a proposal worked out, and then propose to FESCo?

[...]

> 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/

So this is a list of values? Interesting. 

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Przemek Klosowski]

On 08/07/2017 03:58 PM, Matthew Miller wrote:

On Mon, Aug 07, 2017 at 02:10:23PM -0400, Stephen John Smoogen wrote:

I still don't see how this is going to work with a tree of Service Levels
and Lifetimes. Any module can not give a SL greater than the lowest SL and
the shortest lifetime that any package in it is going to agree to. [EG if I
am packaging up a wordpress module and glibc is on a 18 month lifetime but
openssl is meh upstream always.. then unless I am going to maintain openssl
myself with its own fork... my module is going to be 'meh upstream always'.
If my module pulls in enough stuff to make it work, I am going to be
dealing with the need of a lawyer to figure out which SL's and lifetimes
are binding and what ones are not.

Yeah, that would get crazy fast. The 6 month granularity proposal
should help*some*, and we should probably go into this carefully.


Technically, the SL for the module could have the narrow meaning 
referring to the module only, and the tools could follow the chain of 
dependencies and display it as:


Service Level: 6 months (effective SL: 3 months/EOL: 2017-11-08 due to 
dependency on openSSL)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Ralph Bean]

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

Re: [Modularity]: Service levels and EOL expectations?

[Langdon White]

On Mon, Aug 7, 2017 at 3:59 PM Matthew Miller 
wrote:

> On Mon, Aug 07, 2017 at 02:10:23PM -0400, Stephen John Smoogen wrote:
> > I still don't see how this is going to work with a tree of Service Levels
> > and Lifetimes. Any module can not give a SL greater than the lowest SL
> and
> > the shortest lifetime that any package in it is going to agree to. [EG
> if I
> > am packaging up a wordpress module and glibc is on a 18 month lifetime
> but
> > openssl is meh upstream always.. then unless I am going to maintain
> openssl
> > myself with its own fork... my module is going to be 'meh upstream
> always'.
> > If my module pulls in enough stuff to make it work, I am going to be
> > dealing with the need of a lawyer to figure out which SL's and lifetimes
> > are binding and what ones are not.
>
> Yeah, that would get crazy fast. The 6 month granularity proposal
> should help *some*, and we should probably go into this carefully.
>
> For packages, the default is to have fNN branches with the implied 13
> month lifecycle and 6 month branch/update window. (Which means that
> even nearing the end of the 13 month cycle, there's an overlapping
> cycle going half a year longer.)
>
> The Arbitrary Branching proposal suggests not* do this for f28
> *automatically (but still allow it). Maybe (at first at least) we need
> to say that if packagers want to do *other* cycles, they need to give
> at least this "there's a version with an EOL at least 7 months off, and
> if you hit it right there's a 13 month window" service level. (That
> could be fulfilled by "there's one version that is expected to
> continually update in a compatible way".)
>
> Packagers who don't want to deal with all this could just make the
> "f28" branch, and packagers who instead want to do something else
> longer or additional could.*
>
> Then, we could have an opt-in process (FESCo approval?) for packages
> where the upstream changes too fast to support that. (These packages
> are presumably problematic in Fedora currently _anyway_.)
>
>
> * And "longer" sounds like more work, but in many cases it shouldn't
> be. I maintain couple of small "leaf" utility programs which are
> unlikely to change in a significantly incompatible way, and rather than
> maintaining them across "rawhide, f29, f28, f27, el7" I'd like to
> maintain just "devel" and "2.stable".
>
> But there's _definitely_ a lot still to work out here!
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


I guess I am not sure how this is different with modules than with Fedora
today. We promise a 13 month lifecycle on openssl (and everything else)
already. I think the difference here is only that the "position" is
explicit. However, this is not the "real" point to my reply.

I agree it is true that the lifecycle of a given *binary* is locked to the
lifecycle of the module binaries it depends on. However.  this does not
necessarily mean that a *stream* is locked to the those lifecycles. In
other words, wordpress doesn't expose glibc or openssl APIs to its
consumers (to my knowledge ;) ). As a result, it is perfectly valid for the
wordpress-4 stream to be built against base-runtime-f26 (brt) or
base-runtime-f27 or both. If the lifecycle of base-runtime-f26 runs out,
that doesn't mean wordpress-4's lifecycle has run out, it just means that
the user must upgrade the base-runtime stream but their application that
relies on the wordpress-4 API will continue to operate unchanged.

I am not saying that updating a brt is not disruptive, but it should not
require code changes to my-wp-app just a replacement of the underlying
components. However, the disruption is just "dnf module enable brt-f27 &&
dnf update and reboot. You may, as a user, actually get new binaries in the
wordpress-4-on-base-runtime-f27 configuration but the wordpress-4 is built
from the same sources and, while not strictly the "same," for 99% of cases
they will be.

As we are able to increase the bundling of components, the 99% continues to
add 9s after the decimal. At present, we must consume the openssl-1.1
branch in brt/shared-userspace because dnf/rpm can't tell that the binaries
provided by different modules are functionally the same. However, as we
improve that or find other methods around this problem (private
namespacing, containers, rpathing, etc), we could have the openssl-1.1
sources in dist-git be included in multiple modules. When the openssl
maintainer elects to add the openssl-1.2 stream, wordpress-4 could decide
if it is appropriately backwards compatible for their use case and consume
it (by changing their modulemd to point to the new stream).

Langdon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: [Modularity]: Service levels and EOL expectations?

[Matthew Miller]

On Mon, Aug 07, 2017 at 02:10:23PM -0400, Stephen John Smoogen wrote:
> I still don't see how this is going to work with a tree of Service Levels
> and Lifetimes. Any module can not give a SL greater than the lowest SL and
> the shortest lifetime that any package in it is going to agree to. [EG if I
> am packaging up a wordpress module and glibc is on a 18 month lifetime but
> openssl is meh upstream always.. then unless I am going to maintain openssl
> myself with its own fork... my module is going to be 'meh upstream always'.
> If my module pulls in enough stuff to make it work, I am going to be
> dealing with the need of a lawyer to figure out which SL's and lifetimes
> are binding and what ones are not.

Yeah, that would get crazy fast. The 6 month granularity proposal
should help *some*, and we should probably go into this carefully.

For packages, the default is to have fNN branches with the implied 13
month lifecycle and 6 month branch/update window. (Which means that
even nearing the end of the 13 month cycle, there's an overlapping
cycle going half a year longer.) 

The Arbitrary Branching proposal suggests not* do this for f28
*automatically (but still allow it). Maybe (at first at least) we need
to say that if packagers want to do *other* cycles, they need to give
at least this "there's a version with an EOL at least 7 months off, and
if you hit it right there's a 13 month window" service level. (That
could be fulfilled by "there's one version that is expected to
continually update in a compatible way".)

Packagers who don't want to deal with all this could just make the
"f28" branch, and packagers who instead want to do something else
longer or additional could.*

Then, we could have an opt-in process (FESCo approval?) for packages
where the upstream changes too fast to support that. (These packages
are presumably problematic in Fedora currently _anyway_.)


* And "longer" sounds like more work, but in many cases it shouldn't
be. I maintain couple of small "leaf" utility programs which are
unlikely to change in a significantly incompatible way, and rather than
maintaining them across "rawhide, f29, f28, f27, el7" I'd like to
maintain just "devel" and "2.stable".

But there's _definitely_ a lot still to work out here!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Stephen John Smoogen]

On 7 August 2017 at 07:50, Matthew Miller  wrote:

> On Mon, Aug 07, 2017 at 07:38:44AM -0400, Josh Boyer wrote:
> > > 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).
>
> There's a big difference between "10 / 1 / 3 years" and "13 months / 18
> months / 17 weeks / 3 years / 7 months / 280 days / 42 weeks / 1 year /
> 160 days / 12 days / 20 months / 13 months (3 months earlier than the
> other 13 months, though) / 6 months".
>
> I think 6 months granularity should be enough; and it doesn't have to
> be specifically tied to a given release cycle... it still could be 6,
> 12, 18, 24, 30.
>
>
I still don't see how this is going to work with a tree of Service Levels
and Lifetimes. Any module can not give a SL greater than the lowest SL and
the shortest lifetime that any package in it is going to agree to. [EG if I
am packaging up a wordpress module and glibc is on a 18 month lifetime but
openssl is meh upstream always.. then unless I am going to maintain openssl
myself with its own fork... my module is going to be 'meh upstream always'.
If my module pulls in enough stuff to make it work, I am going to be
dealing with the need of a lawyer to figure out which SL's and lifetimes
are binding and what ones are not.



>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Matthew Miller]

On Mon, Aug 07, 2017 at 07:38:44AM -0400, Josh Boyer wrote:
> > 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).

There's a big difference between "10 / 1 / 3 years" and "13 months / 18
months / 17 weeks / 3 years / 7 months / 280 days / 42 weeks / 1 year /
160 days / 12 days / 20 months / 13 months (3 months earlier than the
other 13 months, though) / 6 months".

I think 6 months granularity should be enough; and it doesn't have to
be specifically tied to a given release cycle... it still could be 6,
12, 18, 24, 30.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity]: Service levels and EOL expectations?

[Josh Boyer]

On Sat, Aug 5, 2017 at 1:17 PM, Matthew Miller  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Modularity]: Service levels and EOL expectations?

[Matthew Miller]

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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org