Hello,
please include me in the planning too. I happen to know Django and PDC
a bit, and want to help.
Lubomír
Pierre-Yves Chibon píše v Pá 20. 04. 2018 v 19:34 +0200:
> Good Morning Everyone,
>
> We have been informed thst week at the upstream devs working on the
> product-definition-center (PDC) are moving away from the project and
> are going to leave it without a maintainer. Since we adopted PDC for
> a variety of data flows, this puts us in an awkward position. :(
>
> Ralph and I met up on Tuesday to brainstorm the list of things we
> actively use PDC for today and to come up with a contingency plan for
> how to handle them. One overarching option is for us (fedora-infra)
> to take ownership of the PDC codebase as a whole. We didn't fully
> explore this option, figuring that the codebase is large and contains
> lots of tables, endpoints, and codepaths that we didn't use nor which
> we plan to use.
>
> Instead, below we've got the four things we use PDC for and some
> options for what to do with each.
>
> With the exception of /modules/, one common pattern that we like is
> to investigate splitting out the "django apps" that make up PDC into
> their own projects. We're calling these "pdc-lite", for fun. See
> more below.
>
> * Modules
> The data in the /modules/ PDC endpoint is *also* in the MBS
> db. Ralph's team is going to just use that and stop using pdc
> anything for modules.
> We're going to need to patch pungi, mbs for local builds, and a
> few other places. This should be a relatively low-pain transition.
>
> * Stream branches, branch ownership, retirement dates?
> - SLA/EOL are currently stored in PDC.
> - Queried by releng scripts for retirement, fedrepo-req for new
> branches, etc..
> option #1
> git repo full of yaml file similar to the override repo
> compiled into a single JSON blob
> Single place for all retired packages
> This feels like the lowest tech option.
> git gives us change control for free... but people easily get
> lost in the
> "UX" of navigating a gigantic git repo full of plaintext files.
> option #2
> pagure's DB/API
> pagure knows nothing about branches currently, so that would be
> bigger
> lift
> option #3
> PDC internally is composed of ~20 "django apps"
>
https://github.com/product-definition-center/product-definition
> -center/tree/master/pdc/apps
> We could pick the 2 or 3 that comprise the branches feature,
> copy them
> out, and turn them into their own service: the "branch
> definition center":
> BDC.
> That would be the "pdc-lite" approach mentionned above, ie: PDC
> with only
> the "app" of interest
>
> * release/life-circle tracking?
> option #1:
> PDC lite with just that app of interest
> option #2:
> JSON/yaml file on the proxies
> option #3:
> pkgdb-lite
> option #4:
> ???
> compose tracking?
> impacted: fedfind
> option #1:
> PDC-lite with just that app of interest
> option #2:
> Drop this entirely?
> Adam probably really wants to keep the record of composes.
> option #3:
> ???
>
> The "pdc-lite" options are attractive, across the board. One thing
> we get from this is greater clarity when discussing things formerly
> in PDC. If something is in the branch-definition-center, the
> compose-definition-center, or the release-definition-center.. you
> know what you're talking about. Today, when talking about whether or
> not something should be or is in "PDC", it is easy to get confused.
>
> I propose we start the discussion on the list and plan for a meeting
> sometime late next week to discuss it further with the interested
> parties (please signal yourself)
>
>
> What do you think?
>
> Pierre and Ralph
>
> _______________________________________________
> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproj
>
ect.org