Patch pilot report 2012-10-15

[Dmitrijs Ledkovs]

On 16 October 2012 07:59, Daniel Holbach <daniel.holbach at ubuntu.com> wrote:
> Hello,
>
> 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?
>

I was doing something different. I was opening r-series task, and
won't fixing q-series task for bugs. To me, that seemed more clear
what needs to happen.

While the bugs are somewhat manageable, the branches are slight more difficult.

At the r-series opening, the current nickname lp:ubuntu/package will
actually be turned into nickname lp:ubuntu/quantal/package of the
actual branch name. That also mean that all the "work in progress"
branches will suddenly become SRUs. So somehow on day 0 it would be
nice to reject & re-propose all merge proposals that: (i) target into
lp:ubuntu/quantal/package AND (ii) top of the debian/changelog is
targeting quantal. This should roughly prevent re-targeting real SRUs
to r-series.

but.... a generic approach might be:

"~ubuntu-next-series-sponsors" which is subscribed to bugs & asked to
review branch proposals, with a mass
s/ubuntu-next-series-sponsors/ubuntu-sponsors/ are archive opening.

Regards,

Dmitrijs