On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > Asking individual maintainers for trivial changes does not scale. The > alternative would be not to address FTBFS and other build issues, maybe > file bugs, and rely on active maintainers instead. The alternative we want to achieve is: (1) write useful commit messages, so the reasons and goal of the proven package's commit would be clear and (2) give the maintainers the possibility to react. E.g. with a PR. No one responded to the PR in a week? Force merge it with proven packager rights. Even though I would want a longer time window and multiple iterations of trying to contact the maintainer, putting the PR up just for a week would make the current situation considerably better than it is. I would expect the maintainers to only react on PRs in three general ways: (1) asking for more information = likely means you haven't explained the commit or the problem well that marks problem on your side (2) rejecting the PR for a good reason = likely means there's a problem with the implementation of your solution. that marks problem on your side (3) coming up with an alternative solution = likely means you haven't thought of package specific approaches You might find out the packager has a better idea how to solve the problem in general. Or you just collaborated nicely. Each way leads to a valuable end, I believe. There may be more ways to react (e.g. not react at all), but for now let's assume they are not significant, as you'd end up anyway using the proven packagers rights to force merge. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Kevin Kofler via devel: > > > Michael J Gruber wrote: > >> I am sick of this. Really. I am so sick of this way of stomping on each > >> others' feet. > > > > My pet peeve is provenpackagers or comaintainers who add unwanted > > automagic (autorelease, autosetup, autochangelog) to my packages. I do > > not want any of that in my packages, it just makes my work harder (or > > in practice, just wastes my time for the revert that I am inevitably > > going to do). > > If the package does not contain any patches yet, it's not really > possible to infer the maintainer intentions. %setup vs %autosetup > doesn't matter much in that case, so it doesn't really tell us anything. > Likewise if the package uses %autosetup, but without -p1, and there are > no patches. Does the maintainer really prefer those awkarward -p-less > patches? We don't know. > > Asking individual maintainers for trivial changes does not scale. The > alternative would be not to address FTBFS and other build issues, maybe > file bugs, and rely on active maintainers instead. But I don't think > that can work for Fedora, practically speaking. Fedora lacks Debian's > ban on forcing packagers to do certain work. In the past, FESCo has > used that to order that certain packagers must keep carrying out certain > work they do not want to do, but I think that only means anything if the > victim packager is a Red Hatter on certain teams, I think. Others will > just quit if they disagree. > > Thanks, > Florian > -- > _______________________________________________ > 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 -- _______________________________________________ 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
