SoyuzDistroSeriesQueuePage/Inputs

Not logged in - Log In / Register

Bugs

Email exchange between Colin and LP developers in May 2008

On Mon, May 05, 2008 at 08:39:29PM -0300, Christian Robottom Reis wrote:
> > Now that some of the dust has settled, how does the layout of the page
> > look? Have you used it to do some archive admin? And can we disable
> > access to the shell script now? :-)

As a matter of fact I used it last night for some NEW processing.
(There's a lot of stuff in NEW right now, and this will likely continue
to be the case until DebianImportFreeze.) In short: no, you can't
disable the shell script yet or I will have to cry. :-)

In general, driving the page is a bit of an ergonomic nightmare and it
literally made my wrists hurt:

  * The page badly needs an "expand all" button, or else just ditch the
    expanders and show all items expanded by default; try driving it
    from the keyboard for a while and you'll see what I mean.

  * The default submit button is Reject (as I found out when I pressed
    Enter on an input element by mistake instead of space) rather than
    Accept. This should be changed.

  * To compound the above, unlike in the command-line UI, there's no way
    to retrieve inadvertently rejected uploads from the REJECTED queue
    and choose to accept them instead. I had to resort to 'queue -Q
    rejected accept'.


These are relatively trivial items, though. My main problem was that the
standard workflow for large-scale NEW processing is as follows:

  * pick a source package name, and find all its binaries
  * look at its current overrides in the archive
  * check that the suggested overrides in the queue are sane, and adjust
    if necessary
  * accept (in the command-line UI, typically by package name)

Firstly, this is a lot more inconvenient in the web UI because you have
to select all the binaries for a given sourcepackagerelease
individually. (And please don't mistake me here - I think there are
special circumstances where you *would* want this, so I wouldn't want
individual selection to become impossible.) I think this would be a lot
better if all the binaries for a given sourcepackagerelease were sorted
next to each other by default, rather than slavishly in date order. Date
order is useful for determining which source upload has been waiting for
longest, but for binaries a bit of grouping is much more valuable. You
can't do this by table column sorting for the following reasons:

  * the page is batched so many of the entries you want are in other
    batches
  * sorting by the Package column doesn't do anything obviously useful
  * further to the above, if you try to sort by the Package column then
    the expanders behave completely wrongly, with the expanded items
    showing up at the top
  * in the trivial bin: if you click on the same column heading twice
    then the buttons at the bottom move up to the top

Without this, one is reduced to checking each binary upload individually
rather than together with its typically nearly identical fellows for
other architectures, which is several times slower and more tedious.

The batch size is far too small for serious bulk processing. Bear in
mind that, since we have seven architectures, 30 items in the NEW queue
often equates to about four complete sets of binaries at most; more
often packages end up split up among batches in an unhelpful manner.


I mentioned above that one needs to look at the current overrides in the
archive. Sometimes this is addressed by +queue's display of the existing
overrides for other binary packages, but often not. For instance, an
expanded view of one of the items in the NEW queue at the moment is as
follows:

  postgresql-plproxy (sparc)                                2.0.4-1                        Release 1 hour ago
    postgresql-8.3-plproxy_2.0.4-1_sparc.deb (25.6 KiB) NEW 2.0.4-1 universe misc optional

Now, I know that a binary package whose control file aims it at main
will land in universe by default. For minimal archive breakage, what I
really want to do is see whether the source package and any other
binaries in the same source were previously in main, in which case
chances are that this new version should go to main as well. It would be
much more efficient if +queue showed me something like this:

  postgresql-plproxy (sparc)                                2.0.4-1 universe misc          Release 1 hour ago
    postgresql-8.3-plproxy_2.0.4-1_sparc.deb (25.6 KiB) NEW 2.0.4-1 universe misc optional
    (postgresql-8.2-plproxy OLD                             2.0.2-1 universe misc optional)

... where the component and section on the upload header row for binary
packages are filled in from the source package, and the OLD row I've
rendered inside parentheses would probably be all in italics. OLD rows
would be generated for any binary package currently in the archive for
the architecture in question that isn't part of this upload.

Doing this at the moment involves lots of independent navigation. There
aren't even any links to the source package page so that you can go and
look there without too much trouble (in fairness, that's because the
obvious place for such a link is being used for the .changes file to
save a table column). That would be much harder work than just showing
it all inline in the queue display, though.

-- Colin Watson

On Tuesday 06 May 2008 09:32:38 Colin Watson wrote:
> > On Mon, May 05, 2008 at 08:39:29PM -0300, Christian Robottom Reis wrote:
>> > > Now that some of the dust has settled, how does the layout of the page
>> > > look? Have you used it to do some archive admin? And can we disable
>> > > access to the shell script now? :-)
> > 
> > As a matter of fact I used it last night for some NEW processing.
> > (There's a lot of stuff in NEW right now, and this will likely continue
> > to be the case until DebianImportFreeze.) In short: no, you can't
> > disable the shell script yet or I will have to cry. :-)

I figured this might have go through a few iterations!

Thanks for the detailed feedback, I've replied to some of your points inline.

