On Monday, 25 March 2019 21:45:06 CEST Jason L Tibbitts III wrote: > >>>>> "JC" == Jeremy Cline <jer...@jcline.org> writes: > > > JC> The effort would be a 1-2 line change in the-new-hotness, and > JC> distributing the config to each package repository (some proven > JC> packager could do this easily). > > Well that seems easy enough. We still need the repo for the bugzilla > assignee override thing, but that's fine. One thing at a time. > > I can certainly drop commits into the repositories if that's what's > needed. We would need to define the name and contents of the file, and > the default state for when the file is not present (to perhaps avoid > touching every repository). > > It might also be nice to know what on earth monitoring means for a > module or a container, since the fedora-scm-requests has data for them > but I don't understand what point it has. > > We would also need to change the admin tool which is generating these > files. I think it would speed up its operation a good bit to not have > to mess with this ever-growing repository, so that is a positive. > (Especially since the tool does no local caching and so does a full > clone each time it processes an SCM request). And fedpkg request-repo > would need to drop the --monitor option as it would have no effect. > > So I guess it's more than just a couple of lines that need to change, > but everything outside of the initial new-hotness change and the > monitoring file commits could come later. > > - J<
Any chance this might happen? - A YAML (or TOML maybe) file at the root of the dist-git repo - name to be determined - the-new-hotness can look directly at the file and acts accordingly - some "fedpkg set-monitoring [no-monitoring,monitoring,monitoring-with- scratch]" does the creation and commit of the file - --monitor is retired from fedpkg request-repo - Make monitoring an opt-out only (that is we force all maintainers to run the commands fedpkg set-monitoring no-monitoring after the change if they really want to) No idea what is the admin tool or what does it do. On Tuesday, 26 March 2019 14:53:10 CEST Pierre-Yves Chibon wrote: > > > The original idea, I believe, was to allow for the file to different per > > > branch without breaking the one branch for all releases that many > > > packager like. With modularity and stream branching, the ability to > > > say: "I want PR filled for this version to this branch and for that > > > version to that branch" would be neat, but this means having per-branch > > > information that the-new-hotness will then access and act upon. > > > Having this outside of the dist-git repo was meant to make it easier to > > > tweak this file and have it diverge without having the different > > > dist-git branches diverge. > > > > If this is the reason than I don't think it's good idea to move the > > monitoring file > > to package repository, because the-new-hotness doesn't know which branch > > should be used. > > Right now I'm working on creating PR against dist-git in the-new-hotness, > > but this > > is basic feature and will create PR only against master branch, it's > > than on packager to check, if this is correct. > > The alternative would be to change the format to include the mapping version > -> git branch. > If we could do this in a backward compatible way it'd be great but that's > always kinda hard. > > > Pierre Could we start simple and add a layer of complexity later on? Could we keep all the infos in a single file in the master branch? I guess everyone is ENOTIME, but it would be great to see that issue progress. Best regards, Robert-André _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
