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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to infrastructure-leave@lists.fedoraproj > ect.org _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
