Getting stuff backported is too hard

[Scott Kitterman]

On Saturday, July 31, 2010 06:55:55 am Iain Lane wrote:
> Hello all,
> 
> I've just been thinking about backports. It seems (to me at least),
> that the process[0] for getting stuff into -backports isn't working. It
> goes a bit like this:
> 
>    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.

> 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.

> I think that developers should be able to upload to backports if they
> feel it is warranted. A bug should be filed and the backporters team
> subscribed for review. Once a backport is acked, an archive admin can
> then accept the upload. You'll notice that this mirrors the SRU
> process which has recently evolved into something which is much easier
> for developers and SRU team members alike. So the new process would
> look something like:
> 
>    1) Developer decides a backport is warranted, perhaps/probably from
>    user or upstream requests
>    2) Developer files bug report and prepares package with minimal
>    changes from the current development release
>    3) Developer uploads package to $target-backports
>    4) Package lands in UNAPPROVED and backport team members review from
>    here
>    5.1) If acked, ubuntu-archive is subscribed to ACCEPT the package
>    5.2) If nacked, ubuntu-archive is subcribed to REJECT the package
> 
> This may help reduce the proliferation of unofficial backporting PPAs
> that have sprung up recently, but it's not so easy to selectively
> enable backports so this might require further tool support.

We've had a spec for this for several cycles.  Some work has been done, but 
it's not been implemented.  I think it was first proposed for Jaunty.

> 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.

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.

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.

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 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.

Scott K
> 
> [0]
> https://help.ubuntu.com/community/UbuntuBackports#Backport%20Process
> 
> [1] http://backports.org/dokuwiki/doku.php?id=contribute
> 
> [2]
> https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%
> 20packages