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. Alternative solutions: 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. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
