On 7 August 2017 at 07:50, Matthew Miller <mat...@fedoraproject.org> 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 > <mat...@fedoraproject.org> > 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
