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@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
