launchpad-dev team mailing list archive

[Martin Albisetti <argentina@xxxxxxxxx>]

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

Added.


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

Needs a separate mockup.


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


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

I think it's just variations on the same template, we just need to
figure it out on a case-by-case basis.


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

Agreed. I'd like the current mockup to be about a non-trunk branch,
and we can branch off to different use cases from there.


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

Good. Another use case.


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

Yes, but we need to tackle one case at a time.

Uploaded new version to: http://people.canonical.com/~beuno/branch-index2.png
(that's all I could get done today)


-- 
Martin