launchpad-dev team mailing list archive

[William Grant <me@xxxxxxxxxxxxxxxxxx>]

On Mon, 2009-08-10 at 11:47 +0100, Julian Edwards wrote:
> On Sunday 09 August 2009 23:23:24 Michael Bienia wrote:
> > What about replacing the ticks and crosses with links (and a package
> > icon) to the actual deb for that binary package on that arch?
> > In case I need an old version of a deb (e.g. for a downgrade till a bug
> > is fixed or to check some fixes) I usually need on the current pages too
> > many tries till I find the correct link to get to the page with the link
> > for the deb.
> 
> This is a great idea!  One of the aims of the redesign is to reduce the number 
> of page loads you need to get at important information.
> 
> > BTW: is the publishing history of binary packages (e.g.
> > https://edge.launchpad.net/ubuntu/karmic/i386/gdm) also covered by this
> > redesign (as couldn't stop this data in the current mockups)? I use this
> > page rarely but it was useful in the past to find out what happened to
> > some binary package (binary promotion/demotion).
> > And everytime I need this page it's hard to find. It's nice that the
> > current pages are linked back and forth, but the many links make it
> > sometimes hard to find the one link one searches. When I needed some
> > specific page (e.g. to get an old deb or the binary publishing history)
> > I sometimes found myself on the page I was two clicks before instead of
> > the one I was looking for. I hope the redesign helps in this regard too.
> 
> This is one of the pages that I'd hope we'd be able to drop.  So I have some 
> questions to help me understand what we can do with this:
> 
>  1. Do the binary publication details ever vary across architectures?  If not 
> we could drop that page and move the data to 
> https://edge.launchpad.net/ubuntu/karmic/+package/gdm and link to it from the 
> binary package names in the table on the mockup at 
> http://people.canonical.com/~ed/dspr_mockup2.png.

Not normally, but it's cases where it does happen that are the times
I've most needed that page. Even if you don't want to handle that use
case, what would you do when the data did differ?

It's also not impossible that binaries on some architectures would be
replaced by another source package. What would you do then? This happens
for a shortish time quite frequently, if a binary package moves and the
target FTBFSes on some archs. This can be very confusing, but the
current *BP pages show this pretty quickly.

So, I don't think you can collapse all of the architectures' binary
publication data into one. It doesn't work in the current data model.

>  2. This is the list of the pages we were hoping to drop:
>     * /ubuntu/series/+source/package/version
>     * /ubuntu/series/+package/package
>     * /ubuntu/series/arch/package
>     * /ubuntu/series/arch/package/version 
>  
> Is there anything there that you depend on that we need to worry about?

I think it's a Bad Idea to drop the binary package pages. In the new
scheme there's no way for me to calculate a URL to a binary package -- I
have to know the source package or search, both of which are very slow.
There are already complaints that it takes too many page loads to find a
binary package; I don't see how making it impossible could be a good
thing.

-- 
William Grant