Re: Proven to be sickened
On Mon, Dec 11, 2023 at 08:28:31AM -0500, Stephen Gallagher wrote: > > While I generally agree that a merge request is a more polite and > elegant solution, if a package is listed as FTBFS (having had a bug > automatically opened) and some reasonable amount of time (two, three > weeks?) has passed, then I think it's perfectly reasonable to assume > that the maintainer is vacant (either entirely or because they lack > the available time to deal with it at this point). In that case, I > don't see it as a problem to jump in and fix the package as a > provenpackager if the fix is relatively minor (yes, this is > subjective). I'd hesitate at rebasing to a new version, but if the > issue is that a dependency changed its name or the newest gcc made a > warning into an error, I think that's a perfectly acceptable fix to > make. The ideal case is for it to go through a merge request, but if > the package happens to be blocking other work, I think expediency is > completely warranted. I think the key here is that everyone needs to make sure and communicate with others. If there's a FTBFS bugzilla bug and you are working on a good fix with upstream, say so in the bug. If you are a provenpackager and you need to fix a FTBFS quickly for some reason, look at the bug, if you see the maintainer(s) mentioning they were working on it, ask in bug if you could push a quick fix now and explain why you need it. Use good commit messages. "Fix FTBFS" is not a good commit message, "Fix FTBFS with a quick fix to xyz because we need to rebuild the package for rebuild of package X, this may not be the final fix". Use the packagename-maintainers aliases and notify when you are doing things. Even if everyone doesn't have time to react to communications, just making the effort helps everyone know what happened and whats going on. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Sun, Dec 10, 2023 at 9:49 PM Gary Buhrmaster wrote: ... > > FTBFS issues are, admittedly, complicated, but > such updates SHOULD be via a PR. If a PP wants > to claim they cannot follow that process, they need > to demonstrate that a particular packager is not > responsive (there is a process for that) rather > then just deciding themselves it is too much trouble. While I generally agree that a merge request is a more polite and elegant solution, if a package is listed as FTBFS (having had a bug automatically opened) and some reasonable amount of time (two, three weeks?) has passed, then I think it's perfectly reasonable to assume that the maintainer is vacant (either entirely or because they lack the available time to deal with it at this point). In that case, I don't see it as a problem to jump in and fix the package as a provenpackager if the fix is relatively minor (yes, this is subjective). I'd hesitate at rebasing to a new version, but if the issue is that a dependency changed its name or the newest gcc made a warning into an error, I think that's a perfectly acceptable fix to make. The ideal case is for it to go through a merge request, but if the package happens to be blocking other work, I think expediency is completely warranted. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Sun, Dec 10, 2023 at 5:39 PM Sérgio Basto wrote: > 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 . I think there is a difference between changes that have a formal change proposal (I am thinking something like removing make from the buildroot, which required many packages to add a BR: make, and for which PP's did a lot of the work for some packages), for which packagers were given a sufficient period of time to make the change on their own, and "philosophical"/"syntactical sugar" changes, such as the current "autothings", for which there is not an approved change for all packages (FD: I would object to making the "autothings" mandatory). If a proven packager changes the syntactical sugar without agreement by the current packager via a PR they have exceeded their mandate, and should be (first) asked to revert and formally apologize, and if they repeat such, removed from the PP list (fool me once, shame on you, fool me twice shame on me). FTBFS issues are, admittedly, complicated, but such updates SHOULD be via a PR. If a PP wants to claim they cannot follow that process, they need to demonstrate that a particular packager is not responsive (there is a process for that) rather then just deciding themselves it is too much trouble. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Thu, 2023-12-07 at 11:41 +0100, Michal Schorm wrote: > On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer > 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 > 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@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > 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@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: >
Re: Proven to be sickened
On Thu, Dec 7, 2023 at 3:26 AM Michal Schorm wrote: > I'd advise to create PR - wait week or 2, > if left without response - create BZ for the specific PR as not > everyone watches PRs and PR notifications, and wait week or two, > if left without response - send a direct mail to the package maintainer. > Any automation around a notification workflow like this would be helpful. I've been using the dist-git PR flow and find it very useful. Once I learned how to use fedpkg to do most of the work for me (i.e. `fedpkg fork`, etc.), it usually feels like maintaining my existing packages. Where I have felt the process lacks is automated coordination with the package maintainers. -- Jonathan Steffan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
Am 02.12.23 um 09:46 schrieb Michal Schorm: In my experience through the years, I've found very little proven packagers that would work in what *I would see* as the right way. I fully agree with you but I wanted to mention Miro + the Python team. From my experience in the Python packaging space it works pretty well there. I regularly see new PRs by the "Python wranglers" for packages I (co-)maintain even though (technically) they could just push directly. Felix -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer 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 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé wrote: > 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. Well said. I'd advise to create PR - wait week or 2, if left without response - create BZ for the specific PR as not everyone watches PRs and PR notifications, and wait week or two, if left without response - send a direct mail to the package maintainer. But having at least the PR and a useful commit message would be much appreciated. > 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. In the case of Fedora, for any part of the project - we should expect to receive contributions. I'd also level up and say, we all should encourage contributions to any part of Fedora. Every maintainer may be in for a different goal, so it may not be applicable to everyone, but I like the parable to maintainer being more of a guardian. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, Dec 5, 2023 at 11:36 AM 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. > > 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. > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
* 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
Richard W.M. Jones venit, vidit, dixit 2023-12-05 12:03:36: > On Tue, Dec 05, 2023 at 10:35:35AM +, 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Tue, Dec 05, 2023 at 10:35:35AM +, 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. 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. > 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
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. 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. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
Dne 05. 12. 23 v 5:56 Jason Tibbitts napsal(a): Kevin Kofler via devel writes: My pet peeve is provenpackagers or comaintainers who add unwanted automagic (autorelease, autosetup, autochangelog) to my packages. That really shouldn't be happening for anything which wasn't officially made mandatory or forbidden or whatnot. Sure, I went through and removed Group: tags long ago, and the same was done for ldconfig scriptlets and such, but that was only after the whole thing had gone through the change process. I can't imagine it would be appropriate for a provenpackager (who isn't also explicitly listed as a maintainer for a specific package) to just make a fundamental change to package maintenance like that with no discussion. I would think that if it did happen, it would definitely warrant an apology. I just want to say that during my proven packager years, I certainly did substantial changes to other's packages, but I was pretty sure that the package was not maintained by anybody except proven packagers. I still find surprising, that we can have packages like that. E.g. looking at https://src.fedoraproject.org/rpms/rubygem-json/commits/rawhide How comes the package was not orphaned by some automated process yet, to find a rightful maintainer? Can we also make a rule that if package reaches e.g. release 10 with only mass rebuild commits, it will be orphaned? I have a few examples at hand: https://src.fedoraproject.org/rpms/rubygem-ansi/commits/rawhide https://src.fedoraproject.org/rpms/rubygem-daemons/tree/rawhide https://src.fedoraproject.org/rpms/rubygem-elasticsearch-transport/commits/rawhide I am not going to continue, but from these 3, the rubygem-daemons looks reasonable (but without enabled test, so nobody can tell if the package works) to today standards, because it was touched by proven packager years ago. How I know about these cases? Because from time to time I look at the packages which are not migrated to SPDX yet. Will these be migrated? I don't think so. Should proven packagers do that? There are also cases such as https://koschei.fedoraproject.org/package/rubygem-async_sinatra which is FTBFS for a while already. Should I fix the package as a proven packager knowing it is broken (also knowing the reasons for the breakage and the fix should not be hard), or should I leave it, because it does not seems to be maintained, while I don't think the maintainer is completely inactive. 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? Sorry for bit of OT. Vít But, fixing bugs and FTBFS issues? That's absolutely part of what we would expect provenpackagers to be doing. - J< -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
> Kevin Kofler via devel writes: > My pet peeve is provenpackagers or comaintainers who add unwanted > automagic (autorelease, autosetup, autochangelog) to my packages. That really shouldn't be happening for anything which wasn't officially made mandatory or forbidden or whatnot. Sure, I went through and removed Group: tags long ago, and the same was done for ldconfig scriptlets and such, but that was only after the whole thing had gone through the change process. I can't imagine it would be appropriate for a provenpackager (who isn't also explicitly listed as a maintainer for a specific package) to just make a fundamental change to package maintenance like that with no discussion. I would think that if it did happen, it would definitely warrant an apology. But, fixing bugs and FTBFS issues? That's absolutely part of what we would expect provenpackagers to be doing. - J< -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Tue, Dec 5, 2023 at 3:48 AM Kevin Kofler via devel wrote: > 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). I do not have a dog in this particular fight, but I do have a strong belief that the primary developer of a package, or the primary admin of a package, gets to decide the syntactical "sugar" of the code(s) involved (I have seen PR's based on capitalization styles, and indentation styles, too). Those that want to change those need to arrange to take formal ownership of the development codes and/or packaging before they get change what the primary has decided to do. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
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). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Fri Dec 1, 2023 at 16:26 +0100, Michael J Gruber wrote: > So, due to me following my package (notmuch) upstream and testing early > against upstream's git, reporting and working with upstream, I noticed a > FTBFS and helped fixing it. Nothing urgent since it was basically just a > test failing for the wrong reasons. > > Why? For a FTBFS due to a test? No bugzilla, no FTI, no security issue > whatsoever? FTBFS/FTI bugs are considered serious Unhandled issues[1] that provenpackagers are deputized to fix. The package FTBFS and merging the Ruby update side tag without fixing the FTBFS would've caused it FTI and broken other packages. One of these is aerc which I help maintain, so I'm happy that Mamoru took the time to fix it. Many packagers view FTBFS bugs as low priority issues, but when they're not addressed, they can cause larger issues that affect other packages in the distribution. > Dunno whether it's the new fmn or what. That works for *my* actions with > pagure/bodhi/koji but fails to report copr actions to me, and > apparently also actions by others. Yeah, you may have to go to https://nofications.fedoraproject.org and readjust your settings. [1]: https://docs.fedoraproject.org/en-US/fesco/Who_is_allowed_to_modify_which_packages/#unhandled_issues -- Best, Maxwell G (@gotmax23) Pronouns: He/They -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Fri, Dec 01, 2023 at 03:41:54PM -0600, Jason L Tibbitts III wrote: [snip] > If there isn't anything wrong with the work of the other maintainer, > then I guess I don't understand. They did something in an honest > attempt to save you the trouble and because of unfortunate timing they > didn't actually save you any trouble. But you aren't in a different > position than if they hadn't tried to help. (Excluding the time it took > to start this discussion, of course.) I'm very much with Jason on this… It's a nice clean fix to FTBFS. If the maintainer did some work in parallel, then in the worst case they need to do a git pull and remove the patch. In general, I'd be very happy if somebody fixed an issue in one of my packages. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
In my experience through the years, I've found very little proven packagers that would work in what *I would see* as the right way. I too despise random interventions from the higher power to my packages. I rejoiced when the new process of removing inactive proven packagers took place. And I'd love to see the proven packagers losing their rights regularly for breaking the guidelines. (Especially when there's nothing much stopping them to request the proven packager status again and again, but I hope in the small PITA of doing that might give them time for a reflection on why they lost it and try better next time) "Prior to making changes, provenpackagers should try to communicate with owners of a package in bugzilla, dist-git pull request, IRC, matrix, or email. They should be careful not to change other people’s packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in Who is Allowed to Modify Which Packages." https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ In this particular case, if the commit was urgently needed by the proven packager, I'd expect at least an explanation in the commit message, what bigger whole this is part of (link to BZs or Fedora change, or something). If it wasn't urgent, I'd say PR would be in place instead. (with the same reasoning included in the commit message) I was raised (as a maintainer) watching closely the proven packager 'praiskup', which uses his powers conscientiously like no other proven packager I've ever experienced. Especially early in my packager career, I've gone to him many times, asking for proven packager intervention that would come handy to me. I was refused every time, with a good explanation of the processes I should take before residing to the very last option - the proven packager intervention. It taught me a lot. Through the years I was even thinking about becoming a proven packager myself several times. However I haven't requested it in the end, because, even when I did changes across dozens and dozen of packages, there was never ever a time, where I would *need* to reside to the proven packager powers to get my work done, as the standard ways of contacting regular owners of the packages before that always worked. (PR then BZ, then mail, then mailing list. I haven't even needed to activate 'Policy for nonresponsive package maintainers'.) But I have a strong feeling the proven packagers powers are commonly used because they are handy, instead of them being necessary. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Dec 1, 2023 at 11:35 PM Mamoru TASAKA wrote: > > Sérgio Basto wrote on 2023/12/02 0:49: > > On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote: > >> So, due to me following my package (notmuch) upstream and testing > >> early against upstream's git, reporting and working with upstream, I > >> noticed a FTBFS and helped fixing it. Nothing urgent since it was > >> basically just a test failing for the wrong reasons. > >> > >> Within a few days, upstream releases a patch release. Within hours, > >> I'm testing (again, since it's basically what was on git already) on > >> copr and koji, writing a nice commit message, push to rawhide ... > >> > >> ... and get a reject because someone thought that pushing directly > >> without asking or at least notifying the maintainer would be in > >> order: > >> > >> https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide > > > > > >> Why? For a FTBFS due to a test? No bugzilla, no FTI, no security > >> issue whatsoever? > >> > > > > You may kindly ask to mtasaka why did it ? , and also alert him that > > package is well maintain and have a quick response and kindly ask to do > > PR instead , he is one provenpackager and I sure that he did that in > > hope of improve the package, I'm sure that he will understand. > > > > Best regards, > > So to explain, notmuch was FTBFS. > And we are going to rebuild packages which depends on libruby.so.3.2 as > announced as: > > https://fedoraproject.org/wiki/Changes/Ruby_3.3 > > We are testing beforehand whether packages can rebuild against new ruby > beforehand, and trying to fix **just** FTBFS beforehand because if the package > has FTBFS anyway (regardless of whether the reason is related to ruby or > not, such package will have broken deps after mass rebuild). > > notmuch is this target. > > Regards, > Mamoru > > > > > > > > >> I am sick of this. Really. I am so sick of this way of stomping on > >> each others' feet. > >> > >> It's made worse by failing automated notifications, of course. Not > >> from pagure about the push nor from koji about the build nor from > >> bodhi about the update. > >> > >> Dunno whether it's the new fmn or what. That works for *my* actions > >> with pagure/bodhi/koji but fails to report copr actions to me, and > >> apparently also actions by others. > >> > >> Thanks for
Re: Proven to be sickened
Sérgio Basto wrote on 2023/12/02 0:49: On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote: So, due to me following my package (notmuch) upstream and testing early against upstream's git, reporting and working with upstream, I noticed a FTBFS and helped fixing it. Nothing urgent since it was basically just a test failing for the wrong reasons. Within a few days, upstream releases a patch release. Within hours, I'm testing (again, since it's basically what was on git already) on copr and koji, writing a nice commit message, push to rawhide ... ... and get a reject because someone thought that pushing directly without asking or at least notifying the maintainer would be in order: https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide Why? For a FTBFS due to a test? No bugzilla, no FTI, no security issue whatsoever? You may kindly ask to mtasaka why did it ? , and also alert him that package is well maintain and have a quick response and kindly ask to do PR instead , he is one provenpackager and I sure that he did that in hope of improve the package, I'm sure that he will understand. Best regards, So to explain, notmuch was FTBFS. And we are going to rebuild packages which depends on libruby.so.3.2 as announced as: https://fedoraproject.org/wiki/Changes/Ruby_3.3 We are testing beforehand whether packages can rebuild against new ruby beforehand, and trying to fix **just** FTBFS beforehand because if the package has FTBFS anyway (regardless of whether the reason is related to ruby or not, such package will have broken deps after mass rebuild). notmuch is this target. Regards, Mamoru I am sick of this. Really. I am so sick of this way of stomping on each others' feet. It's made worse by failing automated notifications, of course. Not from pagure about the push nor from koji about the build nor from bodhi about the update. Dunno whether it's the new fmn or what. That works for *my* actions with pagure/bodhi/koji but fails to report copr actions to me, and apparently also actions by others. Thanks for listening ... Michael -- -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
Jason L Tibbitts III venit, vidit, dixit 2023-12-01 22:41:54: > So I've been in this situation, both on the receiving end of nasty flames > because I dared touch someone else's package and having duplicated work > because I didn't check before trying to update something. > > > Michael J Gruber writes: > > > So, due to me following my package (notmuch) > > The idea is that it's really the community's package, but you have > indicated that you will take a primary role. That doesn't mean that > nobody else will ever touch the package. Communication is encouraged, > of course. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity > > > ... and get a reject because someone thought that pushing directly > > without asking or at least notifying the maintainer would be in order: > > This is collaborative maintenance. Occasionally you get ninja'd. It > happens. Certainly it's annoying when it happens but it's not evidence > that anyone did anything wrong. > > If there is something wrong with the work of the maintainer who got > there before you did, then you can always push a revert, bump and build > your own copy. And of course have a discussion with them. > > If there isn't anything wrong with the work of the other maintainer, > then I guess I don't understand. They did something in an honest > attempt to save you the trouble and because of unfortunate timing they > didn't actually save you any trouble. But you aren't in a different > position than if they hadn't tried to help. (Excluding the time it took > to start this discussion, of course.) > > > I am sick of this. Really. I am so sick of this way of stomping on > > each others' feet. > > I can only say that the best thing to do in this situation is to say > "thanks; would you mind sending me a note on [IRC|Matrix|email] in the > future so we don't duplicate effort?" and move on. Surely it's not > worth strong emotions. > > > It's made worse by failing automated notifications, of course. Not > > from pagure about the push nor from koji about the build nor from > > bodhi about the update. > > Now that is a true issue, and perhaps the real underlying issue here. > If you invested time that you didn't need to invest because you didn't > receive a notification that the work had already been done, then that is > problematic. And yes, it would be incredibly beneficial to > collaboration if that were fixed, if only because it would help to > prevent situations such as the one under discussion. But please don't > take that out on the person who had no motivation other than to help you > out. You are all missing the point that this is not about a (co-) maintainer but a proven packager. And that "regular maintainership" is not what this role is for. And it's definitely not what most of them do. Even as (co-)maintainer I see this as team work, at least among those who signal interest. If "main admin" doesn't signal that then what does? But hey, I can learn, such as not to care either. Just push and build where you have access. So much easier. Done with this for now. Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
So I've been in this situation, both on the receiving end of nasty flames because I dared touch someone else's package and having duplicated work because I didn't check before trying to update something. > Michael J Gruber writes: > So, due to me following my package (notmuch) The idea is that it's really the community's package, but you have indicated that you will take a primary role. That doesn't mean that nobody else will ever touch the package. Communication is encouraged, of course. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity > ... and get a reject because someone thought that pushing directly > without asking or at least notifying the maintainer would be in order: This is collaborative maintenance. Occasionally you get ninja'd. It happens. Certainly it's annoying when it happens but it's not evidence that anyone did anything wrong. If there is something wrong with the work of the maintainer who got there before you did, then you can always push a revert, bump and build your own copy. And of course have a discussion with them. If there isn't anything wrong with the work of the other maintainer, then I guess I don't understand. They did something in an honest attempt to save you the trouble and because of unfortunate timing they didn't actually save you any trouble. But you aren't in a different position than if they hadn't tried to help. (Excluding the time it took to start this discussion, of course.) > I am sick of this. Really. I am so sick of this way of stomping on > each others' feet. I can only say that the best thing to do in this situation is to say "thanks; would you mind sending me a note on [IRC|Matrix|email] in the future so we don't duplicate effort?" and move on. Surely it's not worth strong emotions. > It's made worse by failing automated notifications, of course. Not > from pagure about the push nor from koji about the build nor from > bodhi about the update. Now that is a true issue, and perhaps the real underlying issue here. If you invested time that you didn't need to invest because you didn't receive a notification that the work had already been done, then that is problematic. And yes, it would be incredibly beneficial to collaboration if that were fixed, if only because it would help to prevent situations such as the one under discussion. But please don't take that out on the person who had no motivation other than to help you out. - J< -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proven to be sickened
On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote: > So, due to me following my package (notmuch) upstream and testing > early against upstream's git, reporting and working with upstream, I > noticed a FTBFS and helped fixing it. Nothing urgent since it was > basically just a test failing for the wrong reasons. > > Within a few days, upstream releases a patch release. Within hours, > I'm testing (again, since it's basically what was on git already) on > copr and koji, writing a nice commit message, push to rawhide ... > > ... and get a reject because someone thought that pushing directly > without asking or at least notifying the maintainer would be in > order: > > https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide > Why? For a FTBFS due to a test? No bugzilla, no FTI, no security > issue whatsoever? > You may kindly ask to mtasaka why did it ? , and also alert him that package is well maintain and have a quick response and kindly ask to do PR instead , he is one provenpackager and I sure that he did that in hope of improve the package, I'm sure that he will understand. Best regards, > I am sick of this. Really. I am so sick of this way of stomping on > each others' feet. > > It's made worse by failing automated notifications, of course. Not > from pagure about the push nor from koji about the build nor from > bodhi about the update. > > Dunno whether it's the new fmn or what. That works for *my* actions > with pagure/bodhi/koji but fails to report copr actions to me, and > apparently also actions by others. > > Thanks for listening ... > > Michael > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Proven to be sickened
So, due to me following my package (notmuch) upstream and testing early against upstream's git, reporting and working with upstream, I noticed a FTBFS and helped fixing it. Nothing urgent since it was basically just a test failing for the wrong reasons. Within a few days, upstream releases a patch release. Within hours, I'm testing (again, since it's basically what was on git already) on copr and koji, writing a nice commit message, push to rawhide ... ... and get a reject because someone thought that pushing directly without asking or at least notifying the maintainer would be in order: https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide Why? For a FTBFS due to a test? No bugzilla, no FTI, no security issue whatsoever? I am sick of this. Really. I am so sick of this way of stomping on each others' feet. It's made worse by failing automated notifications, of course. Not from pagure about the push nor from koji about the build nor from bodhi about the update. Dunno whether it's the new fmn or what. That works for *my* actions with pagure/bodhi/koji but fails to report copr actions to me, and apparently also actions by others. Thanks for listening ... Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
