Getting stuff backported is too hard

[Iain Lane]

Hiya,

Thanks for replying.

On Sat, Jul 31, 2010 at 10:30:58AM -0400, Scott Kitterman wrote:
>On Saturday, July 31, 2010 06:55:55 am Iain Lane wrote:
>> Hello all,
>>
>> [...]
>>
>>    1) File a bug report, do testing, prepare a new source package if
>>    necessary.
>>    2) Wait for backporting testers to test your package
>>    3) Eventually a backporter (member of the ~ubuntu-backporters team)
>>    will come along and bless your request
>>    4) The package is uploaded
>>
>> I've found that in practice (2) doesn't happen, and the backporters
>> team often takes a very long time to get around to reviewing
>> "confirmed" bugs.
>
>Backports testers is essentially dead.  If you put in the bug that the package
>builds, installs, and runs when you file it, you can skip step 2.  There is no
>requirement for it to be someone else doing the testing.
>
>#3 can take a long time because there aren't very active ~ubunt-backporters at
>the moment (volunteers welcome).  If you do have one you want done, feel free
>to ping me on IRC to review it.  That will almost always get you approval
>within a few hours.

Yeah, I'm aware of this. I'm generally loathe to ping people for
requests that aren't urgent though. Backports generally fall into the
“not urgent” category in my book. And a process which requires this is
a process which needs fixing somehow. Maybe that somehow is more manpower.

>> In contrast, Debian's process[1] is much more lightweight:
>>
>>    1) Build and upload a package with minimal changes from the version
>>    you are backporting
>>
>> Now, obviously there are differences between the two distros, but I
>> wonder if we can make our process more lightweight. I don't propose
>> changing the requirements for package eligibility[2], but instead the
>> technical hurdles.
>
>One of the biggest differences is that backports.org is an external third party
>service and not an official part of Debian.  Ubuntu backports started out this
>way, but was integrated a long time ago.

bpo is planned to become an official Debian service IIRC. I can't find
any link to back this up, but I'm fairly confident it's true. Not sure
how/if the procedure will change though.

> [...]
>
>> I'd like some feedback on whether people feel that there is a problem,
>> feel that backports should be used more and on my proposed
>> process.
>
>This is almost exactly the current process for sourceful backports that
>require changes.
>
>Unlike SRU, backports are usually no different (except a new debian/changelog
>entry) than the current package in the development release.  Also unlike SRU,
>~ubuntu-backporters don't review the diff from the package in the target
>release, they review the diff from the development release.  So, in most cases,
>there would be nothing to reivew in the queue.

That's a good, and interesting, point. I wonder if ubuntu-backporters
review is required at all for no-change backports. Do you think that
there would be a big problem were developers allowed to request
backports themselves without further review? I don't know if this
extends to source-change backports too: would have to think on it some
more. Something like this, for the no-change case:

   1) Developer builds package from development release on target
   release and discovers it works without further changes
   2) Developer files a request with ubuntu-archive subscribed to have
   the package backported. This is very much akin to a sync request
   3) AA processes and syncs into $target-backports.

This places more trust and responsibility in the hands of
developers. I don't know how much review the backporters team does
currently. Perhaps this could be codified in the policy. I suspect
that most backports requested by developers are waved through anyway,
so hopefully no further bad uploads will happen.

>As I see it, there are two problems blocking timely backports at the moment:
>
>1.  No ~ubuntu- backporters are regularly reviewing the backports requests (I
>do it now and then and when pinged, I don't have the impression anyone else is
>more active).  This could be solved by volunteers (and is still an problem if
>your proposal is adopted).  Any MOTU is eligible for this role if they are
>interested.  Please contact me if anyone is interested.

I am interested (and have enquired before, but was rebuffed and then
ignored so didn't push it very hard) — but I don't think the current
process is a very good way for me to spend my time. If we can work
something out then you can count on my help.

Backporting seems to be located out of the sphere of the rest of
Ubuntu development. Was this deliberate when the current procedure was
conceived? My proposal will integrate it somewhat. I don't know if a
significant proportion of backporting requests are coming from
non-developers currently. I think that, if developers are given a more
integral role, the process will become more transparent and efficient
— and therefore more satisfactory to users.

>2.  Archive admins take a long time to process no change backports.  As a non-
>Canonical archive admin, I can accept packages from unapproved, but I can't
>run the backporting script for no-change backports.  It's my impression that
>this is not routinely done by all archive admins on their archive day.  I
>generally see these done by Riddell (who gets bonus points in my book for also
>regularly processing sync requests) or jamesw (I'd imagine others have been
>doing it, just not for backports I've approved).  I have not been following
>details of the archive admin workload, so I don't know what's behind this.

Right, this is something that could perhaps be raised (at a release
meeting?) if it's really a problem. I haven't followed this myself so
have no information to back the claim up.

>Developers uploading no change backports directly would allow me to accept
>them and work around this problem.  As with sync requests from Debian, I do
>believe it's generally better to move code directly from one archive to
>another without having it pass through a developer's system.  There is always
>some small marginal risk of error.

I agree: this should be avoided if possible. This is why I don't
advocate the use of the new syncpackage script (although I have used
it myself in the past for uploads that cannot wait for whatever
reason). My modified proposal removes the need for this.

>I think your proposal of direct uploads would (to the extent I'm available)
>give us a work around for being blocked at this stage.  If there is a backport
>that is particularly urgent for some reason, I think this is reasonable to do
>even under the current rules (it stretches them, but personally, I don't
>mind).  I don't think we should make this the default.  I think we should
>figure out why things are taking so long to process and fix that.

Yep. I am trying to reduce the amount of blocking on other people that
goes into the process as it stands, in order to make it more
streamlined. I think this is where the biggest wins can be found.

This whole train of thought was set off by the amount of upstream
backport PPAs that I'm seeing springing up. This points to a place
where our distribution model isn't meeting the needs of upstream
developers. I would like to think that -backports is a nice home for
these things instead, but currently I wouldn't advocate it to an
upstream as the process is just too clunky. Let's fix this. (I am
aware that the proper fix also blocks on selective backports, but
let's do what we can now)

Iain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100731/e571e9ed/attachment.pgp