Re: [Modularity]: Service levels and EOL expectations?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
<mattdm@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux