* 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.
I am all for this option because it makes everything public and it is
consistent
with the /tests/ and modules/ namespace approach that has been more recently
introduced. I think that option is actually even attractive.
Just noting...I am not a core developer in this subject but this comes to
mind
as a good way to implement the "branch meta-data storage app".
clime
On Fri, Apr 20, 2018 at 7:34 PM, Pierre-Yves Chibon <pin...@pingoured.fr>
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@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
_______________________________________________
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
