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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
