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.