Re: What has the PDC ever done for us?

[Miroslav Suchý]

Dne 18. 03. 22 v 8:26 Tomas Hrcka napsal(a):


> distgit is basically pagure in it has a DB we were thinking about moving
> package-specific data like EOL to in information already stored in the DB
> for each repository.

I cannot parse your sentence. Does it mean there is one database which
stores all the data about all repositories, or does it mean that each
repository has its own database?


Sorry about that. Let me be more clear. distgit is actually pagure-distgit[1] 
that is a plugin for pagure


Which is AFAIK layer on top of the actuall dist-git [3].

[3] https://github.com/release-engineering/dist-git

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Christopher]

On Fri, Mar 18, 2022 at 3:59 AM Petr Pisar  wrote:
>
> V Thu, Mar 17, 2022 at 12:58:54PM -0400, Christopher napsal(a):
> > Even if PDC is the most valuable thing to Fedora composes ever, casual
> > contributors who only work on packaging should never have to care
> > about it.
> >
> You should reavaluate importance of composes. Without a compose no package
> reaches a user.

No, I shouldn't, because I never said composes weren't important. I
was expressing https://en.wikipedia.org/wiki/Separation_of_concerns ;
I don't know how to get anything like "composes aren't important" from
what I wrote.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Petr Pisar]

V Fri, Mar 18, 2022 at 01:24:09PM +0100, Fabio Valentini napsal(a):
> On Fri, Mar 18, 2022 at 8:58 AM Petr Pisar  wrote:
> >
> > V Thu, Mar 17, 2022 at 12:58:54PM -0400, Christopher napsal(a):
> > > Even if PDC is the most valuable thing to Fedora composes ever, casual
> > > contributors who only work on packaging should never have to care
> > > about it.
> > >
> > You should reavaluate importance of composes. Without a compose no package
> > reaches a user.
> >
> > > What is PDC's relevance to packagers?
> >
> > Module EOLs. Without PDC you cannot terminate a support for a module stream.
> > It's like you weren't able to retire an RPM package.
> 
> So you're saying that the *only* thing we really need the PDC for is
> to allow modules to be retired,

No. I say that packagers use PDC for retiring modules. I don't say it's the
only use.

> and that's why you don't want it to go away?

I did not say that at all. I only answered who uses PDC.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Fabio Valentini]

On Fri, Mar 18, 2022 at 8:58 AM Petr Pisar  wrote:
>
> V Thu, Mar 17, 2022 at 12:58:54PM -0400, Christopher napsal(a):
> > Even if PDC is the most valuable thing to Fedora composes ever, casual
> > contributors who only work on packaging should never have to care
> > about it.
> >
> You should reavaluate importance of composes. Without a compose no package
> reaches a user.
>
> > What is PDC's relevance to packagers?
>
> Module EOLs. Without PDC you cannot terminate a support for a module stream.
> It's like you weren't able to retire an RPM package.

So you're saying that the *only* thing we really need the PDC for is
to allow modules to be retired, and that's why you don't want it to go
away?
Given that it's basically unmaintained, and causes problems on a
regular basis, that reason looks very weak to me.
Couldn't those module EOL dates be handled much simpler? I mean, even
a static text file would be a better solution for that than what we
have now.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Petr Pisar]

V Thu, Mar 17, 2022 at 12:58:54PM -0400, Christopher napsal(a):
> Even if PDC is the most valuable thing to Fedora composes ever, casual
> contributors who only work on packaging should never have to care
> about it.
> 
You should reavaluate importance of composes. Without a compose no package
reaches a user.

> What is PDC's relevance to packagers?

Module EOLs. Without PDC you cannot terminate a support for a module stream.
It's like you weren't able to retire an RPM package.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Tomas Hrcka]

On Thu, Mar 17, 2022 at 5:35 PM Petr Pisar  wrote:

