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