On 04/25/2017 08:16 PM, Ralph Bean wrote: > On Tue, Apr 25, 2017 at 07:59:46PM +0200, Mikolaj Izdebski wrote: >> 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. > > True. Also, allowing pull-requests over dist-git with pagure would > help smooth the process. Even if a drive-by packager couldn't set the > flag on their own, they can *almost* set the flag on their own.
You are very optimistic about maintainer responsivnes :) My experience shows that there are lots of packages without active maintainers, which are kept alive only by provenpackagers. Koschei is especially useful for this kind of packages as it allows others (usually SIGs or maintainers of dependant packages) to monitor and keep such de-facto-orphaned packages buildable, which prevents their removal from distro. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