> > In general, driving the page is a bit of an ergonomic nightmare and it
> > literally made my wrists hurt:
> > 
> >   * The page badly needs an "expand all" button, or else just ditch the
> >     expanders and show all items expanded by default; try driving it
> >     from the keyboard for a while and you'll see what I mean.

Ok, this should be easy enough to fix with some JS.  I definitely see what you mean.

> > 
> >   * The default submit button is Reject (as I found out when I pressed
> >     Enter on an input element by mistake instead of space) rather than
> >     Accept. This should be changed.

I think we can change the default focus to "accept".  mpt?

> > 
> >   * To compound the above, unlike in the command-line UI, there's no way
> >     to retrieve inadvertently rejected uploads from the REJECTED queue
> >     and choose to accept them instead. I had to resort to 'queue -Q
> >     rejected accept'.

This is trivial to fix, although it will look a bit weird having the buttons and overrides on the rejection page!

> > 
> > 
> > These are relatively trivial items, though. My main problem was that the
> > standard workflow for large-scale NEW processing is as follows:
> > 
> >   * pick a source package name, and find all its binaries
> >   * look at its current overrides in the archive
> >   * check that the suggested overrides in the queue are sane, and adjust
> >     if necessary
> >   * accept (in the command-line UI, typically by package name)
> > 
> > Firstly, this is a lot more inconvenient in the web UI because you have
> > to select all the binaries for a given sourcepackagerelease
> > individually. (And please don't mistake me here - I think there are
> > special circumstances where you *would* want this, so I wouldn't want
> > individual selection to become impossible.) 

Right - I think we discussed this a lot last month.

We know that the current selection mechanism needs some work and with regard to binaries we took the decision to make it an "all or nothing" approach for now to keep the work do-able for the last LP release, and to enable MOTU to some extent (well, Hobbsee for now since no other MOTU has permission - yet).

The current plan is to make a new page where you can select individual binaries in a build upload, although having read your workflow description I wonder whether this is convenient or not, and is it better or worse than cluttering the existing interface with more checkboxes and buttons.

> > I think this would be a lot 
> > better if all the binaries for a given sourcepackagerelease were sorted
> > next to each other by default, rather than slavishly in date order. Date
> > order is useful for determining which source upload has been waiting for
> > longest, but for binaries a bit of grouping is much more valuable. You
> > can't do this by table column sorting for the following reasons:
> > 
> >   * the page is batched so many of the entries you want are in other
> >     batches

Is there any reason why the "show uploads with names like" filtering box won't work for you?

> >   * sorting by the Package column doesn't do anything obviously useful
> >   * further to the above, if you try to sort by the Package column then
> >     the expanders behave completely wrongly, with the expanded items
> >     showing up at the top
> >   * in the trivial bin: if you click on the same column heading twice
> >     then the buttons at the bottom move up to the top

Ooo that's fun.

That's a by-product of having to put the buttons in their own row at the bottom so that they line up with the other columns.  Perhaps mpt has some ideas on what to do about that?

> > 
> > Without this, one is reduced to checking each binary upload individually
> > rather than together with its typically nearly identical fellows for
> > other architectures, which is several times slower and more tedious.

If you use the name filter and we have a "select all" button, would that alleviate this problem?

> > 
> > The batch size is far too small for serious bulk processing. Bear in
> > mind that, since we have seven architectures, 30 items in the NEW queue
> > often equates to about four complete sets of binaries at most; more
> > often packages end up split up among batches in an unhelpful manner.

I increased it from 25 in the last release but I am wary of going further (75 was requested in a bug) because of page timeouts.  The current NEW queue on Intrepid is generating 1617 queries so we'll need to do some optimisation before that batch size can be increased.

> > 
> > 
> > I mentioned above that one needs to look at the current overrides in the
> > archive. Sometimes this is addressed by +queue's display of the existing
> > overrides for other binary packages, but often not. For instance, an
> > expanded view of one of the items in the NEW queue at the moment is as
> > follows:
> > 
> >   postgresql-plproxy (sparc)                                2.0.4-1                        Release 1 hour ago
> >     postgresql-8.3-plproxy_2.0.4-1_sparc.deb (25.6 KiB) NEW 2.0.4-1 universe misc optional
> > 
> > Now, I know that a binary package whose control file aims it at main
> > will land in universe by default. For minimal archive breakage, what I
> > really want to do is see whether the source package and any other
> > binaries in the same source were previously in main, in which case
> > chances are that this new version should go to main as well. It would be
> > much more efficient if +queue showed me something like this:
> > 
> >   postgresql-plproxy (sparc)                                2.0.4-1 universe misc          Release 1 hour ago
> >     postgresql-8.3-plproxy_2.0.4-1_sparc.deb (25.6 KiB) NEW 2.0.4-1 universe misc optional
> >     (postgresql-8.2-plproxy OLD                             2.0.2-1 universe misc optional)
> > 
> > ... where the component and section on the upload header row for binary
> > packages are filled in from the source package, and the OLD row I've
> > rendered inside parentheses would probably be all in italics. OLD rows
> > would be generated for any binary package currently in the archive for
> > the architecture in question that isn't part of this upload.
> > 
> > Doing this at the moment involves lots of independent navigation. There
> > aren't even any links to the source package page so that you can go and
> > look there without too much trouble (in fairness, that's because the
> > obvious place for such a link is being used for the .changes file to
> > save a table column). That would be much harder work than just showing
> > it all inline in the queue display, though.
> > 

