• [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

    From Michael Orlitzky@21:1/5 to All on Tue Jan 25 18:30:03 2022
    Can I request that Bug: and Closes: tags in our commits automatically
    CC the committer on the bug that is modified?

    Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
    will leave a comment like "it still crashes on x86" that I never see.
    Of course, I could manually CC myself on every bug. But that will send
    everyone an extra email, and is forgettable. Plus, avoiding the manual
    step is kind of the point of the automation, right?

    One potential downside is that the commit author could wind up CCed
    twice via an alias, but that could be solved with a sufficiently clever implementation. Or disregarded if it's not too much of a problem in
    practice; the bugs will usually be closed, after all.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to All on Tue Jan 25 18:40:01 2022
    On 25 Jan 2022, at 17:00, Michael Orlitzky <mjo@gentoo.org> wrote:

    Can I request that Bug: and Closes: tags in our commits automatically
    CC the committer on the bug that is modified?

    Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
    will leave a comment like "it still crashes on x86" that I never see.
    Of course, I could manually CC myself on every bug. But that will send everyone an extra email, and is forgettable. Plus, avoiding the manual
    step is kind of the point of the automation, right?

    One potential downside is that the commit author could wind up CCed
    twice via an alias, but that could be solved with a sufficiently clever implementation. Or disregarded if it's not too much of a problem in
    practice; the bugs will usually be closed, after all.


    I'd quite like this as I do a fair amount of drive-bys.

    Thanks for bringing it up.

    Best,
    sam

    -----BEGIN PGP SIGNATURE-----

    iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmHwNIJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDvCcggAhsNBxQfy8NhB0xrj4SotobxRviiEUuDoYYWayaUmKlCQAvlGK51OjZoL wBZWEGt8VspPUFZorCBHWI9JFZv+Efb1GMjKAIRbLBR1NoM2Ih6iD8Ljm74ngpUd B+1y/M8eFM3lRjDc8mPBrtS3qIedKJZVaXAdH9Sfns+X739b3bAmO1sY3R8jCV3f 600suPtuRVYX4AdgjWdpipV6pCJsRHkjns7Nvg8RssHXy0yEft5xcxpCr0tfj+cV zpVTYENHcoFFkLjVken6bq5fC2oAKp6ywHeRsHrIoQZY/Wui644LK0igl2rHASo+ Qe618FMnahRA4/VFZQpGRvMoZt5RUQ==
    =QM1s
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexey Sokolov@21:1/5 to All on Tue Jan 25 19:20:02 2022
    25.01.2022 17:33, Sam James пишет:


    On 25 Jan 2022, at 17:00, Michael Orlitzky <mjo@gentoo.org> wrote:

    Can I request that Bug: and Closes: tags in our commits automatically
    CC the committer on the bug that is modified?

    Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
    will leave a comment like "it still crashes on x86" that I never see.
    Of course, I could manually CC myself on every bug. But that will send
    everyone an extra email, and is forgettable. Plus, avoiding the manual
    step is kind of the point of the automation, right?

    One potential downside is that the commit author could wind up CCed
    twice via an alias, but that could be solved with a sufficiently clever
    implementation. Or disregarded if it's not too much of a problem in
    practice; the bugs will usually be closed, after all.


    I'd quite like this as I do a fair amount of drive-bys.

    Yes please. There were a few cases where I broke something when trying
    to fix something and didn't notice the report.


    Thanks for bringing it up.

    Best,
    sam


    --
    Best regards,
    Alexey "DarthGandalf" Sokolov

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Michael Orlitzky on Tue Jan 25 20:40:02 2022
    On Tue, 2022-01-25 at 12:00 -0500, Michael Orlitzky wrote:
    Can I request that Bug: and Closes: tags in our commits automatically
    CC the committer on the bug that is modified?

    Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
    will leave a comment like "it still crashes on x86" that I never see.
    Of course, I could manually CC myself on every bug. But that will send everyone an extra email, and is forgettable. Plus, avoiding the manual
    step is kind of the point of the automation, right?

    One potential downside is that the commit author could wind up CCed
    twice via an alias, but that could be solved with a sufficiently clever implementation. Or disregarded if it's not too much of a problem in
    practice; the bugs will usually be closed, after all.


    Sounds good to me. Please file a bug for infra when the discussion
    settles and I'll try to do it.

    IMO the biggest issue is that the committer may be using a different
    address than the one used on Bugzilla but I guess we can resolve that by retrying without CC.

    --
    Best regards,
    Michał Górny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alec Warner@21:1/5 to mjo@gentoo.org on Tue Jan 25 20:40:02 2022
    On Tue, Jan 25, 2022 at 9:00 AM Michael Orlitzky <mjo@gentoo.org> wrote:

    Can I request that Bug: and Closes: tags in our commits automatically
    CC the committer on the bug that is modified?

    Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
    will leave a comment like "it still crashes on x86" that I never see.
    Of course, I could manually CC myself on every bug. But that will send everyone an extra email, and is forgettable. Plus, avoiding the manual
    step is kind of the point of the automation, right?

    Just to clarify here:
    For your own commits (e.g. fixing a package you own) you are already
    typically on the bug..right?
    I assume the major use case here is proxying commits for others (where
    they are on the bug, but you are not, either directly, or via an
    alias?)


    One potential downside is that the commit author could wind up CCed
    twice via an alias, but that could be solved with a sufficiently clever implementation. Or disregarded if it's not too much of a problem in
    practice; the bugs will usually be closed, after all.

    The hooks are all public:

    https://gitweb.gentoo.org/infra/githooks.git/tree/local/postrecv-bugs

    Submit a patch and we can update the hook.

    -A





    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Orlitzky@21:1/5 to Alec Warner on Tue Jan 25 21:50:04 2022
    On Tue, 2022-01-25 at 11:29 -0800, Alec Warner wrote:

    Just to clarify here:
    For your own commits (e.g. fixing a package you own) you are already typically on the bug..right?

    Right.


    I assume the major use case here is proxying commits for others (where
    they are on the bug, but you are not, either directly, or via an
    alias?)



    Take maintainer-needed packages for example. No one else is maintaining
    them, and I don't want to add myself to the alias or take full
    responsibility for the package. But if I have ten free minutes I might
    pick an open bug from the 24h recent list on bugzilla and do a drive-by
    commit to fix a simple build failure. I'd like to be CCed on the
    relevant bug in case someone comments on my fix.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Agostino Sarubbo@21:1/5 to All on Tue Jan 25 22:20:02 2022
    This is a multi-part message in MIME format.

    On martedì 25 gennaio 2022 18:00:30 CET Michael Orlitzky wrote:
    Can I request that Bug: and Closes: tags in our commits automatically
    CC the committer on the bug that is modified?

    Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
    will leave a comment like "it still crashes on x86" that I never see.
    Of course, I could manually CC myself on every bug. But that will send everyone an extra email, and is forgettable. Plus, avoiding the manual
    step is kind of the point of the automation, right?

    One potential downside is that the commit author could wind up CCed
    twice via an alias, but that could be solved with a sufficiently clever implementation. Or disregarded if it's not too much of a problem in
    practice; the bugs will usually be closed, after all.

    While it does not hurt implement an hook I'd say that:

    - CI already cc'es the author of the commit when he breaks a package or introduces a QA
    issue.
    This is related to a new bugs and, obviously, does not cover your use-case.

    - If you are CC'ed by the hook and you are part of the alias that is the assignee of the bug,
    you will receive two emails unless the hook integrates the alias.

    - Based on the previous point, I'd suggest to use a wrapper if you want to be cc'ed on the
    bug you are resolving:


    #!/bin/bash

    BUG="${1}"
    COMMIT_MESSAGE="${2}"

    repoman commit -c "${BUG}" -m "${COMMIT_MESSAGE}" && bugz --key "${APIKEY}" modify --add-cc name@gentoo.org "${BUG}"


    Agostino


    <html>
    <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">On martedì 25 gennaio 2022 18:00:30 CET Michael Orlitzky wrote:</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; Can I request that Bug: and Closes: tags in our commits automatically</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; CC the committer on the bug that is modified?</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; </p> <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; will leave a comment like &quot;it still crashes on x86&quot; that I never see.</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; Of course, I could manually CC myself on every bug. But that will send</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; everyone an extra email, and is forgettable. Plus, avoiding the manual</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; step is kind of the point of the automation, right?</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; </p> <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; One potential downside is that the commit author could wind up CCed</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; twice via an alias, but that could be solved with a sufficiently clever</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; implementation. Or disregarded if it's not too much of a problem in</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">&gt; practice; the bugs will usually be closed, after all.</p>
    <br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">While it does not hurt implement an hook I'd say that:</p>
    <br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">- CI already cc'es the author of the commit when he breaks a package or introduces a QA issue.</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">This is related to a new bugs and, obviously, does not cover your use-case.</p>
    <br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">- If you are CC'ed by the hook and you are part of the alias that is the assignee of the bug, you will receive two emails unless the hook integrates the alias.</p>
    <br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">- Based on the previous point, I'd suggest to use a wrapper if you want to be cc'ed on the bug you are resolving:</p>
    <p>&nbsp;</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">#!/bin/bash</p>
    <br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">BUG=&quot;${1}&quot;</p>
    <p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">COMMIT_MESSAGE=&quot;${2}&quot;</p>
    <br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">repoman commit -c &quot;${BUG}&quot; -m &quot;${COMMIT_MESSAGE}&quot; &amp;&amp; bugz --key &quot;${APIKEY}&quot; modify --add-cc name@gentoo.org &quot;${BUG}&quot;</p>
    <br /><br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Agostino</p>
    <br /></body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ionen Wolkens@21:1/5 to Michael Orlitzky on Tue Jan 25 23:20:02 2022
    On Tue, Jan 25, 2022 at 12:00:30PM -0500, Michael Orlitzky wrote:
    Can I request that Bug: and Closes: tags in our commits automatically
    CC the committer on the bug that is modified?

    Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
    will leave a comment like "it still crashes on x86" that I never see.
    Of course, I could manually CC myself on every bug. But that will send everyone an extra email, and is forgettable. Plus, avoiding the manual
    step is kind of the point of the automation, right?

    One potential downside is that the commit author could wind up CCed
    twice via an alias, but that could be solved with a sufficiently clever implementation. Or disregarded if it's not too much of a problem in
    practice; the bugs will usually be closed, after all.

    +1

    Even in case of projects where I'd already get mail, I treat CC
    specially in filters to try to not miss it. esp relevant on some
    noisy aliases like proxy-maint@

    /If/ some aren't happy at the idea, maybe there could be a opt-out
    feature that'd be adjustable on d.g.o? (having some of these automated
    things be configurable could be something to think about either way).

    --
    ionen

    -----BEGIN PGP SIGNATURE-----

    iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmHwdfUACgkQskQGsLCs QzTP7wf/VklLYmFYOi+0CTgbfIGCDfRjFt4BqPm52VVhz8XLX0EfzRI5zLKevZYl +wcFncxhI9k6tS83ZJYBYpoqGKBPAIjjFnDRv+HncTYKC1ye2DzM0BdeOr/ItbnO s3bwzuApGhtA+PH7chbfY2Ks7I1SesIsjfd2n/AXLmmPcTiM8pMQvJ66wRV/Ac/1 T6W+SaOPWVecQ0pq/6Y+XOjDnC2OXRAKiJBMwIceZFVVereZy8ghYU9Rg4opbpGx uNHVuFGdejnKRAmESAhQL2uFMOa4qSRz9QUxg2OJ4YzV3AfdIGd8qOSPSZrkxk99 0AGUj8GeBBqsFs3RPGP3XSJXDSdaXQ==
    =4Jq8
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Orlitzky@21:1/5 to Agostino Sarubbo on Wed Jan 26 02:10:01 2022
    On Tue, 2022-01-25 at 21:59 +0100, Agostino Sarubbo wrote:

    - If you are CC'ed by the hook and you are part of the alias that is the assignee of the bug,
    you will receive two emails unless the hook integrates the alias.

    - Based on the previous point, I'd suggest to use a wrapper if you want to be cc'ed on the
    bug you are resolving:


    I don't have enough information about the environment to know if it's
    possible, but obviously it would be nice if the implementation could
    avoid double emails. A pass through projects.xml might suffice, since
    non-devs can't commit directly. It might take an extra HTTP request
    though.

    An alias or wrapper isn't much better than checking the box on the
    webpage, at least for me personally:

    * I still have to remember to use the wrapper and not the "repoman 
    commit" I've typed thousands of times.

    * I need two wrappers; one for repoman and one for pkgdev.

    * I only want to be CCed if I actually modify the bug (not merely by 
    committing), since that's what prompts follow-up comments.

    * A few other people have said they would like the feature, and
    we'd all need to reimplement the same thing on a bunch of machines.

    * It needs www-client/pybugz installed =)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)