← Back to team overview

launchpad-dev team mailing list archive

Re: UI RFD: branches that haven't been pushed to


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

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:

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.


Follow ups