update_excuses: show why a package "does not have binaries"

Attached screenshot of the "has no binaries on any arch" from update_excuses.

Attached screenshot of the orthanc-webviewer containing "Note: Some binary packages for this source are not yet published in the repository." and "Pending publication" messages.

https://launchpad.net/ubuntu/+source/orthanc-webviewer

One improvement in this case would be automatically listing bugs with "ftbfs" tag on update_excuses.

This would help assessing the current state of the package quickly and would also help recording observations in the bug, for example when packaging in Debian stopped providing binary packages for a given set of architectures and the package is waiting for removals in Ubuntu.

Looking at britney's code it seems a script is needed to collect the ftbfs bugs from Launchpad and britney could load them like the "block-proposed" bugs but existing "ftbfs" bugs should not block migration just provide explanation for packages blocked due to missing binaries.

I'm a bit worried about maintaining extra code in (makes rebasing harder) and around (needs to be maintained) proposed-migration.

I think most Ubuntu developers ought to be able to find bugs against packages without having them listed on update_excuses.html. FTBFS is just one reason why a package might not migrate so I'm also worried about being vulnerable to mission creep and turning update_excuses into a one-stop "what's wrong here?" shop.

What do you think? Is this worth it? Or can we say that we expect developers to be able to find out what's wrong on their own?

I think showing "ftbfs" bugs could be beneficial for Debian as well thus it does not have to be part of the delta. Debian's script would collect the FTBFS buts from Debian's BTS, that is not a huge difference IMO.

I agree that Ubuntu devs should be able to find bugs of "foo" when "foo" is blocked, but sometimes (many times as I saw) the bug is not in "foo" but in a transitive dependency and the build/test log is not always verbose enough to figure out from the first glance what goes wrong.

Avoiding the mission creep is a valid concern, but IMO update_excuses is actually one of the very important stops where people spend time to look for blocker issues and providing them a good set of pointers helps eliminating duplicate work.

A good example of collecting the "ftbfs" bugs is here:
http://qa.ubuntuwire.org/ftbfs/

Having the link to the bug helps greatly in following the issues without having to parse the build log again and again.

What I'm aiming at is having fewer packages stuck in migration but with more helpful information available for unblocking them.

On Tue, Apr 18, 2017 at 11:11:18AM -0000, Balint Reczey wrote:
> What I'm aiming at is having fewer packages stuck in migration but with
> more helpful information available for unblocking them.

That's very good - I'm just a little worried about having
proposed-migration itself be the place that centralises all of this
information.

Not saying that it should definitely *not* be there, but we might want
to consider alternatives first - like coming up with an Ubuntu specific
simple PTS-type thing to keep our parts separate from upstream p-m.
(update_excuses.yaml exists.)

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Having PTS and tracker in Debian helps greatly in getting an overview per source package, but are not, and I think can't really be used for visualizing queues, like the migration queue.

update_excuses.yaml can already be useful for example I used it to create re-run links for failed autopkgtests due to missing versioned dependencies [1], but making such features globally available would be better than running private helper scripts.

[1] http://pastebin.ubuntu.com/24356986/

On Thu, Apr 20, 2017 at 05:52:21PM -0000, Balint Reczey wrote:
> Having PTS and tracker in Debian helps greatly in getting an overview
> per source package, but are not, and I think can't really be used for
> visualizing queues, like the migration queue.
>
> update_excuses.yaml can already be useful for example I used it to
> create re-run links for failed autopkgtests due to missing versioned
> dependencies [1], but making such features globally available would be
> better than running private helper scripts.
>
> [1] http://pastebin.ubuntu.com/24356986/

I'm not suggesting a private script.

I'm saying: consider building on top of britney rather than building
more things into britney.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]