On Thu, 2023-12-07 at 11:41 +0100, Michal Schorm wrote: > 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. > TL;DR; Maybe we should have a flag in the src.fp.o package for the maintainer to request a PR before committing to have a window for review, or like me, the maintainer would like to not be bothered with things that proven package can do by itself . Another thing is some proven packager which wants force the move to autothings , which I don't like use it, ATM, because in my opinion still have many problems . > 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 -- Sérgio M. B. -- _______________________________________________ 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