> V Thu, Mar 17, 2022 at 04:13:44PM +0100, Tomas Hrcka napsal(a):
> > On Thu, Mar 17, 2022 at 3:09 PM Petr Pisar  wrote:
> > > 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.
> > >
> >
> > distgit is basically pagure in it has a DB we were thinking about moving
> > package-specific data like EOL to in information already stored in the DB
> > for each repository.
>
> I cannot parse your sentence. Does it mean there is one database which
> stores all the data about all repositories, or does it mean that each
> repository has its own database?
>

Sorry about that. Let me be more clear. distgit is actually
pagure-distgit[1] that is a plugin for pagure.
It has its own model definitions[2]. It uses the beefy PSQL server that
most apps use. Currently, we do not store much information about packages.



>
> Is this Pagure/dist-git database publically accessible for reading?
>

No the DB itself but pagure has API.


>
> > This would allow us to use specific EOL for modules.
> >
> In modularity I want to deliver the EOL dates to user's YUM repositories so
> that "dnf module list" can list them and alert users about EOLed module
> stream
> they use (bug #2054662).
>
> We already have a mechanism for delivering the data to the YUM repositories
> <
> https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/module-obsoletes/
> >.
> But the mechanism relies on a manual input
> .
> It's
> manual because one of the purposes if the mechanism is delivering which
> stream
> replaces which one. But the EOL dates could be filled automaticaly.
>
> That's why I'm so obsessed with PDC.
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>

[1] - https://pagure.io/pagure-dist-git/
[2] -
https://pagure.io/pagure-dist-git/blob/master/f/pagure_distgit/model.py
-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Christopher]

On Thu, Mar 17, 2022 at 12:29 PM Adam Williamson
 wrote:
> It stores the metadata of all composes that have been run, ever. (Well,
> when there isn't a bug in the sync, anyway). This is useful in several
> ways:
[snip]

I think a lot of the Fedora infrastructure complexity and difficulty
attracting new packagers is because too much of the compose processes,
which seems very opaque and relatively few people participate in, is
allowed to leak into the packaging processes, in which a lot more
Fedora folks participate.

Even if PDC is the most valuable thing to Fedora composes ever, casual
contributors who only work on packaging should never have to care
about it.

What is PDC's relevance to packagers?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Adam Williamson]

On Thu, 2022-03-17 at 12:34 +0100, Miro Hrončok wrote:
> 
> Where is the sanitation, medicine, education, wine, public order, irrigation, 
> roads, a fresh water system, and public health that the PDC have done for us?
> 
> 
> Serious question: Why do we need PDC? What actual problems does it solve?

It stores the metadata of all composes that have been run, ever. (Well,
when there isn't a bug in the sync, anyway). This is useful in several
ways:

1. It's the best way I know of to figure out what the "previous"
compose was. fedfind implements two ways of doing this, one based on
PDC, one not. Here they are. You judge which is less awful:

https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1293 
(PDC)
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1380 
(not PDC)

2. It's useful if you want to look at the history of, e.g., what
packages were in what composes, or what size images were. The actual
nightly composes are garbage-collected after two weeks, so unless you
have your own stash of their metadata, you cannot find this information
for nightly composes that are more than two weeks old anywhere but PDC.
With the PDC metadata you can chart image sizes or package changes
between nightly composes from five years ago, if you want. Without the
PDC metadata you can only do it for composes we still have around -
final releases, maybe Beta releases - and it's painful even for those
because we don't actually keep the metadata for them in the live trees,
you have to figure out what you want to know from HTTP requests (ugh).

3. It's actually very useful for handling exactly that case of how we
screw up composes when we release them. When we take a compose and
release it as a Beta or Final release, we throw some things away and
move other things around, and because of that, we don't publish the
metadata for it in the repos because it's not exactly correct any more.
But that, well, sucks. If you ask fedfind for the metadata of a final
or Beta release, what it does is find the metadata for the source
compose of that release in PDC, then amend it in a way that reflects
how releng hacked it up, and present you with modified, accurate
metadata:
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1876
it's the path there where we *do* find `origmd` (the path where we
*don't* is for handling releases that were done before Pungi 4 / PDC,
and it provides much less complete, synthesized metadata). Once the
original, unmodified composes have been garbage-collected from
https://kojipkgs.fedoraproject.org/compose/ and
https://dl.fedoraproject.org/pub/alt/stage/ , PDC is the *only* place
you can get this metadata.

4. It's the only way I know of for finding out what the compose ID of a
candidate compose was if all you have is its label. For example, for
the Fedora 36 Beta candidate compose, its compose ID was "Fedora-36-
20220311.0", and its label was "Beta-1.1"; if you want to look up "what
compose was 36 Beta-1.1?" the only solid way to do it is in PDC. This
is kind of esoteric, I guess, but for boring reasons I won't go into
it's something I actually need in the release validation process
automation.

5. It's the most convenient way to look up "what version of packages X,
Y and Z were in compose foo?", which fedfind does here:
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1320
the only alternatives I know of are to parse HTTP requests, which is
awful and doesn't get you epochs, or grab the entire `rpms.json`
metadata for the compose and parse that, which works but it's nearly
200MB, which is a lot to download just to query five packages. And you
can only do those two if the compose hasn't been garbage-collected (see
point 2). We use this and "previous" compose discovery (point 1) in the
release validation event creation code - we query the versions of
several key packages (e.g. anaconda and gnome-shell) in the current and
'previous' composes, and if any of them has changed, we are more likely
to create a new event than if none of them has changed.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Petr Pisar]

