launchpad-dev team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

On 2010-04-20 18:05, Jonathan Lange wrote:

Jono, thanks for showing us more of the breadth of this problem beyond 
my own very limited research.


> > People not familiar with distributed version control fail to
> > figure out how to start a branch.  Project owners set up translations
> > exports to nonexistent branches.
>
> I am familiar with DVCS and I think I'd be tripped up by this one. Why
> doesn't the translations exporter create a new branch?

Because there are choices to be made that we probably don't fully 
understand ourselves.  Does the user have the right branch sitting 
around somewhere that we don't know about?  What if they push it just as 
we try to create it?  What if they want to use the branch for merging 
with their development branch?  What if that's not the one selected in 
Launchpad for whatever reason (e.g. because that's a mirror of a bzr 
branch hosted elsewhere)?  Do they have any restrictions on versions and 
formats, e.g. because they are running stable OSs for a long time?

We did ask the bzr folks and were assured that creating an empty branch 
would not be the right thing to do.  The suggestion was not to offer 
unpushed branches for selection, but on reflection I think that would 
just be moving the hamster around under the carpet.  Why your branch 
doesn't show up in the selector would be highly nonobvious.

I now see this also came up in the discussion for bug 368312, which you 
pointed to.


> >   "Configure a series branch" on a product
> > series can appear to do nothing, with no next steps becoming obvious (bug
> > 567065).
>
> Looking at the bug, I think that's a different problem too.

Definitely.  See the "without absolving" clause.  The point is that it 
is related, and a fix for 567065 would benefit further from the other 
changes.


> > 1. For branches that have had no changes scanned yet, lots of places that
> > link to them could benefit from a standardized warning icon and tooltip, or
> > even a full paragraph.  Maybe even all places.
>
> Not quite what you describe, but see:
>   https://bugs.edge.launchpad.net/launchpad-code/+bug/368312
>   https://bugs.edge.launchpad.net/launchpad-code/+bug/320065

The latter is very close, though I think it would be unwise to show any 
further detail in the link.  For one, it's probably costly to look up 
the actual state of the codehosting server (and both error-prone and 
slow to cache it in the db).  For another, it can be hard to maintain 
brief and verbose descriptions of roughly the same set of states in 
parallel.  The two start conspiring against you when the set of 
conditions you're willing to check while rendering the bug page diverges 
from the ones you're willing to check for each branch link in, say, a 
listing of 300.

On the other hand, if you can just draw attention to the problem, the 
link to diagnostic details is right there.

Marking links to broken branches may look ugly at first, but many people 
will catch on to the fact that they can make the icons go away, and 
we'll all be happier for it.  It may even get us some user feedback 
about problems we didn't know existed.


> The branch page should definitely be better in this regard. The code
> team are working this week to reduce a significant part of the latency
> between pushing and appearing in the web ui.

I wasn't aware that was a problem, except in one specific case we happen 
to care a lot about.  But the faster this happens I guess, the less 
confusion a few warning icons will cause.


> Before a link to help will help, Launchpad needs to be more honest
> about the state of the branch. See

That's a wording issue, but one we'd do well to figure out before 
sprinkling the wording all over the UI.

How about this?  "Launchpad has not processed any revisions for this 
branch yet.  Processing may take a few minutes after the branch has been 
pushed."


> https://bugs.edge.launchpad.net/launchpad-code/+bug/445424. We should
> also have an ajax widget that updates when the branch is ready, rather
> than the embarrassing "please refresh" thing we have now (same goes
> for MP diffs).

Sidenote: polling by the client is a known performance risk with Ajax.

On the other hand the need may be less pressing when users can see the 
link change its appearance in the course of normal Launchpad usage.


Jeroen