SRU never reviewed, why/how do we avoid that next time?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

SRU never reviewed, why/how do we avoid that next time?

Sebastien Bacher
Hey there,

(sorry if that's not the perfect place but the SRU team doesn't have a
dedicated contact point/mailing list that I know of)

We had a libreoffice bugfix SRU in the week after the 15.10 release to
address some of the user feedback we received from the iso version,
that's still waiting in the queue unreviewed as far as we can tell (the
bugs references didn't get updates, the updater/uploader didn't get
contacted)
https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=libreoffice

That's a bit unfortunate and I'm unsure what happened there. The SRU
team is working on best-effort basis and it's understandable that
reviews take time sometime, but in this case the queue has been
regularly reviewed since, it just seems that everybody ignored that item
for some reason. I can imagine that reviewers tend to stay away from
libreoffice updates since those can be non trivial to review, but in
this case the diff it's pretty trivial.

Coming to the point I would like to try to understand what has been the
issue there (insight from the SRU team welcome ;-) and if we can find a
solution so it doesn't happen next time?

Thanks,
Sebastien Bacher


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: SRU never reviewed, why/how do we avoid that next time?

Christopher Arges
On Wed, May 18, 2016 at 06:08:42PM +0200, Sebastien Bacher wrote:

> Hey there,
>
> (sorry if that's not the perfect place but the SRU team doesn't have a
> dedicated contact point/mailing list that I know of)
>
> We had a libreoffice bugfix SRU in the week after the 15.10 release to
> address some of the user feedback we received from the iso version,
> that's still waiting in the queue unreviewed as far as we can tell (the
> bugs references didn't get updates, the updater/uploader didn't get
> contacted)
> https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=libreoffice
>
> That's a bit unfortunate and I'm unsure what happened there. The SRU
> team is working on best-effort basis and it's understandable that
> reviews take time sometime, but in this case the queue has been
> regularly reviewed since, it just seems that everybody ignored that item
> for some reason. I can imagine that reviewers tend to stay away from
> libreoffice updates since those can be non trivial to review, but in
> this case the diff it's pretty trivial.
>
> Coming to the point I would like to try to understand what has been the
> issue there (insight from the SRU team welcome ;-) and if we can find a
> solution so it doesn't happen next time?
>

If a review doesn't happen in a timely manner I would ping an SRU team member
on their day as shown here:
https://wiki.ubuntu.com/StableReleaseUpdates#Publishing

For the above I'm happy to review today.

--chris

> Thanks,
> Sebastien Bacher
>
>
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: SRU never reviewed, why/how do we avoid that next time?

Sebastien Bacher
Le 18/05/2016 18:16, Christopher Arges a écrit :
> If a review doesn't happen in a timely manner I would ping an SRU team member
> on their day as shown here:
> https://wiki.ubuntu.com/StableReleaseUpdates#Publishing

Hey Christopher,

Yes, pinging/nagging would work, it should be needed though and I don't
like to abuse of those pings. The wiki page seems also quite outdated
(Kate is listed but I don't think she has been active in recent years?)

Thanks for proposing to review it today, I'm unsure the SRU still make
much sense though, now that xenial is out, wily users probably don't
count on it after a cycle and most migrated ...

Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: SRU never reviewed, why/how do we avoid that next time?

Brian Murray-5
In reply to this post by Sebastien Bacher
On Wed, May 18, 2016 at 06:08:42PM +0200, Sebastien Bacher wrote:

> Hey there,
>
> (sorry if that's not the perfect place but the SRU team doesn't have a
> dedicated contact point/mailing list that I know of)
>
> We had a libreoffice bugfix SRU in the week after the 15.10 release to
> address some of the user feedback we received from the iso version,
> that's still waiting in the queue unreviewed as far as we can tell (the
> bugs references didn't get updates, the updater/uploader didn't get
> contacted)
> https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=libreoffice
>
> That's a bit unfortunate and I'm unsure what happened there. The SRU
> team is working on best-effort basis and it's understandable that
> reviews take time sometime, but in this case the queue has been
> regularly reviewed since, it just seems that everybody ignored that item
> for some reason. I can imagine that reviewers tend to stay away from
> libreoffice updates since those can be non trivial to review, but in
> this case the diff it's pretty trivial.
>
> Coming to the point I would like to try to understand what has been the
> issue there (insight from the SRU team welcome ;-) and if we can find a
> solution so it doesn't happen next time?
I think a large part of the problem is that we don't have a great
process for handling things which are not accepted.  An item in the
queue may not be accepted because it isn't fixed in the development
release or missing a test case among other reasons.  In those situations
we comment on the bug and hope it gets addressed while leaving the item
in the queue.  There isn't a way in Launchpad to record this information
about items in the queue - I personally just a browser extension to keep
notes for myself.  Additionally, the SRU team doesn't have a process or
system for conveying that type of information to its members.  In the
end we have long queue of items which are a mix of items that have never
been reviewed, ones that have but we are waiting on the uploader to
fix something, or ones that reviewers don't feel comfortable looking at.

