On 04/25/2017 07:48 PM, 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.
One problem I can see with this approach is that only commiters of
Pagure repo could change the file, while currently any member of
packager FAS group can change Koschei flag for any package. But that
could work if provenpackager policy explicitly allowed changing this
file directly, without filing bugs and waiting for maintainer response.
1. Revert to using Koschei's own package tracking mechanism. Koschei can
be deployed in environments without PkgDB and therefore it has its own
way for enabling package rebuilds.
2. Drop the flag and enable Koschei for all packages in all collections.
In the past I would vote for this solution, but with current modularity
efforts I'm not sure if we have enough builder capacity to do this.
Software Engineer, Red Hat