Code 4.0 stakeholder priorities
OEM Services
Contact: Steve Magoun / Cody Somerville
- 1 Branches take an exceedingly long time to mirror (LP: #428032) (Is this fixed already? Branch scanning seems to be pretty quick in LP 3.0)
- 2 Performance - codebrowse can be slow to respond. For example, browsing files in a revision or revisions in a branch can be slow or timeout altogether
- 3 LP admin required to enable private branches on a project (is this really a registry issue?)
Ubuntu Foundations
Contact: Colin Watson / Robbie Williamson
- 1
- 2
- 3
(some projects that use code a lot)
Bazaar Project
Contact: Martin Pool
- 1 Better code reviews: keep developing workflow, integrate more with the branch and bug page, more direct commenting on diffs; accurate diffs always available; landing support
- 2 View of branch contents (like loggerhead) more clear, reliable, and integrated with the rest of the site; making interesting diffs always available before creating a merge proposal
- 3 Simple page hosting from bzr branches: check it out and show it within launchpad; (a start towards wiki-type functionality)
Honorable mention/things I'm still thinking about:
- Branch naming: getting rid of junk, changing access without changing names, graduating from a personal experiment to being a project
- Make it easier to host small numbers of private branches to experiment
- General quality things: better server-side logging, edge codehost for testing,
- Larger stories across bzr and lp: bzr lp-login, lp: resolution, manipulating branches and mps from the bzr client
Ubuntu One
Contact: Elliot Murphy
- 1 Bulk editing of bugs. Sorting on the fly clicking in the column names. Let me select visible columns. Add date to sort and filters
- 2
- 3
Canonical IS
Contact: James Troup
- 1 Scaling: memory usage of smart server
- 2 Scaling: multiple front ends for code, single FS back end
- 3 Codebrowse instability
Drizzle
Contact: Monty Taylor
- 1 Better "review, make changes, re-review" workflow. Thanks for adding the resubmit proposal link.. but something which doesn't require the full resubmit and makes the ongoing conversation about the changes something that can be followed, and potentially something that can annotate code and then be updated as the code is updated. (Reviewboard has some nice bits in this area). You know, so that the system understands that I've reviewed code and that someone has pushed code to that same tree... that perhaps that code is code that addresses my concerns.
- 2 More bzr client integration. The more I can do via bzr command line the better. Often I'm hacking branches on remote machines over ssh and email-based commands are just not possible. It would be great if I could "submit for merge", "resubmit"
- 3 The ability to upgrade a bzr branch format through the website. Bonus points for: ability to upgrade all branches for a project, which for branches not-writable by the requester could send a message to the owner requesting permission for launchpad to upgrade all of their "foo" branches to format "bar".
Honorable mention/things I'm still thinking about:
- Virtual branches for merge requests. As in: I request lp:~mordred/drizzle/mychanges to be merged. This generates something like lp:~mordred/drizzle/mychanges-2009092501 that gets added to the merge request, which is the equiv of lp:drizzle/mordred -rrevid:blah. Merge request resubmission creates a new one of these. Essentially so that a request to merge is associated with the state of a tree. (Right now we do this process by hand for our merge captain branches.)
- Bulk editing of branch status (or something) I have 118 "active" branches for drizzle right now... most of them are old, merged or abandoned - but honestly the thought of stepping through all 118 of them to set their status, especially since that takes 2 full page loads and a form submit per branch, is just a bit daunting.