launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 10 August 2009 22:50:25 William Grant wrote:
> On Mon, 2009-08-10 at 11:47 +0100, Julian Edwards wrote:
> >  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?

Well I am trying to establish if it's a valid case or not.  If it only happens 
by mistake then it should be prevented rather than catering for it.

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

That's an interesting use case that I had not thought of.

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

Right, it's getting to the point where I feel the need to do a longer survey 
of current use cases, I don't think the kind of re-design we had in mind will 
work.

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

Have you got any concrete examples of this that we've not already addressed in 
the other page re-designs?

Thanks for the feedback!