Ok, let me have a think about this.

Thanks a lot for the feedback, that's all very useful.

Cheers
J


On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
> > On Tuesday 06 May 2008 09:32:38 Colin Watson wrote:
>> > > On Mon, May 05, 2008 at 08:39:29PM -0300, Christian Robottom Reis wrote:
>>> > > > Now that some of the dust has settled, how does the layout of the page
>>> > > > look? Have you used it to do some archive admin? And can we disable
>>> > > > access to the shell script now? :-)
>> > > 
>> > > As a matter of fact I used it last night for some NEW processing.
>> > > (There's a lot of stuff in NEW right now, and this will likely continue
>> > > to be the case until DebianImportFreeze.) In short: no, you can't
>> > > disable the shell script yet or I will have to cry. :-)
> > 
> > I figured this might have go through a few iterations!
> > 
> > Thanks for the detailed feedback, I've replied to some of your points inline.

Thanks.

> > The current plan is to make a new page where you can select individual
> > binaries in a build upload, although having read your workflow
> > description I wonder whether this is convenient or not, and is it
> > better or worse than cluttering the existing interface with more
> > checkboxes and buttons.

I'm not sure what "select individual binaries in a build upload" means -
is this a separate page for each set of binaries? If so, that would be a
pain - see below.

>> > > I think this would be a lot 
>> > > better if all the binaries for a given sourcepackagerelease were sorted
>> > > next to each other by default, rather than slavishly in date order. Date
>> > > order is useful for determining which source upload has been waiting for
>> > > longest, but for binaries a bit of grouping is much more valuable. You
>> > > can't do this by table column sorting for the following reasons:
>> > > 
>> > >   * the page is batched so many of the entries you want are in other
>> > >     batches
> > 
> > Is there any reason why the "show uploads with names like" filtering
> > box won't work for you?

It would be incredibly tedious to have to click through for every
package. Bear in mind that there are hundreds of the things. I want to
have the whole queue grouped sensibly on a single (possibly batched)
page, not to have to visit a separate page or enter a package name for
each set of binaries.

>> > > Without this, one is reduced to checking each binary upload individually
>> > > rather than together with its typically nearly identical fellows for
>> > > other architectures, which is several times slower and more tedious.
> > 
> > If you use the name filter and we have a "select all" button, would
> > that alleviate this problem?

As above, the name filter is too cumbersome. Some kind of "select all
from this SPR" would work although I have no idea how you'd present that
in the UI. Grouping would really be easier to cope with.

>> > > The batch size is far too small for serious bulk processing. Bear in
>> > > mind that, since we have seven architectures, 30 items in the NEW queue
>> > > often equates to about four complete sets of binaries at most; more
>> > > often packages end up split up among batches in an unhelpful manner.
> > 
> > I increased it from 25 in the last release but I am wary of going
> > further (75 was requested in a bug) because of page timeouts.  The
> > current NEW queue on Intrepid is generating 1617 queries so we'll need
> > to do some optimisation before that batch size can be increased.

The number of items in the queue as a whole will fluctuate a lot, of
course. I've been working on the NEW queue (using the command-line UI!)
this morning and it's down to 73 items - not sure how many queries that
translates to. Once we start syncing in new source packages from Debian
(at the moment we're only syncing new versions of existing ones - there
are some more checks to do before we can open the hosepipe all the way),
it wouldn't surprise me if we got up to 1000 items at some point.

Cheers,


On Tue, May 06, 2008 at 10:30:35AM +0100, Colin Watson wrote:
> > On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>> > > Is there any reason why the "show uploads with names like" filtering
>> > > box won't work for you?
> > 
> > It would be incredibly tedious to have to click through for every
> > package. Bear in mind that there are hundreds of the things. I want to
> > have the whole queue grouped sensibly on a single (possibly batched)
> > page, not to have to visit a separate page or enter a package name for
> > each set of binaries.

It occurs to me that it may not be obvious to all readers why scaling
and speed is important here. Please ignore this lecture if you already
know it. :-)

It does matter that all packages get checked before they're accepted
into the archive. However, just as we don't have the manpower to package
everything ourselves, we don't have the archive administrator manpower
to check everything in detail either! In the same way that we trust the
Debian project to do a large amount of packaging which we then sync into
our archive, we also trust that the Debian archive administrators have
done a good job of checking such packages for sanity (and indeed they
typically go into a lot of detail).

Thus, when we're syncing packages from Debian, Ubuntu archive
administrators are not sitting there doing detailed sanity checks on
each and every one. Instead, our function is usually to ensure that
everything lands in roughly the correct component in Ubuntu, and also to
keep an eye out for packages we know we don't want in our archive for
some reason (previously removed but we forgot to blacklist it, or
sometimes part of a general class of packages that have been removed -
for example we don't generally include kernel patch packages in Ubuntu
at the moment, preferring that all such useful modules be in
linux-ubuntu-modules instead). With the command-line UI, we typically
spend maybe 20-30 seconds per package, limited mainly by the way the
queue tool takes several seconds to connect to the database on each
invocation.