One improvement to the process, from my perspective as an SRU team
member, would be rejecting items that are missing SRU information.  But
it seems rude to reject an upload and throw away someones work just
because a bug is missing information, if we then give the uploader two
weeks(?) we may end up in the situation where have a long messy queue
again.

--
Brian Murray

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SRU never reviewed, why/how do we avoid that next time?

Martin Pitt-4
In reply to this post by Sebastien Bacher
Sebastien Bacher [2016-05-18 18:08 +0200]:
> We had a libreoffice bugfix SRU in the week after the 15.10 release to
> address some of the user feedback we received from the iso version,
> that's still waiting in the queue unreviewed as far as we can tell (the
> bugs references didn't get updates, the updater/uploader didn't get
> contacted)
> https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=libreoffice
>
> That's a bit unfortunate and I'm unsure what happened there.

I'm sure a lot of it can be attributed to responsibility dilution, not
spending enough time on the queues, or people shying away from
reviewing LibO diffs indeed.

However, we have a similar case right now: There is a new LibO
upstream release sitting in the xenial-proposed queue. I reviewed it,
but didn't accept it because the new version didn't get uploaded to
yakkety.

It appears to me that the same happened for wily: The wily SRU was
uploaded on Oct 28, but the xenial package only on Nov 11. So back
then the SRU wasn't accepted because of "devel first", and then it
probably feel into the mental category of "this upload has been
sitting here for several weeks, there must be something bad with it".

So, a lot of fallacies all around :-/, but maybe this helps to
understand what's going on.

Martin

--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: SRU never reviewed, why/how do we avoid that next time?

Sebastien Bacher
Le 19/05/2016 09:55, Martin Pitt a écrit :
> It appears to me that the same happened for wily: The wily SRU was
> uploaded on Oct 28, but the xenial package only on Nov 11. So back
> then the SRU wasn't accepted because of "devel first", and then it
> probably feel into the mental category of "this upload has been
> sitting here for several weeks, there must be something bad with it".

Thanks Martin, that's indeed a possible explanation. While the "upload
to devel first" usually makes sense as a rule I'm unsure it should be
enforced that strictly, or at least we should accomodate for special
cases/situations imho.

Libreoffice (to stay on that example) tends to exercice new compiler
versions/toolchain in challenging ways and it's not uncommon that
getting it to build on a new serie takes some time. Also it's often the
case that we aim at landing a new upstream serie on the new distro (same
for GNOME) and that we prefer to get that going rather than spending
time trying to get the old version to build with e.g a new gcc.

I think that if we are confident that the fixes/updated version are
going to land but just are taking a bit of time there is no real reasons
to block bugfixes to reach users on the stable serie...

Does that make sense?

Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: SRU never reviewed, why/how do we avoid that next time?

Martin Pitt-4
Sebastien Bacher [2016-05-19 10:24 +0200]:

> Libreoffice (to stay on that example) tends to exercice new compiler
> versions/toolchain in challenging ways and it's not uncommon that
> getting it to build on a new serie takes some time. Also it's often the
> case that we aim at landing a new upstream serie on the new distro (same
> for GNOME) and that we prefer to get that going rather than spending
> time trying to get the old version to build with e.g a new gcc.
>
> I think that if we are confident that the fixes/updated version are
> going to land but just are taking a bit of time there is no real reasons
> to block bugfixes to reach users on the stable serie...
>
> Does that make sense?

I think LibO and the kernel are pretty much the only examples where I
can understand and could tolerate this. It would set a precedent which
other people can point to though, and before we know it we are in the
situation that Ubuntu Touch was in the past when people never landed
new things in the devel series first and then fixes got lost, merging
was a pain, etc.

This is the only real point in time when this gets checked by a human,
beyond that we don't have any pressure on developers any more to land
in devel first.

In this particular LibO case this argument also doesn't work -- LibO
5.1.2 already *has* been uploaded to yakkety twice, and it clearly
does build with the new toolchain. There is no reason to assume that
5.1.3 is worse, and if it is, that's a regression that should be
investigated first.

I'd say that cases like this at least require prodding some SRU team
member with some good reason -- I wouldn't expect these uploads to get
accepted as part of the regular workflow.

That said, I accepted LibO for xenial-proposed now. But these kinds of
special cases are hard to track, don't stick around, and don't
generalize.

Martin
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: SRU never reviewed, why/how do we avoid that next time?

Sebastien Bacher
Le 19/05/2016 14:54, Martin Pitt a écrit :
> I'd say that cases like this at least require prodding some SRU team
> member with some good reason -- I wouldn't expect these uploads to get
> accepted as part of the regular workflow.

Thanks for the feedback&review Martin!

I think what you wrote makes sense and indeed there is no reason to not
land the update in yakkety (Bjoern said he would get it ready in the
next days, just need to set up his env for the new serie).

We had the case of build issue/new serie being prepared in wily though,
which might have contributed to that upload not being review

Cheers,
Sebastien

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel