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

[Tiago Stürmer Daitx]

After fixing FTBFS bugs on the newly imported orthanc-digicom and orthanc-webview packages, I got a message saying it was stuck and directing me to update_excuses.

Looking into it I saw a "has no binaries on any arch" message. The project page for those packages did show a note "Note: Some binary packages for this source are not yet published in the repository." as well as a "Pending publication" besides each arch on the "Builds" section.

update_excuses could be improved to show why the package has no binaries - in this case, publication was pending (furthermore, but I'm not sure update_excuses could fetch this information somehow, that was because they were new packages and thus were stuck in the NEW queue waiting to be approved by an archive admin).

[Tiago Stürmer Daitx (tdaitx)]

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

[Tiago Stürmer Daitx (tdaitx)]

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

[Balint Reczey (rbalint)]

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.

[Iain Lane (laney)]

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?

[Balint Reczey (rbalint)]

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.

[Balint Reczey (rbalint)]

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.

[Balint Reczey (rbalint)]

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

[Iain Lane (laney)]

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

[Balint Reczey (rbalint)]

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/

[Iain Lane (laney)]

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