Hi, The current process (described in UbuntuDevelopment/CodeReviews [1]) for handling sponsor request not suitable for the current release period is:
1. Let the contributor know that the patch is not suitable for the current release period. 2. Unsubscribe ubuntu-sponsors. 3. Subscribe yourself to the bug report (this ensures it shows up in the following url) 4. Milestone the bug to 'later'. 5. Visit https://bugs.launchpad.net/people/+me/+bugs/?field.milestone% 3Alist=196 once the new release opens and upload the fix. I don't like this process, because some request could get lost if step five is forgotten. I propose following change: 1. Let the contributor know that the patch is not suitable for the current release period. 2. Add a tag that indicates that the bug is delayed to the next release (for example, deferred-to-natty) Then the sponsor overview [2] needs to be adjusted to understand the tag from point two. The list will be split into two lists. The first list will contain the bugs that needs to be processed. The second list will contain the deferred bugs. Once the new series is open for upload, the deferred bugs will be moved back to list one. This concept could be extented to bugs that require work from the requester. All bugs that are Incomplete could be put on list two. What do you think? Do you have better ideas? [1] https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews [2] http://people.ubuntu.com/~bdrung/sponsoring/ until my patch is merged to http://reports.qa.ubuntu.com/reports/sponsoring/ -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