This is, of course, wildly different from how we treat new packages
uploaded directly to our archive, where we do perform extensive sanity
(and especially licence) checks.



On Tuesday 06 May 2008 10:30:35 Colin Watson wrote:
>> > > The current plan is to make a new page where you can select individual
>> > > binaries in a build upload, although having read your workflow
>> > > description I wonder whether this is convenient or not, and is it
>> > > better or worse than cluttering the existing interface with more
>> > > checkboxes and buttons.
> > 
> > I'm not sure what "select individual binaries in a build upload" means -
> > is this a separate page for each set of binaries? If so, that would be a
> > pain - see below.

Yes - it was to get around the limitations of the existing page because we're using the accept button to also override.  The checkboxes next to the top-level upload lines have this dual functionality, but if we put them next to individual binaries they could only mean "override" so Kiko suggested a separate page for differently overriding individual binaries in a single upload.

> > 
>>> > > > I think this would be a lot 
>>> > > > better if all the binaries for a given sourcepackagerelease were sorted
>>> > > > next to each other by default, rather than slavishly in date order. Date
>>> > > > order is useful for determining which source upload has been waiting for
>>> > > > longest, but for binaries a bit of grouping is much more valuable. You
>>> > > > can't do this by table column sorting for the following reasons:
>>> > > > 
>>> > > >   * the page is batched so many of the entries you want are in other
>>> > > >     batches
>> > > 
>> > > Is there any reason why the "show uploads with names like" filtering
>> > > box won't work for you?
> > 
> > It would be incredibly tedious to have to click through for every
> > package. Bear in mind that there are hundreds of the things. I want to
> > have the whole queue grouped sensibly on a single (possibly batched)
> > page, not to have to visit a separate page or enter a package name for
> > each set of binaries.

It sounds like we just need to sort the page results a bit more intelligently then.

> > 
>>> > > > Without this, one is reduced to checking each binary upload individually
>>> > > > rather than together with its typically nearly identical fellows for
>>> > > > other architectures, which is several times slower and more tedious.
>> > > 
>> > > If you use the name filter and we have a "select all" button, would
>> > > that alleviate this problem?
> > 
> > As above, the name filter is too cumbersome. Some kind of "select all
> > from this SPR" would work although I have no idea how you'd present that
> > in the UI. Grouping would really be easier to cope with.

Yep.

>>> > > > The batch size is far too small for serious bulk processing. Bear in
>>> > > > mind that, since we have seven architectures, 30 items in the NEW queue
>>> > > > often equates to about four complete sets of binaries at most; more
>>> > > > often packages end up split up among batches in an unhelpful manner.
>> > > 
>> > > I increased it from 25 in the last release but I am wary of going
>> > > further (75 was requested in a bug) because of page timeouts.  The
>> > > current NEW queue on Intrepid is generating 1617 queries so we'll need
>> > > to do some optimisation before that batch size can be increased.
> > 
> > The number of items in the queue as a whole will fluctuate a lot, of
> > course. I've been working on the NEW queue (using the command-line UI!)
> > this morning and it's down to 73 items - not sure how many queries that
> > translates to. Once we start syncing in new source packages from Debian
> > (at the moment we're only syncing new versions of existing ones - there
> > are some more checks to do before we can open the hosepipe all the way),
> > it wouldn't surprise me if we got up to 1000 items at some point.

Okay.

In its current state, I imagine that the UI is (mostly) fine for MOTU.  However, you guys are used to using the command line tool so your expectations are set accordingly.  I think we should get together at UDS and chat about this in person, it's going to be much easier that way where we can draw diagrams and wave our hands about.

Cheers
J


On Tue, May 06, 2008 at 11:32:57AM +0100, Julian Edwards wrote:
> > In its current state, I imagine that the UI is (mostly) fine for MOTU.
> > However, you guys are used to using the command line tool so your
> > expectations are set accordingly.

Well, perhaps more importantly, MOTU don't do the serious bulk
processing, at least at the moment. However, if they did, then I expect
that they would have similar performance requirements independent of
previously-set expectations.

> > I think we should get together at UDS and chat about this in person,
> > it's going to be much easier that way where we can draw diagrams and
> > wave our hands about.

Certainly. (I may be rather slammed at UDS personally, but there are
other archive admins who can chip in.)

Cheers,

-- Colin Watson 

On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>> > >   * The default submit button is Reject (as I found out when I pressed
>> > >     Enter on an input element by mistake instead of space) rather than
>> > >     Accept. This should be changed.
> > 
> > I think we can change the default focus to "accept".  mpt?

The default focus is the first button to appear in the form, so you'd
need to change the design there. My original design had a do-nothing
default for this reason.

