On Thu, 2018-05-17 at 10:09 +0800, Chenxiong Qi wrote: > Hi, is it too late? I want to help as well. > Hello, I just realized the part "is it too late?" could be ambiguous and confuse people. Sorry for my poor English. I just meant I want to help. :) Regards, Chenxiong Qi > 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-definiti > > on > > -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@lists.fedoraproject.o > > rg > > To unsubscribe send an email to infrastructure-leave@lists.fedorapr > > oj > > ect.org _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
