annoyed how SRU's are currently handled

[Dmitrijs Ledkovs]

On 14 March 2013 22:15, Clint Byrum <clint at ubuntu.com> wrote:
> Excerpts from Matthias Klose's message of 2013-03-14 15:00:19 -0700:
>> Hi,
>>
>> with the latest rejection of gcc-4.6 for precise-proposed, my motivation to
>> contribute to stable release updates is below zero.  For this particular upload
>>
>>  - I got a reject message without any reason, and had to figure out with
>>    help from Colin from irc logs who did reject the upload.  No, even on
>>    irc no reason was given.
>>
>>  - Talking with Steve, he pointed out that one issue actually has some
>>    information in the wrong place, although afaics there is no information
>>    missing.
>>
>> The worst thing about this is that nothing can be traced. Good luck for you if
>> you are online, but if you are not, you are on your own figuring out the
>> reasons.  Please compare this with other processes like the MIR process where
>> everything is documented in a bug report, with removal of packages (again,
>> documented in bug reports), or package rejections from the NEW queue, where
>> package maintainers send an email to the uploader and ubuntu-archive.
>>
>
> Whoever rejected the upload should have emailed you directly if you were
> listed in the changelog. There's an open bug request for launchpad to have
> a way to enter a reject reason that would be automatically emailed. But
> for now, whoever did that, did it wrong IMO.
>

This does not scale. I am (like many other people) am subscribed to
the ubuntu-archive mailing list, simply for the purpose of noticing
all of the kernel SRU trackers & MIR reports and removals.

It would be exceptionally helpful to have: unapproved, new and reject
queues to CC a publically archived mailing list.

That way, SRU team members can reply to that message (which would then
automatically have correct uploader, sponsor and the public mailing
list) explaining what happened.
I think all of us agree that hitting reply button to a message with
relevant context is easier and more informative that drafting personal
1-to-1 emails.

I would like to see why other people's uploads are rejected, such that
I don't fall into the same trap / make the same mistake.


>> Another thing is the pedantic attitude that everything to reproduce the issue
>> has to be in the bug description. Looking at #972648, this information
>> actually is even included partially in the bug description (the gcc command
>> line).  Pasting the preprocessed source in the bug description seems to be wrong.
>>
>
> So, how many developers are there, vs. SRU team members? Is it so much
> to ask that developers who are uploading to the SRU team's review queue
> have things arranged properly so we can find it easily and don't have to
> dig? This goes for SRU bug verifiers too, they should be able to look
> at the bug description and see how to reproduce, and what areas of a
> program need testing because of regression risks.
>

I was the one who added the bug template to the SRU instructions wiki page:
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

I'm confused, why that hasn't been done earlier when SRU team
advocates test-cases so strongly.

And has been consistently asking people to fill that template out.
Many contributors / requesters for an SRU did that work for me, which
was awesome and made my SRU uploading less boring.

I can totally reverse your argument there. Why is there so much more
developers who upload SRUs, yet collectively for all of these
developers it is much harder to find out about SRU rejections.
If I would receive an unapproved email / rejection email on a public
mailing list and the issue at hand affects me, I can volunteer to fix
up the SRU bug report as that task can be done by more developers than
those who prepare and upload a fix.

This is for the first time I find out about gcc SRU rejection, and I'd
totally spend the necessory 2 minutes to dig through the bug report
and fix it up.

With a personal email going between 1 SRU team member and 1 developer,
leave the rest of the SRU team members & the rest of the developers in
the dark.

>> And last but not least, not only with this issue, the SRU processing is not the
>> fastest. Yes, there are delays in MIR handling as well, but usually these get
>> addressed faster, and because these can't be delayed infinitely the MIR team
>> usually tries to handle missing and incomplete information in a cooperative way.
>> I would like to see a similar attitude from the SRU team.
>>
>
> In what way have we, the SRU team, not been cooperative? There is a very
> clear wiki page with the process to follow. When it is not followed, we do
> not reject uploads immediately, but ask that it please be followed. Once
> it has been followed, the uploads get processed.
>

Public/Central archival of past times when "follows ups" were required
is one thing that would improve communication.
This way the developers can collective learn and improve.

Are there any privacy concerns with automatically CC a public mailing
list for new/unapproved/rejected queues?


> Some of us are just volunteers these days, so we don't have much time. I
> suspect that the backup of SRU's is one reason for the rolling release
> discussion. With less supported releases and/or packages, the SRU team
> could narrow its focus.
>
>> It is good to have stricter requirements for SRU's than for normal uploads, but
>> imo it's wrong to have these requirements to just discourage SRU's.
>
> I'm sorry that you're discouraged Matthias, but unless there are more
> people available to review SRU's, or more software is put through the
> MRE process, I don't think there's much more we can do and still maintain
> a level of stability in the stable releases.
>

Regards,

Dmitrijs.