>> > >   * To compound the above, unlike in the command-line UI, there's no way
>> > >     to retrieve inadvertently rejected uploads from the REJECTED queue
>> > >     and choose to accept them instead. I had to resort to 'queue -Q
>> > >     rejected accept'.
> > 
> > This is trivial to fix, although it will look a bit weird having the
> > buttons and overrides on the rejection page!

How so?

> > The current plan is to make a new page where you can select individual
> > binaries in a build upload, although having read your workflow
> > description I wonder whether this is convenient or not, and is it
> > better or worse than cluttering the existing interface with more
> > checkboxes and buttons.

Well, IIRC Colin did point out that it's a minority of cases where he
actually needs to override individual binaries to different values.

>> > >   * sorting by the Package column doesn't do anything obviously useful
>> > >   * further to the above, if you try to sort by the Package column then
>> > >     the expanders behave completely wrongly, with the expanded items
>> > >     showing up at the top
>> > >   * in the trivial bin: if you click on the same column heading twice
>> > >     then the buttons at the bottom move up to the top
> > 
> > Ooo that's fun.

Column-sorting with expanders and buttons inline will not work without
some serious engineering.

>> > > The batch size is far too small for serious bulk processing. Bear in
>> > > mind that, since we have seven architectures, 30 items in the NEW queue
>> > > often equates to about four complete sets of binaries at most; more
>> > > often packages end up split up among batches in an unhelpful manner.
> > 
> > I increased it from 25 in the last release but I am wary of going
> > further (75 was requested in a bug) because of page timeouts.  The
> > current NEW queue on Intrepid is generating 1617 queries so we'll need
> > to do some optimisation before that batch size can be increased.

Yeah, we definitely should allow displaying at least 500 items, so the
queries do need work there. I'm surprised at the number of queries there
-- that's at least a High priority bug to fix, because no DB server
wants to be hit that many times for a single page.

>> > > I mentioned above that one needs to look at the current overrides in the
>> > > archive. Sometimes this is addressed by +queue's display of the existing
>> > > overrides for other binary packages, but often not. For instance, an
>> > > expanded view of one of the items in the NEW queue at the moment is as
>> > > follows:
>> > > 
>> > >   postgresql-plproxy (sparc)                                2.0.4-1                        Release 1 hour ago
>> > >     postgresql-8.3-plproxy_2.0.4-1_sparc.deb (25.6 KiB) NEW 2.0.4-1 universe misc optional

So in this case the package metadata says universe/misc/optional, or is
this just because we auto-override to universe?

>> > > ... where the component and section on the upload header row for binary
>> > > packages are filled in from the source package, and the OLD row I've
>> > > rendered inside parentheses would probably be all in italics. OLD rows
>> > > would be generated for any binary package currently in the archive for
>> > > the architecture in question that isn't part of this upload.

Meaning the upload might not include all the binary packages that are
currently in the archive? When would that happen? I'm assuming it's when
the source package has changed to produce less (or different) binaries
than before.
-- Christian Robottom Reis 


On Tue, May 06, 2008 at 03:12:50PM -0300, Christian Robottom Reis wrote:
> > On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>> > > Colin Watson wrote:
>>> > > > I mentioned above that one needs to look at the current overrides in the
>>> > > > archive. Sometimes this is addressed by +queue's display of the existing
>>> > > > overrides for other binary packages, but often not. For instance, an
>>> > > > expanded view of one of the items in the NEW queue at the moment is as
>>> > > > follows:
>>> > > > 
>>> > > >   postgresql-plproxy (sparc)                                2.0.4-1                        Release 1 hour ago
>>> > > >     postgresql-8.3-plproxy_2.0.4-1_sparc.deb (25.6 KiB) NEW 2.0.4-1 universe misc optional
> > 
> > So in this case the package metadata says universe/misc/optional, or is
> > this just because we auto-override to universe?

This is an auto-override; the package metadata says main/misc/optional.

>>> > > > ... where the component and section on the upload header row for binary
>>> > > > packages are filled in from the source package, and the OLD row I've
>>> > > > rendered inside parentheses would probably be all in italics. OLD rows
>>> > > > would be generated for any binary package currently in the archive for
>>> > > > the architecture in question that isn't part of this upload.
> > 
> > Meaning the upload might not include all the binary packages that are
> > currently in the archive? When would that happen? I'm assuming it's when
> > the source package has changed to produce less (or different) binaries
> > than before.

Precisely as you say. It's very common when e.g. library versions
change. Indeed, Launchpad ships a script (archive-cruft-check.py) for
archive admins to go through and remove those old binaries later (it's
important that this not be an entirely automatic process, for reasons
that aren't important here but that I can explain separately if you
like).

In this case, the postgresql-plproxy source package used to build only
the postgresql-8.2-plproxy binary package, but now builds only the
postgresql-8.3-plproxy binary package. In other circumstances it might
have decided to build both binary packages in parallel for a period of
time; I assume that either wasn't felt necessary or wasn't possible in
this case, and this sort of thing is so common that I haven't felt the
need to investigate.

Cheers,

-- Colin Watson 

