Patch pilot report 2012-10-15

[Steve Langasek]

Hi Daniel,

On Tue, Oct 16, 2012 at 08:59:49AM +0200, Daniel Holbach wrote:
> On 15.10.2012 22:32, Steve Langasek wrote:
> > On Mon, Oct 15, 2012 at 03:09:31PM -0500, Jamie Strandboge wrote:
> >> Note, queue not going down as much as it could be because I saw a lot of
> >> things (correctly) being deferred to R

> > I think we really need to come up with a better way of systematically
> > deferring sponsorship queue items that doesn't involve individual sponsors
> > taking responsibility for revisiting an item when the next release opens. 
> > That workflow tends to make developers very reluctant to move stuff out of
> > the queue because they can't commit to being the one to do that work in $x
> > weeks.  I'd really like us to be able to have a central sponsorship deferral
> > tag that we can batch process at the opening of the next release, so that we
> > can deal with this more efficiently across the team.

> On
> https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Keeping_the_Sponsoring_Queue_manageable
> we say for things that are "[n]ot suitable for the current release period":

>  * Let the contributor know that the patch is not suitable for the
>    current release period.
>  * Unsubscribe ubuntu-sponsors, or mark the merge proposal status as
>    "Work in Progress". (Be sure to tell the contributor to reverse the
>    process)
>  * Subscribe yourself to the bug report (this ensures it shows up in
>    the following url)
>  * Milestone the bug to 'later'.
>  * Visit
> https://bugs.launchpad.net/people/+me/+bugs/?field.milestone%3Alist=196
> once the new release opens and upload the
>    fix.

> Would this work?

Sorry, that's the process I meant.  It doesn't actually require the sponsor
to take responsibility for *sponsoring* the change at the opening of the
next release, but they still have to take responsibility for checking in at
the start of the release cycle and moving these bugs back into the queue.  I
think sponsors are more reluctant to follow such a workflow compared with
one that would put bugs in a general "deferred sponsorship" queue that could
be batch processed after the release opening.  It's also more error prone to
ask each of 50 sponsors to punt their later-milestoned bugs down the line,
than it is to ask that /someone/ on the team run $magicscript to update all
the deferred bugs at the release opening.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20121016/7ff2c00e/attachment.pgp>