V Thu, Mar 17, 2022 at 04:13:44PM +0100, Tomas Hrcka napsal(a):
> On Thu, Mar 17, 2022 at 3:09 PM Petr Pisar  wrote:
> > 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.
> >
> 
> distgit is basically pagure in it has a DB we were thinking about moving
> package-specific data like EOL to in information already stored in the DB
> for each repository.

I cannot parse your sentence. Does it mean there is one database which
stores all the data about all repositories, or does it mean that each
repository has its own database?

Is this Pagure/dist-git database publically accessible for reading?

> This would allow us to use specific EOL for modules.
> 
In modularity I want to deliver the EOL dates to user's YUM repositories so
that "dnf module list" can list them and alert users about EOLed module stream
they use (bug #2054662).

We already have a mechanism for delivering the data to the YUM repositories
.
But the mechanism relies on a manual input
. It's
manual because one of the purposes if the mechanism is delivering which stream
replaces which one. But the EOL dates could be filled automaticaly.

That's why I'm so obsessed with PDC.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Tomas Hrcka]

On Thu, Mar 17, 2022 at 3:09 PM Petr Pisar  wrote:

> 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.
>

distgit is basically pagure in it has a DB we were thinking about moving
package-specific data like EOL to in information already stored in the DB
for each repository.
This would allow us to use specific EOL for modules.


>
> 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 -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.
>

Package EOL is set by releng during the branching process for each package.


>
> > Serious question: Why do we need PDC? What actual problems does it solve?
> >
>

I am asking this question myself for a year, spending some time on
use-cases we have, and creating initiative for the CPE team.
https://pagure.io/cpe/initiatives-proposal/issue/5

The short answer is none and it causes some. And I didn't even start about
that last commit in the project is years ago.


> 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam on the list, report it:

Re: What has the PDC ever done for us?

[Petr Pisar]

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 -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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What has the PDC ever done for us?

[Miroslav Suchý]

Dne 17. 03. 22 v 12:34 Miro Hrončok napsal(a):
Where is the sanitation, medicine, education, wine, public order, irrigation, roads, a fresh water system, and public 
health that the PDC have done for us? 


ABRT uses PDC to (automaticaly) determine which release is active, what Fedora 
versions we have.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

What has the PDC ever done for us?

[Miro Hrončok]

Hello Fedora packagers.

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


2) Rawhide packages have arbitrary EOL dates, such as -01-01.


3) Even many of the modular packages have arbitrary EOL dates because 
maintainers don't know the EOL date beforehand.



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.



5) Many packagers don't know PDC at all, they only observe "random weirdness".



Where is the sanitation, medicine, education, wine, public order, irrigation, 
roads, a fresh water system, and public health that the PDC have done for us?



Serious question: Why do we need PDC? What actual problems does it solve?


[1] https://pdc.fedoraproject.org/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure