Fedora and PDC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux