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(a)lists.fedoraproject.o
> > rg
> > To unsubscribe send an email to infrastructure-leave(a)lists.fedorapr
> > oj
> >
ect.org