Richard W.M. Jones venit, vidit, dixit 2023-12-05 12:03:36: > On Tue, Dec 05, 2023 at 10:35:35AM +0000, Daniel P. Berrangé wrote: > > On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote: > > > > [snip] > > > > > Granted, these are dissimilar to initial Michaels's issue. But how can I be > > > sure that if I touch some of the packages, I won't be told that they were in > > > such state for purpose? > > > > IMHO all changes should be opened as merge requests in pagure. This gives > > the regular package maintainers a window of opportunity to review the > > change before it is merged. If there's no response from the package > > maintainer after a couple of weeks then a proven packager can go ahead > > and approve the merge request. > > > > Essentially proven packagers can follow the same workflow as anyone else > > does for contributing to a package that they are not a (co)maintainer of. > > They just need the extra priv of being able to approve their own MR at > > their discretion. Pushing directly to git, bypassing merge requests, > > should not be required in order to achieve what provenpackagers exist > > to do. Yes. My main point was communication, i.e. the "how", not the "what" of those changes. The "what" may influence the "how", of course. An urgent security fix does not leave time for upfront communication. But there should always be time for communication afterwards. > This workflow doesn't really work for mass rebuilds / mass maintenance > of OCaml packages (I guess it's similar for other language packages). > We want to be able to rebuild or fix all packages that contain OCaml > code, and we have a bunch of scripts to do that including the push and > build in a side tag. That makes it even more important to communicate: you don't want a packager to build into rawhide while your side tag is cooking. Note that "communicate" can be as simple as a commit message "bump for xy mass rebuild" or "fix FTBFS for xy rebuild", maybe together with a link to the announcement. If there was an announcement ... That is something you can do automatically. You only have to take the time *once* to template a proper dist-git commit message. > > At the same time I think it is good to remember that Fedora package > > maintainers should think of themselves as guardians, not owners, and > > thus should expect to receive contributions from others, including > > provenpackagers, doing cleanups to follow Fedora guidelines better. > > Yes indeed. Yes, it goes both ways, and requires communication. That's all. And, just to clarify: I probably wouldn't have reacted the way I did if I hadn't experienced something like that over and over again. And that included quelling test suites completely and other niceties (from various pp's). Michael -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
