distinguish "is this a patch" from "is this a patch that fixes this bug"

[Martin Pool]

At the moment Launchpad conflates "is this a patch" from "is this a patch that fixes this bug". Many things that are patches can be attached to a bug, such as sample data that causes a bzr failure, or a historical diff that needs review in eg bug 521989. These should not kick off the "this bug has work that needs merging" flow.

[Jonathan Lange (jml)]

On Thu, Mar 25, 2010 at 1:48 AM, Martin Pool <email address hidden> wrote:
> Public bug reported:
>
> At the moment Launchpad conflates "is this a patch" from "is this a
> patch that fixes this bug".  Many things that are patches can be
> attached to a bug, such as sample data that causes a bzr failure, or a
> historical diff that needs review in eg bug 521989.  These should not
> kick off the "this bug has work that needs merging" flow.
>

I don't think there's any point in fixing this unless we just change
patch management to be merge proposals.

jml

[Deryck Hodge (deryck)]

I'm confused. An attachment isn't a patch unless the "This attachment contains a solution (patch) for this bug" option is ticked when adding an attachment. Isn't this what you're asking for here?

[Martin Pool (mbp)]

Deryck, Launchpad seems to have heuristics whereby if the attachment looks like a patch, Launchpad pressures you to agree that it really is. Try editing an existing attachment that is not a fix for the bug but does contain a diff.

This doesn't block you from doing the right thing so it's not very urgent, but it's a bit anoying. Low, at most.

[Robert Collins (lifeless)]

Ran into this today on bug https://bugs.edge.launchpad.net/bzr/+bug/594958 - a user has attached a faulty patch - specifically a patch file which is faulty - and launchpad considers that a patch to fix the bug, when it really is just evidence to help diagnose the bug.

I appreciate only a few product (launchpad itself, bzr, other vcs systems, gnu patch and diff) will have this distinction, but it would be nice for us to have it, or even just some way to say

'this bug really does not have a patch, don't be fooled'.

I will note that while the text: "This attachment contains a solution (patch) for this bug" is pretty clear it could perhaps be tweaked - e.g. "This attachment contains a solution (patch) fixing this bug"

But even then folk will put bad data in, and we should have a way to correct that data.

[Robert Collins (lifeless)]

Hah, if you click on 'edit' beside such an attachment there is a form where you can unclick the 'this attachment is a patch' setting.

If you do so, you then get asked:
---
This file looks like a patch. What is a patch?

Is this file a patch:
 yes
 no
---

And *this* question is wrong.
The file is a patch.
It is not a solution for the bug.

So the two checks are not consistent with each other, and this may be encouraging people to say 'yes' to a question that is really only checking the MIME type/content when in fact the other form wants to check the semantic intent.

[Deryck Hodge (deryck)]

Sorry I never responded to this. Lost the bug somehow until a dupe reminded me.

I understand this bug to be primarily about the confusing UI around us asking "is this a patch." There are other bugs tracking the desire to get patches to branches and/or vice versa.

Cheers,
deryck