Triaging Bugs with Patches
eapache at gmail.com
Sat Feb 20 16:13:07 UTC 2010
On Thu, Feb 18, 2010 at 5:59 PM, Brian Murray <brian at ubuntu.com> wrote:
> On Wed, Feb 17, 2010 at 10:42:34PM -0500, Evan wrote:
> > I've been triaging a few bugs, and I came across a pair of bugs in
> > which had patches .
> > I found and checked the wiki page on triaging bugs with patches , and
> > after completing the available steps, I ran into a wall.
> > The complete text of the section describing what to do with a bug that
> has a
> > patch reads as follows:
> > > In the event that [the patch] is not a debdiff one could incorporate
> > > patch into a debdiff for the latest release of Ubuntu or apply the
> patch to
> > > a bzr branch of the package and link the branch to the bug report.
> > > If an attachment is a debdiff and applies to a recent version of the
> > > package the bug report needs to be sponsored<
> https://wiki.ubuntu.com/SponsorshipProcess>to the appropriate archive.
> This is done by subscribing (NOT assigning) the
> > > appropriate sponsorship team to the bug. For packages in main and
> > > the ubuntu-main-sponsors team should be subscribed. For packages in the
> > > universe and multiverse repositories the ubuntu-universe-sponsors team
> > > should be subscribed. You can view their queues at main-sponsors<
> > > universe-sponsors<
> > > .
> > >
> > 1) The two attached patches are simple diffs, not debdiffs - is there a
> > to convert them, and could it be added to this page?
> This isn't exactly trivial as you would need to incorporate the patch in
> the package's patch system (if it has one) and update the changelog
> among other things. Some documentation that might help in this process,
> if you are interested, can be found at
I've added a link to the patch-related portion of that page to the wiki.
> > 2) As a triager, how is one expected to be able to apply a patch to a
> > branch, and what if the project isn't hosted on launchpad/bzr? This seems
> > more dev-related then triager-related.
> Most packages are available in bzr on launchpad so you could use bzr
> branch lp:ubuntu/libpcap. Unfortunately, this isn't the case for
> libpcap though. There is also a plugin so one can use bzr patch and the
> link to the patch on launchpadlibrarian.
I'm a little confused on this point - is it Ubuntu's goal to host all
package's sources locally on bzr,
even ones which have their own upstream versioning system? While I
appreciate the integration,
it seems a bit redundant.
> > 3) Is there a way to tell from a bug page which repository the package is
> > in? I eventually found it on the launchpad libpcap package page, but I
> > couldn't find any obvious indicator on the bug page itself. This should
> > probably be mentioned as well.
> When you mouse-over the package name in the bug task table you are
> presented with information about the latest package version and the
> repository it is from. I'll update the wiki page appropriately.
> > To my mind, once a bug has an attached patch which the triager can verify
> > at least being potentially useful, there should be a simple button "flag
> > patched".
> > This flag should ping the maintainer with something like: "Project X has
> > ticket with a patch!".
> > The maintainer (or another dev) should then check the patch, commit it,
> > close the bug.
> The bugs with patches are already flagged this way in bug listings, the
> dual band-aid icon, additionally e-mail notifications now indicate when
> attachments flagged as patches are added to bug reports.
I've updated the wiki to mention the band-aid icon, and removed the
reference to the
out-dated greasemonkey script (it seems launchpad does this itself now?)
The sponsorship queue is a way to collate bug reports with patches
> across packages which is something that isn't easy to do in Launchpad.
> You can either view all the bugs with patches (quite a lot at the
> moment) or only one package's bugs with patches.
> > I'm not a workflow expert, so there may be reasons for the way the system
> > currently set up, but it doesn't make sense to me.
> I agree that the current workflow isn't ideal but hope that I've helped
> clarify some of the process for you.
You have. Thank you very much!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss