Strawman: eliminating debdiffs

[Daniel Holbach]

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

Thierry Carrez schrieb:
> I think there are two levels of patching. One is to find the solution to
> the bug, and can be in proper diff format as well as carefully-worded
> suggestion. The other is a ready-to-be-sponsored debdiff. I suppose we
> want to encourage both, the first one to get solutions and testing from
> bug reporters without scaring them away, and the second one to train
> potential future developers to the subtleties of Debian packaging.

I agree. In the last time if small things like the changelog format
(etc.) was not perfect in the sponsoring bug, I simply changed it, added
a nice comment saying "this is what I changed and why I did it, thanks
for your great work". The replies almost always were "Oh thanks a lot,
I'll bear that in mind the next time."

This way we don't need to block on small issues, but still educate new
contributors.


> In the best of worlds I would only use status field to track the status
> of the bug : we could use "Triaged" to mark that the bug has a solution
> (or that the developer already knows how to fix it), then have an
> additional "Fix proposed" status to track sponsoring:
> 
> 1) patch is attached and turns up on "open bugs with patches" list
> 2) patch triage happens, use "Triaged" to show the bug has a solution
> 3) use "In progress" when working on a proper debdiff
> 4) use "Fix proposed" to get attention from the sponsors
> 5) Sponsors review and set back to "In progress" if not successful
> 6) Sponsors review and go to "Fix committed" when uploading
> 7) bug closed
> 
> This would make the whole process more intuitive and easier to track,
> but would require more open access to the status field (and a new status
> to be available).

The problem with bug statuses is that there can be too much interpreted
into it. For instance "Fix Committed" to a lot of people means "there's
a fix available".

Actions which feel most natural to me are
 - set to "in progress" and assign to patch author to indicate "there's
work to be done"
 - subscribe/unsubscribe sponsors team to get input (I use
http://people.ubuntu.com/~dholbach/unsub for that)


What do we want to make sure has been checked already before a bug from
the "patch list" moves to the "sponsors list"? What do you think we
should add to the BugSquad documentation?

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

iEYEARECAAYFAkj1jhkACgkQRjrlnQWd1etiFACdHONFzV5NLRVqAm4aKGhveq90
OR0An0Smn+XoB9AmlMAyzvWgK62kx7B+
=yznm
-----END PGP SIGNATURE-----