On Mon, Aug 17, 2009 at 7:24 AM, Tim Penhey<[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
