Re: [Launchpad-users] Your top three wishes for Launchpad? (4.0 planning)

[Jamu Kakar <jkakar@xxxxxxxx>]

Hi Karl,

On Thu, Aug 20, 2009 at 8:45 AM, Karl Fogel<karl.fogel@xxxxxxxxxxxxx> wrote:
> With the 3.0 release coming up soon, we're beginning the 4.0 planning
> process.  To help with prioritization, we'd like to know your top 3
> wishes for Launchpad 4.0.  Please follow up in this thread, and...

Thanks for asking!  Here's my wishlist:

1. Project wiki and static hosting

   For pretty much every project I have on Launchpad, I'd like to be
   able to (1) manage project documents using a wiki and (2) provide
   static generated content such as API documentation.  I'd like to
   be able to use the wiki format in places like the product
   description and summary, so that I can link into my content from
   standard Launchpad pages.

2. Batch operations in the Launchpad API

   I enjoy using the API, it's very simple and straight-forward, and
   I've been able to automate a number of boring processes with it.
   For things I do infrequently the cost of making an HTTP request
   for each object I want to work with isn't a big deal: I can start
   my scripts and let them run for as long as necessary.  But, there
   are things I'd like to do frequently that are currently too slow.
   For example, getting a list of bugs in project X with tag
   'review' and printing them in my terminal.  A quick test here
   shows that it takes 12-15s to get bug and bug task objects for 4
   bugs and display them.  I want to do this operation 20 times a
   day and for that it needs to be faster, at least as fast as
   loading the same view in my web browser.  Making it possible to
   retrieve many objects at once would help.

3. Unify bug/code review user experience

   On pretty much all the projects I work on the bug tracker is the
   place where we keep track of things that need to be done to make
   the code or the project better.  Every code-related task starts
   by finding or filing a bug, assigning it to oneself and marking
   it as 'In Progress'.  From there, a branch is created, eventually
   going through a review process before being merged.  At that
   point the bug is closed.  The current separation of merge
   proposals and code reviews from bug reports makes it awkward to
   follow the details of a problem from the initial report,
   discussions about the issue and potential solutions, (typically
   one) proposed branches and associated reviews, to the final
   changes landing.  I would like to be able to look at a bug in my
   web browser and be able to see the whole set of interactions that
   happened around it, without needing to jump around from the bug
   to individual merge proposals.

Thanks,
J.