launchpad-dev team mailing list archive

[Tim Penhey <tim@xxxxxxxxxx>]

On Sat, 15 Aug 2009 09:43:31 Martin Albisetti wrote:
> Hi,
>
> I've been working on a mockup for the branch index page for 3.0.
>
> The mockup is here: http://people.canonical.com/~beuno/branch-index.png
>
> I had a few things in mind when I did this:
>
> - Deleting a branch was... weird. Elliot Murphy has a long-standing
> bug about this
> - Proposing for merge is the main action for that page, and the
> current display is very noisy
> - Portlets where too busy as well
> - Needed 3.0ization
>
> There's a few things missing here:
> - How to get to the "source code" (loggerhead)
> - Where to display the technical babel (branch/repository formats,
> stacked on). This needs to be moved out of the way, as the current
> information is not human-understandable, and is rarely something users
> are interested in
> - Bugs and blueprint linking
> - Displaying the recent revisions
>
>
> Comments are welcome, expected and needed  :)

Warning!  This gets long, and rambles a bit.

Here are some other things that are missing too :-)

The description of the branch.  This was recently added back in.  It does use 
the icky (IMO) field set border around the description.  I really don't like 
that.  Bugs don't use this for their description, and I'd really not like to 
see it on the main code-review page when we add a description to that instead 
of the first comment.

Import branches have an area where we list the source of the import branch, 
and a list of the most recent attempts.  Other import branch only links or 
buttons are there too.  For import branches, this is pretty important 
information.

Mirrored branches have additional meta-data about when they were last 
mirrored, and when they'll next be mirrored.  This could perhaps go down in 
the metadata area that also contains the branch format information.  
Personally I think that the metadata isn't that interesting most of the time, 
so it wouldn't bother me at all to have this further down the page so you'd 
have to scroll to see it most of the time.

I think the commands for updating the branch and getting the branch are also 
not that interesting most of the time.  It is useful when you don't know 
anything about launchpad, but once you do it is just noise.

Before I get into my next rant, let me tell you what I do like:
 * I like that you have broken out the branch name, and use it in the 
breadcrumbs.  Does it bother you that there may be two different branches that 
have the same breadcrumbs?
 * I like the "Delete this branch" link on the RHS
 * I like the clean new look at the top of the page
 
Part of the problem about designing a one page fits all type branch page is 
that there are currently three different types of branches with two more 
potential types of branches in the wings.  Each of these different types of 
branches has different information that is interesting.  

Perhaps... perhaps we have different layouts based on the different types of 
branches.

Firstly we have trunk branches, or focuses of development.  Most projects use 
branches that are linked to series for this.  Launchpad links the branches to 
special series called "edge", "staging", "devel".  Part of this is to get 
handy "short-hand" branch identities, and despite our "db_devel" branch being 
"trunk", most branches actually target the lp:launchpad/devel branch, as that 
is what ends up on edge.  There are other projects have have several unrelated 
branches, each of which can be targetted for development, but for whatever 
reasons the project owner wants to keep them together in the one project.  
Right now, linking these branches to ProductSeries is the only way to mark 
them as "special".

Trunk branches are interesting because these branches are the ones that users 
often want to "get", and "see the source" of.  These are the branches that we 
may want to render the README file nicely on the page, and to be have links to 
set the "Review team" for.  These branches will most likely have many 
subscribers, and will be the target for many merge proposals.

Feature branches are quite different.  As Barry and Martin have mentioned, it 
is very desirable to see what changes the branch has introduced as soon as 
possible when going to the branch page.  Also the most important things for 
features branches are the bugs being fixed, blueprints being implemented, and 
the status of the code review.  I have been thinking that perhaps we'd even 
want to show the review status table on the branch page itself (the pending 
and completed reviews) when the branch is in review state.  The only reason 
right now that I don't suggest moving all of the code review content on to the 
branch page itself is that we allow the same branch to be proposed to multiple 
targets at one time.  Perhaps this flexibility is actually hurting us more than 
it is helping, and by constraining a branch to only having one review, we gain 
the ability to make the branch page more useful for the reviews. (This is 
getting quite radical in its shift from the current implementation).

Next we have package branches.  Some of the package branches are the official 
package branches that have been used to build the official packages.  Others 
will be users package branches used to build packages in PPAs.  I can foresee 
that we'll want to show some form of build history on branches that have been 
build.

The other two types of branches are wikis and documentation, too far out in 
the implementation plan to worry about here.  We have enough to worry about.

I guess the first question we need to ask ourselves is:
  "Are we designing a single branch page that nicely shows all possible 
branches?"

If we are, this gets harder.  Hard but not impossible.  There are certainly 
sections of the page that will make sense in one part, but not in another.
The review team (I removed the "default" some commits ago - not on edge yet 
though) is almost certainly only different to the owner on "special" branches 
that are linked to a series.  Why show this option to users on a feature 
branch when they are almost certainly never going to click on it, nor do they 
care.  The default reviewer that is shown on the mock up confused me.  Who is 
it the default reviewer for?

Diffs... diffs are interesting.

Merge proposals have a status called "Work in progress".  This was a hang over 
from the old workflow that the launchpad developers used.  The intention was 
always to have diffs generated somehow for these.  I think we could work out 
some way to have a work-in-progress proposal created with the branch (not 
sending out any email notifications), and allow the user to change the target 
without penalty.  Perhaps we could try something smart in the scanner to look 
at the active series linked to branches and choose the closest target (magic 
is good when it works).  Anyway... one plan we have right now is to update the 
diffs when the user updates the source branch (updates on target pushes 
wouldn't be done by Launchpad - but could be updated by a user with a lp:mad 
like script) - and if we had the one proposal constraint, we could make this 
diff available on the branch pages itself.

Anyway, I'm pretty much done now.

Comments?

Tim