On 7 August 2017 at 07:50, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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
<mattdm@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
