Strawman: eliminating debdiffs

[Daniel Holbach]

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

Colin Watson schrieb:
> OK. Can I suggest that we should change that to something like the
> following:
> 
>   == Patch that does not seem to be getting any attention ==
> 
>   Thanks for your proposed fix. If you feel that nobody is taking care
>   of this package and would like to help to do so yourself, then you may
>   wish to prepare a source package including this fix and follow
>   http://wiki.ubuntu.com/SponsorshipProcess to have it included in
>   Ubuntu.
> 
> This restricts this request to where it's actually useful rather than to
> essentially all patches not in debdiff format, it talks about the
> process rather than about the mechanism, and it explains a little more
> about the end goal of getting involved in the sponsorship process.
> 
> Daniel, I suspect this was your text. Comments?

The part in our process that involves subscribing ubuntu-*-sponsors
basically means "somebody who can upload the patch, please review it". I
agree with what Colin said in his mails earlier that this review should
be more about the solution of the problem than the formatting of the
changelog or other subtleties.

So how can we get the list of bugs with patches
(https://bugs.launchpad.net/ubuntu/+bugs?field.has_patch=on has - 2006
bugs right now) reasonably processed? It'd be nice if they all get
reviews and the number of open bugs with patches down to 0.

Our workflow for getting some kind of patch integrated into Ubuntu is
somewhat limited by Launchpad Bugs not offering information about the
status of a patch. Maybe the solution is to have some kind of "patch
triage" and a guide for how to do it. Items that come to my mind are:
 - *is* it a patch (and not a screenshot)?
 - does it apply against the current development version?
 - where is the patch from?
 - was it accepted upstream already?
 - is it properly documented?
 - etc.

If somebody is willing to tidy up the patch, bring it into debdiff
format, add a nice changelog entry, etc during this "patch triage" even
better. Once this has been done, it would make sense to have some
ubuntu-dev member review it, test it, and if it's all good upload it.

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

The proposed process has the advantages that
 - the bug status does not need to be interpreted as a patch status
 - we can track those bugs easily in harvest ("gedit - 12345 (patch)"
vs. "gedit - 23456 (triaged patch)")
 - we know what needs doing and write documentation for it

Have a nice day,
 Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjuSKIACgkQRjrlnQWd1eswBwCggMtGv0DZzZpUJxv4mwVmA+Oj
AOMAmgK3CT8DAOC9VTVGHLdeXPgJ8yrj
=uzmd
-----END PGP SIGNATURE-----