On Sat, Jul 23, 2022 at 12:23 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Fabio Valentini wrote: > > Given that there's a very long list of affected packages, just > > dropping the package in a few weeks would have disastrous effects on > > Fedora. > > I also see core components of several Editions and Spins on that list, > > so I assume just dropping pcre would also make QA, Release > > Engineering, and various Spin manitainers very sad. > > So far, I agree, but: > > > I would ask you that instead of retiring the package in a few weeks, > > you go through the "proper process" for changes like this. > > That would probably involve steps similar to these: > > > > - announce an official deprecation with Fedora 37 (Self-Contained > > Change proposal) > > - mark all pcre packages as deprecated > > - help other packagers with porting software to pcre2 > > - announce official removal of pcre with Fedora 38 (or 39, or later, > > whenever dropping it would not implode several deliverables of Fedora; > > another Change proposal) > > - actual removal of the package according to schedule laid out in the > > previous step > > I do not agree with that process proposal. In fact, I object to the library > deprecation process as a whole, because it actually prevents people willing > to maintain an old library in Fedora from picking up maintenance. Processes > should never block volunteers from doing the work they sign up to do for > free. I'm not sure why deprecating a package would prevent people from working on it? The only thing that changes by officially deprecating X is that no new packages are allowed into Fedora that still depend on X. > Instead, I am going to say the same thing I always say when people want to > retire a package directly: Please just orphan it instead. Then either > somebody else will take care of the package, or it will eventually > automatically get retired. In this case, it is quite likely that it will be > taken up. (In fact, if nobody else does, I will probably have to take it > because kdelibs3 and kdelibs 4 depend on it.) This sounds like you're mixing up two different things here: 1) Whether the package should be marked as "deprecated", and 2) whether the current maintainers will continue maintaining the package, or if somebody else will pick it up. Those are, while not entirely independent of each other, separate considerations. It would be entirely possible to mark the package as deprecated, but also give it to new maintainers. That would give packages that still require pcre time to migrate, while also preventing new things that depend on pcre from being added. Whether those new pcre maintainers then decide to retire the package a few years in the future will be their decision. Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
