Hi, is it too late? I want to help as well.
On Fri, 2018-04-20 at 19:34 +0200, Pierre-Yves Chibon wrote:
> 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