| 2009-03-19 19:48:49 |
Ted Gould |
bug |
|
|
added bug |
| 2009-03-22 22:33:27 |
Jonathan Lange |
bug |
|
|
assigned to launchpad-bazaar |
| 2009-03-22 22:35:05 |
Jonathan Lange |
launchpad-bazaar: importance |
Undecided |
Low |
|
| 2009-03-22 22:35:05 |
Jonathan Lange |
launchpad-bazaar: status |
New |
Triaged |
|
| 2009-03-22 22:35:23 |
Jonathan Lange |
tags |
|
code-review feature |
|
| 2009-03-22 22:35:38 |
Jonathan Lange |
tags |
code-review feature |
bug-branch-links code-review feature |
|
| 2009-09-15 03:33:04 |
Jonathan Lange |
tags |
bug-branch-links code-review feature |
bug-branch-links code-review feature patch-tracking |
|
| 2009-12-08 14:39:16 |
Deryck Hodge |
malone: status |
New |
Triaged |
|
| 2009-12-08 14:39:20 |
Deryck Hodge |
malone: importance |
Undecided |
Low |
|
| 2010-03-08 13:46:42 |
Karl Fogel |
summary |
Patches should be made into Bazaar branches |
Patch / branch equivalence: patches should be branches and vice versa. |
|
| 2010-03-08 14:20:18 |
Karl Fogel |
description |
A typical workflow is that people will attach a patch to a bug that fixes the bug. This is great, but there are a few things that are difficult about it. The first is merging it, while not difficult, is kinda a pain. Downloading and finding the file isn't trivial, and we really want people to accept patches easily.
So, I think that when a patch is attached to a bug, it should be made into a Bazaar branch. This would make the acceptance of that patch easier as it would only be a merge. Plus, it would give credit to the submitter to the patch directly in the source repository instead of in a comment, which I think is a positive for tracking contributions to a project.
There are a few issues. The first is determining which branch the patch should be applied to. I think that it should be applied to the default branch for the project, and if that doesn't work should have an appropriate icon to signal a failure there. By expanding that icon you could specify another branch if that's the issue.
Also, a large use of Launchpad is for the Ubuntu project so it'd be important that the packages in LP were related to the appropriate packaging branch so that things like debdiffs can be applied.
Another issue is where to put the branch. I think that it should just go to a user "launchpad-bugger" and made into a branch with the bug number and an incrementing number with the attachment. This takes care of the issue of multiple patches while keeping the URL short. So for most patches on project "bob" bug number 35 would result in the URL being lp:~launchpad-bugger/bob/bug35 if it had two patches you'd also have lp:~launchpad-bugger/bob/bug35-1. This would make it so that when you go to "http://code.lp.n/bob" you'd see all the bugs with patches that haven't been merged in yet, which would further encourage merging them in.
Lastly, as I've assumed that you've finished everything else already, I think it should be possible to convert a bug with a patch into a merge request for that branch. This is typically what happens already as when there is a patch people start discussing the patch on the bug, but it'd formalize the status of what's happening to the bug.
Thank you. |
[This bug was originally filed about auto-converting patches to bzr branches. The description has since been expanded to be about converting both ways, patch-to-branch and branch-to-patch.]
When a patch is attached to a bug, it should be possible to get access to it in the form of a Bazaar branch. Likewise, when a branch is linked to a bug, it should be possible to get access to that branch in patch form (and possibly in some-other-vc-system form as well).
The advantages of having a patch available in branch form are that it's easier to merge (If upstream uses Bazaar too, then the advantage is really big, but even if upstream doesn't, the Ubuntu packager probably does, and might need to merge the patch independently of upstream); and crediting information would automatically be in-band, instead of in some comment on the side.
The advantages of having a branch available in patch form are that patches are the lowest-common-denominator format for communicating changes -- all upstreams can accept a patch, no matter what version control system they use.
For converting patches to branches, there are few issues:
1) determining which branch the patch should be applied against. Answer: probably the default branch for the project. If it doesn't apply successfully, have an icon to signal the failure, and by expanding the icon you could specify another branch.
2) for Ubuntu, it's important that packages in Launchpad be related to the appropriate packaging branch so that things like debdiffs can be applied.
3) Where to put the branch? OP's proposal: go to a user "launchpad-bugger" and made into a branch with the bug number and an incrementing number with the attachment. This takes care of the issue of multiple patches while keeping the URL short. So for most patches on project "bob" bug number 35 would result in the URL being lp:~launchpad-bugger/bob/bug35 if it had two patches you'd also have lp:~launchpad-bugger/bob/bug35-1. This would make it so that when you go to "http://code.lp.n/bob" you'd see all the bugs with patches that haven't been merged in yet, which would further encourage merging them in. Follow-up proposal, based on Andrew Bennetts' comment #1 below: lp:~bob/bug35-patch-1 (where "1" is the comment number where the patch is attached, or else a sequence number).
Naturally, one could make a merge proposal based on a branch-from-patch; they would behave like real branches in every respect.
|
|
| 2010-03-08 14:21:13 |
Karl Fogel |
description |
[This bug was originally filed about auto-converting patches to bzr branches. The description has since been expanded to be about converting both ways, patch-to-branch and branch-to-patch.]
When a patch is attached to a bug, it should be possible to get access to it in the form of a Bazaar branch. Likewise, when a branch is linked to a bug, it should be possible to get access to that branch in patch form (and possibly in some-other-vc-system form as well).
The advantages of having a patch available in branch form are that it's easier to merge (If upstream uses Bazaar too, then the advantage is really big, but even if upstream doesn't, the Ubuntu packager probably does, and might need to merge the patch independently of upstream); and crediting information would automatically be in-band, instead of in some comment on the side.
The advantages of having a branch available in patch form are that patches are the lowest-common-denominator format for communicating changes -- all upstreams can accept a patch, no matter what version control system they use.
For converting patches to branches, there are few issues:
1) determining which branch the patch should be applied against. Answer: probably the default branch for the project. If it doesn't apply successfully, have an icon to signal the failure, and by expanding the icon you could specify another branch.
2) for Ubuntu, it's important that packages in Launchpad be related to the appropriate packaging branch so that things like debdiffs can be applied.
3) Where to put the branch? OP's proposal: go to a user "launchpad-bugger" and made into a branch with the bug number and an incrementing number with the attachment. This takes care of the issue of multiple patches while keeping the URL short. So for most patches on project "bob" bug number 35 would result in the URL being lp:~launchpad-bugger/bob/bug35 if it had two patches you'd also have lp:~launchpad-bugger/bob/bug35-1. This would make it so that when you go to "http://code.lp.n/bob" you'd see all the bugs with patches that haven't been merged in yet, which would further encourage merging them in. Follow-up proposal, based on Andrew Bennetts' comment #1 below: lp:~bob/bug35-patch-1 (where "1" is the comment number where the patch is attached, or else a sequence number).
Naturally, one could make a merge proposal based on a branch-from-patch; they would behave like real branches in every respect.
|
[This bug was originally filed about auto-converting patches to bzr branches. The description has since been expanded to be about converting both ways, patch-to-branch and branch-to-patch.]
When a patch is attached to a bug, it should be possible to get access to it in the form of a Bazaar branch. Likewise, when a branch is linked to a bug, it should be possible to get access to that branch in patch form (and possibly in some-other-vc-system form as well). Note that offering branches in patch or other form is not really specific to the bug tracker component: it should be possible for any branch.
The advantages of having a patch available in branch form are that it's easier to merge (If upstream uses Bazaar too, then the advantage is really big, but even if upstream doesn't, the Ubuntu packager probably does, and might need to merge the patch independently of upstream); and crediting information would automatically be in-band, instead of in some comment on the side.
The advantages of having a branch available in patch form are that patches are the lowest-common-denominator format for communicating changes -- all upstreams can accept a patch, no matter what version control system they use.
For converting patches to branches, there are few issues:
1) determining which branch the patch should be applied against. Answer: probably the default branch for the project. If it doesn't apply successfully, have an icon to signal the failure, and by expanding the icon you could specify another branch.
2) for Ubuntu, it's important that packages in Launchpad be related to the appropriate packaging branch so that things like debdiffs can be applied.
3) Where to put the branch? OP's proposal: go to a user "launchpad-bugger" and made into a branch with the bug number and an incrementing number with the attachment. This takes care of the issue of multiple patches while keeping the URL short. So for most patches on project "bob" bug number 35 would result in the URL being lp:~launchpad-bugger/bob/bug35 if it had two patches you'd also have lp:~launchpad-bugger/bob/bug35-1. This would make it so that when you go to "http://code.lp.n/bob" you'd see all the bugs with patches that haven't been merged in yet, which would further encourage merging them in. Follow-up proposal, based on Andrew Bennetts' comment #1 below: lp:~bob/bug35-patch-1 (where "1" is the comment number where the patch is attached, or else a sequence number).
Naturally, one could make a merge proposal based on a branch-from-patch; they would behave like real branches in every respect.
|
|
| 2010-06-23 23:04:32 |
Bryce Harrington |
malone: importance |
Low |
Medium |
|
| 2011-02-02 20:50:05 |
Robert Collins |
launchpad: importance |
Medium |
Low |
|