On Tuesday 06 May 2008 19:12:50 Christian Robottom Reis wrote:
> > On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>>> > > >   * The default submit button is Reject (as I found out when I pressed
>>> > > >     Enter on an input element by mistake instead of space) rather than
>>> > > >     Accept. This should be changed.
>> > > 
>> > > I think we can change the default focus to "accept".  mpt?
> > 
> > The default focus is the first button to appear in the form, so you'd
> > need to change the design there. My original design had a do-nothing
> > default for this reason.

IIRC mpt vetoed that design.  But we can set the default focus via JS though, right?

> > 
>>> > > >   * To compound the above, unlike in the command-line UI, there's no way
>>> > > >     to retrieve inadvertently rejected uploads from the REJECTED queue
>>> > > >     and choose to accept them instead. I had to resort to 'queue -Q
>>> > > >     rejected accept'.
>> > > 
>> > > This is trivial to fix, although it will look a bit weird having the
>> > > buttons and overrides on the rejection page!
> > 
> > How so?

Accepting and overriding from the rejected items queue is a little counter-intuitive to me.  But if it's useful, then it should go in, it's a one-liner.

>> > > The current plan is to make a new page where you can select individual
>> > > binaries in a build upload, although having read your workflow
>> > > description I wonder whether this is convenient or not, and is it
>> > > better or worse than cluttering the existing interface with more
>> > > checkboxes and buttons.
> > 
> > Well, IIRC Colin did point out that it's a minority of cases where he
> > actually needs to override individual binaries to different values.

He did, and I have a strange feeling that we might all not be talking about the same thing here!  I think UDS would be a better place to talk about it.

> > Yeah, we definitely should allow displaying at least 500 items, so the
> > queries do need work there. I'm surprised at the number of queries there
> > -- that's at least a High priority bug to fix, because no DB server
> > wants to be hit that many times for a single page.

Yeah, I filed a bug, I'll try and get to it this cycle.

The other usability issues are also filed and targeted to 1.2.5.

Cheers.


Julian Edwards wrote:
> > On Tuesday 06 May 2008 19:12:50 Christian Robottom Reis wrote:
>> >> On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>>>> >>>>   * The default submit button is Reject (as I found out when I pressed
>>>> >>>>     Enter on an input element by mistake instead of space) rather than
>>>> >>>>     Accept. This should be changed.
>>> >>> I think we can change the default focus to "accept".  mpt?
>> >> The default focus is the first button to appear in the form, so you'd
>> >> need to change the design there. My original design had a do-nothing
>> >> default for this reason.
> > 
> > IIRC mpt vetoed that design.  But we can set the default focus via JS though, right?

If the design allows for a comment when accepting, then the default
focus can be in a text box to enter a comment.  The default "no comment"
acceptance becomes "tab->return".

I don't like the idea of a button being focused on the page immediately.
 I prefer the idea that I can easily tab to the button that does what
I'll most often want to do.

It's a bit of a brainfuck for me to go to a page that has a workflow
that is heading in a particular direction, and be presented with a
default action of jumping out of the workflow.

I see this on our "subscribe to a bug" pages.

If the UI guideline says "the first button should not progress the
workflow, because it will be focused when the page is loaded", then that
guideline represents a logical consequence of a flawed premise.

-- Steve


On Wed, May 07, 2008 at 01:59:28PM +0200, Steve Alexander wrote:
> > Julian Edwards wrote:
>> > > On Tuesday 06 May 2008 19:12:50 Christian Robottom Reis wrote:
>>> > >> On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>>>> > >>> I think we can change the default focus to "accept".  mpt?
>>> > >> 
>>> > >> The default focus is the first button to appear in the form, so you'd
>>> > >> need to change the design there. My original design had a do-nothing
>>> > >> default for this reason.
>> > > 
>> > > IIRC mpt vetoed that design.  But we can set the default focus via JS though, right?
> > 
> > If the design allows for a comment when accepting, then the default
> > focus can be in a text box to enter a comment.  The default "no comment"
> > acceptance becomes "tab->return".

