On Tue, Apr 25, 2017 at 07:56:06PM +0200, Michael Šimáček wrote: > > > On 2017-04-25 19:48, Ralph Bean wrote: > >On Tue, Apr 25, 2017 at 06:46:40PM +0200, Mikolaj Izdebski wrote: > >>On 04/25/2017 04:23 PM, Pierre-Yves Chibon wrote: > >>>- Store koshei integration flag > >>> - store this in a yaml/toml file in the dist-git repo > >>> - let the consumers > >>> - do an http request to retrieve the file > >>> - listen to fedmsg to catch changes to this file (and update a local > >>> cache based on this) > >> > >>Do you mean separate yaml/toml file per package/collection, stored in > >>dist-git branch, right next to spec file? > > > >Yeah. We would introduce some yaml/toml file alongside the spec file > >in git, in branch. > > > >We figured it could be done one of a few different ways: > > > >- Consumers could only consider the 'master' branch. Whatever is in > > rawhide is true for the package across the other branches. > >- Consumers could consider each branch independently. This could let > > koschei have new fine-grained on/off values for different releases. > > Not sure if that's something we actually want, though. > > > > Koschei flag in pkgdb was implemented because people thought it's more > natural to have all the package settings in one place (pkgdb). But koschei > can keep track of it's packages by itself (it has a view for adding > packages, it's just not visible when pkgdb integration is on). So if pkgdb > goes away, it can return to old behavior of keeping the koschei flag in > koschei itself. This works! No objection from me. Note, we still have to solve the same problem for the-new-hotness settings, which doesn't have a UI such as koschei's.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
