11:37 a.m.
Hi Kevin,
On 4/12/24 11:45, Kevin Fenzi wrote:
On Thu, Apr 11, 2024 at 03:41:02PM -0500, Michel Lind wrote:
> Hi all,
>
> With the recent EOL of the Django 3.2 LTS series[^1], and Django being a
> key component of our mailing list infra for both Fedora and CentOS, I
> would like to propose the following plan to maintain Django in both
> Fedora and EPEL:
>
> - Fedora: `python-django` maintained as currently, not tracking any LTS
> series
> - **but** also fork off `python-django` each time it hits an LTS
> series to make a new `python-djangoX.Y` (e.g.
> https://bugzilla.redhat.com/show_bug.cgi?id=2274198)
> - LTS packages are introduced in Fedora first, until they either reach
> EOL or no longer build, at which point they are retired in Rawhide.
> See below for the EOL case.
> - EPEL: we will only branch LTS packages (as is the case now, with
> `python-django3` - though under the new naming scheme it should have
> been `python-django3.2`)
> - Handling EOL
> - not an issue for `python-django` - we just keep rebasing it
To be clear, in fedora right? There wouldn't be a bare python-django in
EPEL?
Correct. There is no bare python-django in epel8 and epel9 currently and
I don't plan to introduce one. There is /unfortunately/ one for epel7, but
happily that will go EOL soon.
> - for LTS releases in Fedora, retire in Rawhide if the
series will
> EOL before the EOL of the upcoming Fedora release
> - for LTS releases in EPEL, once it is EOL (like `python-django3`)
> we mark it as `Provides: deprecated()` and retire it if there is a
> replacement that works with add-on packages, *and* there is a CVE
> that is not fixed
> - Package ACL: cc-ing the current maintainers of python-django here.
> Please let me know if
> - you want to be added to the LTS packages as well
> - you want to be removed from python-django
> - you're not currently involved but want to help out
> - I'll also add infra-sig to the ACL for the LTS packages, as in
> practice they might need access to fix any issue affecting Mailman
>
> The different Django stacks are in the process of being updated so they
> can be swapped without affecting dependents, by providing and
> conflicting with the virtual `python-django-impl`; not only will this
> allow us to swap one Django LTS for another in EPEL when the older one
> EOLs, but it also allows those with dependencies that are not qualified
> for the latest Django to swap to the LTS in Fedora
>
> Let me know if this makes sense, or if you have ideas of how to handle
> some of these better.
I think it does make a lot of sense. ;)
On the epel side, it would be good to make some noise/announce when a
LTS one is marked deprecated and when it's retired, since 3rd parties
might be using it for the external stuff even if everything in EPEL
moves to the new one.
Good point! That's also a reason I marked it as deprecated only (and
don't
plan on removing it immediately even when python-django4.2 is in epel9).
I'll add concern for external usage as an explicit consideration.
Would a EPEL package moving to a new LTS release need
exceptions/announcements also? I mean, ideally it doesn't matter, but it
would be a large version jump, even if the dependent package didn't
change otherwise. Also, there might be cases where the dependent package
does have to change... ie, foo-1.0 works with django-3.2, but when 4.2
lands you have to upgrade to foo-2.0 to work with it?
Exceptions, not in most cases where it's a no-op. But in case the package
needs to be updated, I expect it needs an incompatible update exception, yes.
We might want to consider a single announcement when the old LTS is already
deprecated and we can't hold off on rebuilding packages where the old versions
don't work with the new LTS yet, but otherwise, we probably should only do
incompatible upgrades if something needs the new version (e.g. our mailman stack)
Anyhow, I think this is a pretty reasonable process, but we should make
sure and communicate it very well, document it and make sure epel
steering comittee is happy with it.
Agreed. I filed https://pagure.io/epel/issue/271 so we can discuss it tomorrow.
Thanks,
--
_o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2