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. For packages, the default is to have fNN branches with the implied 13 month lifecycle and 6 month branch/update window. (Which means that even nearing the end of the 13 month cycle, there's an overlapping cycle going half a year longer.) The Arbitrary Branching proposal suggests not* do this for f28 *automatically (but still allow it). Maybe (at first at least) we need to say that if packagers want to do *other* cycles, they need to give at least this "there's a version with an EOL at least 7 months off, and if you hit it right there's a 13 month window" service level. (That could be fulfilled by "there's one version that is expected to continually update in a compatible way".) Packagers who don't want to deal with all this could just make the "f28" branch, and packagers who instead want to do something else longer or additional could.* Then, we could have an opt-in process (FESCo approval?) for packages where the upstream changes too fast to support that. (These packages are presumably problematic in Fedora currently _anyway_.) * And "longer" sounds like more work, but in many cases it shouldn't be. I maintain couple of small "leaf" utility programs which are unlikely to change in a significantly incompatible way, and rather than maintaining them across "rawhide, f29, f28, f27, el7" I'd like to maintain just "devel" and "2.stable". But there's _definitely_ a lot still to work out here! -- 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
