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)
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.
>>
>>
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.
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
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
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
> 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
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
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
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
> > >
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
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
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
13 matches
Mail list logo