On Sat, Dec 1, 2018 at 10:24 AM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > > > Folks, hi. > > > > Planning for a specific delay for a specific reason is one thing. But > > the same design philosophy reasons that apply to Fedora 31 have > > applied to almost every other Fedora releases, and changing to an > > annual cycle is going to drive people *nuts* when updates for their > > particular critical components get delayed up to 18 months because > > they missed the *current* release and have to wait for the next major > > release for the dependencies to be built up. This especially plays out > > with tools that use many distinct small modules by different authors, > > such as Python. Have you *looked* at what happens if python modules > > are even slightly out of date, and the dependency chain that "pip > > instlal" brings in? > > > > I think the thinking is that you would make these modules and would > just make them available during a release. You put a 12 month lifetime > on each module set you are running and put out updated ones when you > are ready to do so. The modules get retired over time and you are > running your own 'release'. Of course this works better if packagers > team up together and own the module versus trying to do it all > themselves.. which is also assumed but may not have been realized by > the packagers yet :). The problem is maintaining the dependency chain. I tried to do this for "airflow" under Fedora 28, and it became.... painful to try to build chain. I used to do it for RHEL and CentOS 7 for previous releases. But getting the dependencies resolved for very specific python module requirements, and the older and newer versions of critical modules, just got out of hand. I've found it much easier to work from Fedora at or near the bleeding edge of all infrastructure components than to backport mixed versions of individual components for compatibility. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