It doesn't allow for such a comment. I don't think a comment in that
situation would be likely to be useful ("hi, I accepted your package,
hope you like it"). That said, there is a long-standing bug for
requiring comments when rejecting an upload:

  https://bugs.launchpad.net/soyuz/+bug/31750

> > I don't like the idea of a button being focused on the page immediately.
> >  I prefer the idea that I can easily tab to the button that does what
> > I'll most often want to do.
> > 
> > It's a bit of a brainfuck for me to go to a page that has a workflow
> > that is heading in a particular direction, and be presented with a
> > default action of jumping out of the workflow.

I think I agree here.

-- Colin Watson 



>> >> I don't like the idea of a button being focused on the page immediately.
>> >>  I prefer the idea that I can easily tab to the button that does what
>> >> I'll most often want to do.
>> >>
>> >> It's a bit of a brainfuck for me to go to a page that has a workflow
>> >> that is heading in a particular direction, and be presented with a
>> >> default action of jumping out of the workflow.
> > 
> > I think I agree here.

In other words, if there's a risk that a user will accidentally accept a
package by hitting "return" twice or something, then we should address
that risk, but in a way that does not sacrifice presenting the workflow
in a simple way.

-- Steve


Steve Alexander wrote on 07/05/08 12:59:
> >...
> > If the UI guideline says "the first button should not progress the
> > workflow, because it will be focused when the page is loaded", then that
> > guideline represents a logical consequence of a flawed premise.
> >...

There is no such guideline anywhere, as far as I know. Actually I'd go
so far as to say the reverse: a button should *never* be focused when a
page is loaded.

Cheers
- --
Matthew Paul Thomas

On Wed, May 07, 2008 at 12:51:19PM +0100, Julian Edwards wrote:
> > On Tuesday 06 May 2008 19:12:50 Christian Robottom Reis wrote:
>> > > On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>>> > > > This is trivial to fix, although it will look a bit weird having the
>>> > > > buttons and overrides on the rejection page!
>> > > 
>> > > How so?
> > 
> > Accepting and overriding from the rejected items queue is a little
> > counter-intuitive to me.  But if it's useful, then it should go in,
> > it's a one-liner.

There's no other way to undo a mistaken rejection. Asking the uploader
to reupload is very inconvenient compared to just shifting it over to
the right queue.

>>> > > > The current plan is to make a new page where you can select individual
>>> > > > binaries in a build upload, although having read your workflow
>>> > > > description I wonder whether this is convenient or not, and is it
>>> > > > better or worse than cluttering the existing interface with more
>>> > > > checkboxes and buttons.
>> > > 
>> > > Well, IIRC Colin did point out that it's a minority of cases where he
>> > > actually needs to override individual binaries to different values.
> > 
> > He did, and I have a strange feeling that we might all not be talking
> > about the same thing here!  I think UDS would be a better place to
> > talk about it.

Agreed.

Cheers,

-- Colin Watson 

On Wed, May 07, 2008 at 12:51:19PM +0100, Julian Edwards wrote:
> > On Tuesday 06 May 2008 19:12:50 Christian Robottom Reis wrote:
>> > > On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>>>> > > > >   * The default submit button is Reject (as I found out when I pressed
>>>> > > > >     Enter on an input element by mistake instead of space) rather than
>>>> > > > >     Accept. This should be changed.
>>> > > > 
>>> > > > I think we can change the default focus to "accept".  mpt?
>> > > 
>> > > The default focus is the first button to appear in the form, so you'd
>> > > need to change the design there. My original design had a do-nothing
>> > > default for this reason.
> > 
> > IIRC mpt vetoed that design.  But we can set the default focus via JS though, right?

Well! mpt doesn't "veto" designs in general (and I don't like the use of
the term "veto" because it suggests this is some crazy monarchy, which
it isn't!). But he did propose an alternative UI and we agreed to use
it. One of the drawbacks of that UI, however, is this. Everything's a
tradeoff!

I don't think you can change the default focus via JS; at least not
without doing mindgames. It would be neat to be proven wrong, though
non-JS users do exist..

>>>> > > > >   * To compound the above, unlike in the command-line UI, there's no way
>>>> > > > >     to retrieve inadvertently rejected uploads from the REJECTED queue
>>>> > > > >     and choose to accept them instead. I had to resort to 'queue -Q
>>>> > > > >     rejected accept'.
>>> > > > 
>>> > > > This is trivial to fix, although it will look a bit weird having the
>>> > > > buttons and overrides on the rejection page!
>> > > 
>> > > How so?
> > 
> > Accepting and overriding from the rejected items queue is a little
> > counter-intuitive to me.  But if it's useful, then it should go in,
> > it's a one-liner.

By "rejected items queue" you mean the exact same page, except filtering
by rejected status, right?
-- Christian Robottom Reis 
Julian Edwards wrote on 07/05/08 12:51:
> > 
> > On Tuesday 06 May 2008 19:12:50 Christian Robottom Reis wrote:
>> >> 
>> >> On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>>> >>> 
>>>> >>>>   * The default submit button is Reject (as I found out when I
>>>> >>>>     pressed Enter on an input element by mistake instead of space)
>>>> >>>>     rather than Accept. This should be changed.
>>> >>> 
>>> >>> I think we can change the default focus to "accept".  mpt?

I don't have permission to use the queue myself, launchpad.dev doesn't
seem to contain any relevant sampledata, and I don't have any recent
screenshots. If someone can change one of those things, I'll be glad to
help out.

>> >> The default focus is the first button to appear in the form, so you'd
>> >> need to change the design there. My original design had a do-nothing
>> >> default for this reason.
> > 
> > IIRC mpt vetoed that design.  But we can set the default focus via JS
> > though, right?

I don't see how focus has anything to do with this. If the button was
focused, pressing Enter accidentally would have done exactly the same as
pressing Space, so there would have been no problem.

Colin didn't mention focus, he referred to "the default submit button".
In all browsers since Netscape 4, the first button in a form has been
its default button, responding to the Enter key. There might be a way to
use JavaScript to make another button the default, but if you did that
the Enter key would have an opposite effect on browsers with JavaScript
turned off than on those with it turned on, which doesn't seem like a
good idea.

If accepting an item accidentally is similarly bad as rejecting it
accidentally, it might be useful to have a "Do Nothing" button, but to
hide it using style="display: none;". That way it would prevent anything
from happening when you pressed Enter, even with JavaScript turned off,
but it wouldn't clutter the interface.

>>>> >>>>   * To compound the above, unlike in the command-line UI, there's no way
>>>> >>>>     to retrieve inadvertently rejected uploads from the REJECTED queue
>>>> >>>>     and choose to accept them instead. I had to resort to 'queue -Q
>>>> >>>>     rejected accept'.
>>> >>> 
>>> >>> This is trivial to fix, although it will look a bit weird having the
>>> >>> buttons and overrides on the rejection page!
>> >> How so?
> > 
> > Accepting and overriding from the rejected items queue is a little
> > counter-intuitive to me.  But if it's useful, then it should go in,
> > it's a one-liner.
> >...

Possibly the buttons should have labels that are slightly sensitive to
what queue they're appearing in. I'd need to see the interface to
comment further.

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
On Tuesday 13 May 2008 17:09:07 Matthew Paul Thomas wrote:
> > Julian Edwards wrote on 07/05/08 12:51:
>> > >
>> > > On Tuesday 06 May 2008 19:12:50 Christian Robottom Reis wrote:
>>> > >>
>>> > >> On Tue, May 06, 2008 at 10:10:51AM +0100, Julian Edwards wrote:
>>>> > >>>
>>>>> > >>>>   * The default submit button is Reject (as I found out when I
>>>>> > >>>>     pressed Enter on an input element by mistake instead of space)
>>>>> > >>>>     rather than Accept. This should be changed.
>>>> > >>>
>>>> > >>> I think we can change the default focus to "accept".  mpt?
> > 
> > I don't have permission to use the queue myself, launchpad.dev doesn't
> > seem to contain any relevant sampledata, and I don't have any recent
> > screenshots. If someone can change one of those things, I'll be glad to
> > help out.

launchpad.dev has got a bit of sample data that works.

http://launchpad.dev/ubuntu/breezy-autotest/+queue

Log in as foo.bar@canonical.com.  When you accept anything it will oops
because the librarian does not have the required files in it.  You can fake
them by:

make harness
>>> >>> from canonical.archiveuploader.tests import insertFakeChangesFileForAllPackageUploads
>>> >>> insertFakeChangesFileForAllPackageUploads()


>>> > >> The default focus is the first button to appear in the form, so you'd
>>> > >> need to change the design there. My original design had a do-nothing
>>> > >> default for this reason.
>> > >
>> > > IIRC mpt vetoed that design.  But we can set the default focus via JS
>> > > though, right?
> > 
> > I don't see how focus has anything to do with this. If the button was
> > focused, pressing Enter accidentally would have done exactly the same as
> > pressing Space, so there would have been no problem.
> > 
> > Colin didn't mention focus, he referred to "the default submit button".
> > In all browsers since Netscape 4, the first button in a form has been
> > its default button, responding to the Enter key. There might be a way to
> > use JavaScript to make another button the default, but if you did that
> > the Enter key would have an opposite effect on browsers with JavaScript
> > turned off than on those with it turned on, which doesn't seem like a
> > good idea.

Ah I understand now, thanks for explaining.

> > If accepting an item accidentally is similarly bad as rejecting it
> > accidentally, it might be useful to have a "Do Nothing" button, but to
> > hide it using style="display: none;". That way it would prevent anything
> > from happening when you pressed Enter, even with JavaScript turned off,
> > but it wouldn't clutter the interface.

Not a bad idea, at least it sounds better than rejecting things by mistake.

> > Possibly the buttons should have labels that are slightly sensitive to
> > what queue they're appearing in. I'd need to see the interface to
> > comment further.

We're making a change to disable the reject button if viewing the rejected
items list.

Email feedback from Martin Pitt on 2009-08-04

Hello Michael,

Michael Nelson [2009-07-29 18:10 +0200]:
> > But I really want to make sure that I have understood your needs
> > correctly, so I have created:
> > 
> > https://dev.launchpad.net/SoyuzDistroSeriesQueuePage

Nowadays I use the +queue page mainly for the unapproved queue, and
use the web ui exclusively, together with two external scripts which
generate a debdiff between what's in the archive and what's in the
queue, and update the bug status for an accepted -proposed upload. I
added the use case to the wiki.

I don't do regular archive admin any more, and I almost never did it
through the web ui.  Downloading all the source and binary packages is
a huge bandwidth issue, and it's much quicker and convenient to
download it to /tmp on cocoplum and review it there.

You can safely kill the "Bulk-accepting a bunch of debian imports" use
case. We have a script on cocoplum which does that fully automatically
for binary packages, and an established process to process them in
bulk for source packages. Replacing that with a manual process would
be both a waste of work and error prone.

Also, NEW review of Ubuntu packages is hardly a "bulk review" type,
you have to carefully download and inspect each package individually.
Setting the overrides for it is a very small part of the entire
exercise.

Thanks,

Martin

SoyuzDistroSeriesQueuePage/Inputs (last edited 2009-08-04 12:58:57 by michael.nelson)