Closed
Bug 455295
Opened 17 years ago
Closed 9 years ago
Allow changeset id to be placed alongside patch details
Categories
(bugzilla.mozilla.org :: General, enhancement)
bugzilla.mozilla.org
General
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: standard8, Unassigned)
Details
Now we have hg, and specific changeset ids, it would be really good if we could make an extra field associated with individual patches which would allow the changeset id to be entered once the patch was checked in.
This would provide us with:
1) An indication the patch has been checked in
2) A direct link to the check in (hence to look at date/time etc)
3) A consistent checked-in indication.
and avoid having to add comments, and search through the bug to find them later.
I'm guessing this is probably something we want on bugzilla.mozilla.org as a bugzilla customisation, but if you feel it should be a bugzilla bug, please feel free to move it.
suppose a patch is committed to multiple repositories, how would one handle multiple changeset ids? :)
| Reporter | ||
Comment 2•17 years ago
|
||
(In reply to comment #1)
> suppose a patch is committed to multiple repositories, how would one handle
> multiple changeset ids? :)
With the co-existence of mozilla-central and comm-central, I haven't yet seen a patch in bugzilla that spreads across multiple repositories, even build patches are attached separately. I think until hg has support for that kind of diff (if ever), then its something that doesn't need to be fussed about too much.
Alternately, how about a free-text field where you could just paste in the changeset urls?
Comment 3•15 years ago
|
||
It would be good to handle multiple changesets, so we could support noting branch-landing of patches as well.
Comment 4•15 years ago
|
||
People have been dealing with this by pasting changeset URLs into the final comment. Has that proved to be an effective solution in practice, or does it leave something to be desired?
Adding an "edit attachment" step to the "edit bug" step when closing a bug seems to me to be something to be avoided if possible.
Gerv
| Reporter | ||
Comment 5•15 years ago
|
||
(In reply to comment #4)
> People have been dealing with this by pasting changeset URLs into the final
> comment. Has that proved to be an effective solution in practice, or does it
> leave something to be desired?
No, it isn't an effective solution. There are various issues with it:
1a) If more than one patch (or more than one branch landing) in a bug, and the patch title isn't updated, then you can have more than one changeset referenced which you then have to dig through all the comments to find the appropriate landing.
1b) This gets even more complicated with backouts.
2) If you have a bug that later gets more than one attachment, some people follow up by changing the attachment names to reference the comments which causes more bugspam and pain.
3) Even then there's no easy lookup/direct link from attachment to the landing.
4) Some areas are now using a separate "checked-in" attachment flag. This shows when the attachment has been checked in, but not where/what it was checked in to (and also wouldn't account for branches).
So then you get two or three semi-workarounds, and some people don't even include the changeset.
IMHO if you're using a management system to track bugs, then you should be able to easily track a reference to where the things were actually fixed.
| Assignee | ||
Updated•14 years ago
|
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
Comment 6•9 years ago
|
||
With mozreview we're probably never doing this. For github we tend to use special links to github PRs and such.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•