launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Aug 17, 2009 at 8:24 PM, Tim Penhey<tim@xxxxxxxxxx> wrote:
> 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.
>

Acknowledged.

> Here are some other things that are missing too :-)
>
...
> 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.
>

Yes.

> 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.
>

For mirrored branches, the 'last mirrored' time is fairly closely tied
to the usefulness of the revision log (and diff, if it exists). It
would be a pity if they were separated too far.

These two together make me think of the other 'big' operations that
Launchpad can do to a branch:
  * Mirror now
  * Completely remirror
  * Upgrade
  * Abort import
  * Import now
  * Fork this branch

Granted not all of these are implemented, but they are of a kind, and
should be displayed similarly.

> 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.
>

It's good for copy/pasting.

> 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.
>

I think that for these branches, if not for all branches, we should
inline a file browser for the branch tip.

> 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).
>

I agree that diff is the most important thing in feature branches.

I think we should strongly consider optimizing for one merge proposal
per branch in our UI, and make room for adapting for the less common
case of multiple MPs.

> 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.

This feature is just a little futuristic, so I don't want to spend too
much time designing for it, but...

I don't think that showing the build history on branches should be a
thing tied to the kind of branch. It's an unnecessary special case. I
think that it would be more useful to think of showing a history of
'interesting things done with this branch', and making it possible to
filter & search that history.

> 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?"
>

I don't think this is the first question, although it is an interesting one.

In general, analyzing by type is a good start but makes for messy
ends. It's much better to think about the properties of each of these
types and design for them.

e.g.  On feature branches we want to show the diff, on trunk branches
we want to show the file browser (or README or whatever). We could
include both elements on the page as collapsables, and show "diff and
not file browse" by default for branches proposed for merging and
"file browse and not diff" for other 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?
>

We already have a heuristic that we use to guess target branches for a
project. We could probably use that for default reviewer.

The difficulty here is that there's a potential bootstrap problem: you
want to set the default review team before anyone has submitted a
review and maybe even before the branch becomes the dev focus.

> 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.
>

We talked a bit about this on the phone yesterday. This sounds very
exciting to me -- I'd like to see it written down with bugs filed.

> Anyway, I'm pretty much done now.
>

Thanks for the very interesting thoughts!

jml