Strawman: eliminating debdiffs

[James Westby]

Hi Colin,

Thanks for the response.

I should have said in my original mail that some of the inspiration for
the proposal was some comments you had made the day before, so thanks
for that too.

On Thu, 2008-10-09 at 13:59 +0100, Colin Watson wrote:
> I'm going to reply to a number of points made throughout this thread,
> but am replying to the topmost article because I'd like to do it all at
> once.

>   * Sometimes people send a perfectly good patch in an Ubuntu bug
> report
>     and then somebody says "in order to get this included you should
>     attach a debdiff instead". This is *a complete and utter waste of
>     time*. A debdiff is just a kind of patch and any Ubuntu developer
>     who can't figure out how to apply some slightly
>     differently-formatted patch in a matter of seconds shouldn't be an
>     Ubuntu developer. What bug triage processes recommend that people
>     say this and how can we get them fixed? I know people who are
>     perfectly competent developers who think we're mired in useless
>     bureaucracy due to this and have been put off contributing.

There is a mention at

  https://wiki.ubuntu.com/Bugs/Responses

(can't link directly due to Moin's strange anchor names). It has been
changed to suggest that a debdiff may help things along, but it is
not a requirement.

>   * As you say, there is little incentive for anyone to submit patches
>     upstream because that's not the main thing they're measured on when
>     attempting to join the Ubuntu development team.
> 
>   * Quite a number of people seem to spend considerable time preparing
>     debdiffs for simple changes. If that really is something that gains
>     credit in the MOTU application process then we should review the
>     process. We should focus on quality over quantity; people who are
>     capable of doing more complicated bug-fixing work will not have any
>     trouble with simple things.

I agree completely with this. There are some items in the sponsors queue
which were never worth the effort for the contributor, and certainly
not worth sponsors time. An email/bug report in Debian or upstream would
be much more efficient, as well as being the right thing to do.

I think the application process should ask for applicants to present
what they think are the best examples of their work. Those that were
particularly tricky, those that required an in-depth understanding
of things like the upgrade process, those where they worked well
with others to come to a good solution.

Thanks,

James