Strawman: eliminating debdiffs

Tue Oct 14 07:14:50 BST 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Colin Watson schrieb:
> On Thu, Oct 09, 2008 at 08:08:34PM +0200, Daniel Holbach wrote:
>> The part in our process that involves subscribing ubuntu-*-sponsors
>> basically means "somebody who can upload the patch, please review it".
> 
> Right. At root, I think the thing that makes me dissatisfied with our
> current process is that people who are sending us patches - things that
> fundamentally need review by developers - are getting responses from
> non-developers (and sometimes even told to go somewhere else by
> non-developers before developers get a look-in, which is appalling). In
> effect, we've set up a technical support firewall, which is always
> guaranteed to annoy people who know what they're doing.
> 
> Our processes for patch handling should concentrate on funnelling them
> straight through to developers in the most efficient way possible. In
> theory, I can see why it's tempting for a larger group of people to try
> to improve things before the small highly-contended group of developers
> needs to worry about it - that's a principle we apply to bug triage work
> in general - but in this case I don't think it actually helps developers
> process things significantly more quickly. We do have a problem dealing
> with sponsorship requests, but this doesn't seem like the solution
> (except in that it might make some patch submitters give up).

I'm absolutely not opposed to people (who know what they're doing) using
the Sponsoring Process directly. What I'd like to improve is how we deal
with the huge list of bugs with patches attached.

I expect nobody to triage the list directly, but I'm sure that some kind
of public guidelines for "making sure the patch is useful" would help
people who triage the bug anyway.

>   * There needs to be a way for developers to say that they have looked
>     at the item and it does not apply, without necessarily closing it
>     altogether.

I had a few discussions about it and there were a couple of cases where
we identified what might be options for those cases.

 - a small string change (.desktop file, etc) that really should be
upstream first, so it can get translated properly: add a nice comment
explaining the situation, open an empty upstream task, mark the Ubuntu
task "won't fix" (so it's off the list).
 - broken patch: either untag the 'patch' checkbox or remove the patch
 - huge patch we're not comfortable carrying on our own: explain the
situation, add an empty upstream task (no idea how to 'get it off the list')

>   * There should be a way for a developer to claim an item off the list
>     to avoid duplicating work. As we've found, this works better if
>     developers claim things rather than if they're assigned to them
>     (where they get lost in the noise).

Subscribing to the bug report and unsubscribing the sponsors team is an
option, but it doesn't help "getting it off the list".

>   * It should be concise, searchable, and ideally not divided into pages
>     (so that you can use your browser's search facilities, not to
>     mention the rather excellent specialised search facilities built
>     into the human brain).
>     https://bugs.launchpad.net/ubuntu/+bugs?field.has_patch=on is
>     hopeless because it consists of 25 pages and has lots of duplicated
>     bug numbers; I'm never going to skim through that looking for things
>     I'm an expert on.
> 
>   * We should valiantly resist the temptation to add yet another list
>     that people need to monitor regularly. I think I'm already at my
>     practical limit in terms of lists I go over with my team on a weekly
>     basis.
> 
>   * Some kind of incentive helps. Of course this sort of work will tend
>     to accrue karma, but perhaps some way to find a list of champion
>     patch integrators would help. The incentive doesn't necessarily have
>     to involve your name, though; I've found that seeing the bug graphs
>     at http://people.ubuntu.com/~bryce/Plots/ drop can be a great
>     incentive when I'm working on a package's bugs.
> 
>   * There should be a way to get an item off the list once a developer
>     has responded and it's waiting for further information. Once that
>     further information is provided, it should reappear on the list,
>     usually quite high up (since it is now likely that it's higher up
>     the quality scale).

I realise that adding a tag does not help much in terms of searchability
on LP (No way to list bugs that DON'T have a certain tag added or team
subscribed). What we can do, is add that information to harvest though.

What I'd really like us to avoid is trying to interpret the bug status
as a patch status. We're not very good at using bug statuses strictly
and consistently anyway.

> Anything that involves judgement of the patch itself needs to be done by
> people who are competent to judge it, i.e. developers. I'm afraid I've
> seen far too many cases of people itching to get the bug count down for
> any reason they can find rejecting perfectly good patches, and I would
> be very concerned about an explicit patch triage program. I would phrase
> this differently, as "what makes a good patch", but with a note that
> patches that don't "comply" to the letter may well still be perfectly
> useful.

I understand your concern. In the documentation it'd be important to
point out every 10 lines that "if you're unsure, please ask for advice".

Things we could make sure and which would be important before patches
reach the sponsoring queue:
 - is it really a patch?
 - is the patch well-documented? do we know what and why?
 - (does it apply to the current development version? - although this
should be no blocker)

> I don't object to people tidying up patches, but honestly I think there
> are much better uses of their time. Trivial cleanups that anyone can do
> are only going to take the developer a minute or two, and with much less
> risk of error. The things that make patch review slow are not trivial
> cleanups like this, but rather having to go back and forward with the
> patch submitter about the intent of the patch, and the inevitable time
> delays while people notice that something has been said.

This makes sense to me. I'd be interested what others think.

> Personally, it would speed my patch review up very significantly if I
> could have a time-ordered list of cases where people have responded to
> my comments on a patch that failed review (or even just a procmail rule
> that would copy just those bug mails into my inbox or send it in the
> direction of my desktop notification script). As it is, I make a comment
> on a patch, the submitter replies a few days later when they have time,
> and then the comment is probably lost in incoming bug mail.

I might not get that much bug mail, but inbox for bugs I'm personally
subscribed on works quite well for me.

Would filtering for "ubuntu-*-sponsors is subscribed" AND "I'm
subscribed" work?

>> To try to workaround the limitations in Launchpad Bugs and add
>> information to classify those 2006 bugs in terms of "what needs doing
>> now?" we could try the following:
>>  1) patch is attached and turns up on "open bugs with patches" list
>>  2) patch triage happens, tag "triaged-patch" added
>>  3) ubuntu-*-sponsors is subscribed, review happens
>>  4) patch needs work, ubuntu-*-sponsors is unsubscribed
>>  5) ubuntu-*-sponsors re-subscribed, review is good, uploaded
>>  6) bug closed
> 
> If the patch triage step consisted only if "*is* it a patch (and not a
> screenshot)", and also filtered out cases where a developer has already
> responded giving negative feedback on the patches, I think it would make
> sense for step 3) to happen en masse. I would be unhappy with any more
> extensive patch triage unless it's being done by developers, in which
> case you might as well just subscribe ubuntu-*-sponsors anyway.

I'm not sure how we can best categorise those bugs without massive bug
tagging. But I feel that once we're on top of the massive list of bugs
with patches, I'm sure that "get patches through the sponsoring queue
quickly" would just work.

Have a nice day,
 Daniel

- --
My 5 today: #280806 (tomboy), #282821 (ubuntu), #282818 (ubuntu),
#279207 (swfdec0.6, swfdec-gnome), #282961 (xapian-core)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj0ONkACgkQRjrlnQWd1evNygCdHQefuyyP+nFa9zskSZcgEkOP
DP0Anj4ZYk4ShVtGD0/4RBLFRZGfJInN
=bzjN
-----END PGP SIGNATURE-----