|
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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
