Sorry for the confusion with work that is already done,
We can drop the critpath thanks Adam!
As it goes for EoL and package retirement we for the past few releases we are saving EOL date in bodhi.
So getting EOL for specific release is not a problem once the release is out.
For storing the orphaning reason and other potential metadata. We can store some of it in git in form of notes on branches not necessarily in pagure-disgit specific code-base.
With toddlers i think the path is clear we need to use bodhi as a source of truth about releases.
Similar work as on toddlers will need to be done on mdapi
For the compose metadata we can store the the json blobs on fedorapeople for now and search for some stable place.
On Wed, Sep 6, 2023 at 12:23 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
On Tue, Sep 05, 2023 at 11:35:19AM -0700, Kevin Fenzi wrote:
> On Mon, Sep 04, 2023 at 04:51:22PM +0200, Tomas Hrcka wrote:
> > Hello all, it took us a few years but we are finally getting rid of the PDC
> > project. Thanks to the ARC research we identified use cases in our tooling
> > and proposed solution.
> >
> > The essential functionalities currently provided by PDC will be
> > re-implemented in other applications within our release infrastructure, as
> > there are no immediate plans for their replacement and are currently
> > maintained
> >
> > This work is anticipated to span several months for completion. However,
> > before we embark on this endeavor,
> >
> > we would like to proactively share our proposed solution with all of you
> > and gather your valuable feedback.
> >
> > Below, we outline our strategy to preserve the core functionality of PDC by
> > leveraging existing applications within our ecosystem.
> >
> > Current uses of PDC:
> >
> > Currently, we rely on the Package Database (PDC) for various data
> > management tasks, including:
> >
> >
> > 1.
> >
> > Critical Path Package Tracking: Bodhi leverages PDC to track packages on
> > the critical path.
>
> As Adam mentioned this is already not in pdc. ;)
>
> > 2.
> >
> > Retirement of Packages and Service Level Agreements (SLAs): PDC assists
> > in managing the retirement of packages and their associated SLAs.
>
> Yeah. The super big one is that its queried from a git commit hook for
> all src.fedoraproject.org git commits. Right now if pdc is down, no one
> could commit anything.
>
>
> > 3.
> >
> > Metadata for Nightly Composes: Our Release Engineering and Fedora
> > Quality Assurance teams rely on PDC for metadata related to nightly
> > composes.
> >
> >
> > More info on the usage can be found here:
> > https://fedora-arc.readthedocs.io/en/latest/pdc/users.html
>
> mass rebuild of modules can be dropped. ;)
>
> fedscm-admin is now the scm requests toddler. It still uses pdc tho
> of course.
>
> > Specific Endpoints in Use:
>
> ...snip...
>
> > Upcoming Changes
> >
> > Bodhi:
> >
> > Bodhi will assume responsibility for the following tasks, reducing our
> > reliance on PDC:
> >
> > /rest_api/v1/releases/: Bodhi will now manage release-related data.
>
> Do note that bodhi still has a window after we are 'go' for a relase
> where it thinks it's released, but it's not yet. We probibly need to
> address this if we are moving this to bodhi.
>
> > /rest_api/v1/component-branches/: Specifically, Bodhi will handle the
> > critical-path flag.
>
> Already done.
>
> ...snip...
> >
> > Pagure-dist-git:
> >
> > Pagure-dist-git will take over several responsibilities from PDC, including:
> >
> > /rest_api/v1/product-versions
> >
> > /rest_api/v1/global-components
> >
> > /rest_api/v1/component-branches/
> >
> > /rest_api/v1/component-branch-slas/
> >
> > Pagure already has a robust database of global components (repositories)
> > and product versions (repository branches).
> >
> > It utilizes the PDC API to query component branches when a package is
> > retired, and an auxiliary table in Pagure-dist-git will store the reasons
> > for orphaning these components.
>
> So, I know this will work... but it means more closely tying ourselves
> to pagure-dist-git. ;(
>
> With modules going out of the picture, most branches just have the
> release cycle of the fedora or rhel release they are based on, so
> couldn't we just default that somewhere?
In the pkgdb time, the EOL status was basically simply computed from the release
status, ie: what we still have at: https://admin.fedoraproject.org/pkgdb/api/collections
(looks like we should fix the branchname in that json)
but we could just go back to this :)
Pierre
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Tomas Hrcka
fas: humaton
libera.CHAT: jednorozec
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-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/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
