launchpad-dev team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxxxxx>]

On Fri, Aug 07, 2009 at 05:00:09PM +0100, Julian Edwards wrote:
> On Friday 07 August 2009 10:27:04 Jonathan Lange wrote:
> > I showed the page to cjwatson & mpt: here's what they said (roughly):
> >
> >   * (cjwatson) It's very important to have a page that has every
> > upload and the changelog entry corresponding to each upload. This is
> > different from the current changelog, since changelog entries can be
> > deleted. Such a page needs to be structured so that the browser's text
> > search can be used to quickly find things.
> 
> Colin, what's the use case for this?

Colin vaguely remembers that at some point in the past somebody changed
alsa-utils to do <something>, but it's no longer in the current
changelog due to an intervening sync from Debian. He wants to use his
browser's text search to look for the changelog entry in all the uploads
that Launchpad's seen. (A search box is too slow because he can't quite
remember the exact string.)

> I am just wondering if there's a better 
> way of doing what you need.  The problem with doing this is that it's not 
> scalable and a pretty costly page to render for some packages.

The scalability problems are surely mostly because at some point in the
past somebody decided that it'd be a great idea to HTMLify person links
and such ... as we've discussed before, it can be done a lot more
quickly if you don't bother to HTMLify things.

> We see a lot of timeouts in the OOPS reports, so if I can find a
> better way we'd avoid that?  We'd also reduce end-user frustration.

I don't mind whether it's on the main source package page or not - I
just want it to be available somewhere. Simply putting it off in a
corner somewhere so that freaks like me can search for uploads would be
fine, I think.

> >   * (cjwatson) On the DSPR page, it's important to be able to quickly
> > get at old versions of binary packages. This helps advanced users who
> > want to test how newer versions of packages have broken their system.
> 
> That page doesn't currently do this - is this a new requirement?  I'm happy to 
> accommodate but I want to make sure you're not referring to the DSP page.

Whoa - let's keep a distinction between "new requirement" and "thing
Colin thought might be a good idea if you're redesigning the busted old
navigation pages anyway" ...

Binary packages are the most obvious logical unit presented to users (as
opposed to developers), and it seems like a bit of a hole that it's
difficult to follow back through their history. As you say, it's not
there right now.

> >   * (cjwatson) The dspr_mockup.png file says that 'Table entries link
> > to build pages'. However, every build for a given (arch,
> > sourcepackage) will be the same.
> 
> Right, that's an issue.
> 
> How about the headings link to the builds instead, and we put the ticks and 
> crosses next to the headings?  The table can then contain a check mark where a 
> package is built for each arch.

Seems OK to me.

> >   * (cjwatson) Saying that the only build is i386 when you really mean
> > architecture-independent build is confusing.
> 
> Right - that could be detected and we can display "arch-indep" instead?

Perhaps, yes. In any event it would be less confusing if there weren't
ticks and crosses in each table cell.

-- 
Colin Watson                           [cjwatson@xxxxxxxxxxxxxxxxxxxxxx]