V Thu, Mar 17, 2022 at 12:34:52PM +0100, Miro Hrončok napsal(a):
> What has the PDC [1] ever done for us? It only bough pain and misery to me
> for no apparent benefit.
>
>
> 1) When we retire packages in dist-git, PDC creates another layer of delay
> between dist-git and Koji and another place when synchronization regularly
> breaks.
>
> dist-git retirement -> PDC retirement -> block in Koji
>
Maybe dist-git retirement was supposed to disappear, to unify with modules
work flow:
PDC retirement -+-> block in Koji
+-> block in dist-git
Having the dist-git retirement as a primary source of truth has the problem
that you need to clone a dist-git branch to get the data. And then for each
package you are interested again and again. Whereas PDC, being a database
underneath, have the data centralized at one place, and readily available in
no time.
Also dist-git retirement provides only a binary information: Is this specific
branch supported, or is it retired now? In contrast, in PDC you can have
future dates: This branch will be EOLed on that day. That's not important for
packages because they inherit the dates from Fedora release, but in case of
modules they are pretty indepenent, and unique, hence this feature is
important. E.g. I used it last two weeks pretty heavily when I, instead of
relents, was rebuilding all modules for Fedora 37. Without looking into PDC
I would have no clue whether a maintain wants that module in Fedora 37, or
not.
Also don't forget that unretiring packages works differently from the
retirement:
PDC unretirement -+-> unblock in Koji
+-> unblock in dist-git
In practise you need to file an unretirment request to relengs queue in
Pagure. You cannot drive it from dist-git. And once the request is fulfilled,
you need manually to remove the retiring commit. What will happen if
a packager does not revert it? Will we have infrastrucutre in an inconsistent
state?
In the end, PDC-first work flow is symetric and does not clutter dist-git with
dead_package files.
> 2) Rawhide packages have arbitrary EOL dates, such as 2222-01-01.
>
> 3) Even many of the modular packages have arbitrary EOL dates because
> maintainers don't know the EOL date beforehand.
>
That means there is a need for un undefined/missing EOL which should be
interpreted as "supported at any time you ask for". Once known, the EOL date
can be changed. Relengs have a template for it in their Pagure queue.
> 4) Packages for branched Fedoras have "epxected" EOLs, such as 2022-11-26
> for Fedora 35. Repeatedly, this has prevented packagers from updating their
> packages in soon-to-EOL Fedoras when the date of EOL was changed, but not in
> PDC.
>
I lived under impression that package EOLs are inherited from Fedora prodcut
release. Not only as work flow but also as implementation in PDC. Hence the
date is not multiplicated for each package in PDC.
> Serious question: Why do we need PDC? What actual problems does it solve?
>
You should ask sochotni. I think he was at design of the service.
I think a purpose of PDC was to handle release life cycle from the product top
level to RPM components on the bottom level. But Fedora has never onboarded to
that. Mainly because there was a huge migration to Pagure at the same time
and relengs had hands full of work on it.
(A sideway rant: And now when Pagure more or less caught feature parity of the
previous solution, we are going to abandone it. It reminds me a plague of
Linux desktop environments.)
Maybe if don't need PDC for handling EOLs, do we actually need blocking
retired packags from dist-git and Koji? What's the point?
-- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
