[IPython-dev] Experience with launchpad

[Fernando Perez]

Hi Holger,

[ I'm replying to your request with a CC to the ipython dev list, in
case others want to provide their take on the matter.  Please note
that you can only post to the list if you are subscribed, we get too
much spam otherwise. ]

On Sat, Oct 4, 2008 at 3:26 PM, Holger Rapp <HolgerRapp at gmx.net> wrote:
> Hi Fernando,
>
> I am writing as the head developer of the widelands open source game
> (www.widelands.org). We are finally fed up with sourceforge and are making
> up our minds to move to another hoster. One of the top candidates in my list
> is launchpad (besides berlios and savannah). I realized that ipython made
> that switch earlier this year. And since i am a very happy user of ipython
> and am very convinced by it, I am very much interested in your experience so
> far.
>
> It would be great if you could give me a short summary of your experience
> with launchpad, especially two questions are important to me:
>
> 1) Speed
> launchpad seems slow to me. Is it in real life use?

It can be, yes.  So far this hasn't been a show stopper, but just
yesterday I was making a clean branch of the ipython trunk for some
tests, and

bzr branch lp:ipython

failed to complete twice.  I had to kill it and restart twice, because
it was just hanging.

I should add though that this is the worst I've seen, it's typically
not this bad.  In general I find it sluggish enough to annoy me but
not to drive me crazy.  I just put up with it.

I have no idea how things would fare with a much larger project, but
you could easily test things yourself: find a large project, branch
it, make some changes locally and start pushing the branch to your
+junk workspace.  Or even better, do the test with a toy copy of your
widelands tree, to see how it feels for a while.

> 2) Lower developer entry bar
> Have you had the feeling that more developers start hacking for ipython?

I don't think we've picked up anyone completely new since we moved
over, but we most certainly have a much better flow.  Developers who
aren't core members have made branches we can review until they are
ready for inclusion, for example (Vivian de Smedt made one such
contribution this year).  We also have been making heavy use of the
ability to keep individual branches alive while we review them for
merging, and the actual painless merge capabilities of bzr are
definitely a great improvement over svn.

> but also what about service, which features are the killer-features for you,
> are you happy with the performance of bzr, what did you're team say to the
> move, can you recommend it also for non python projects, and why didn't you
> chose other hostings?

For me the killer features are:

- lower barrier of entry to new contributions.

- reasonably easy  workflow for code review (though I hope their
review tool matures and improves, as right now it's very primitive).
This aspect can really use some improvements, but even in its basic
form we've found it to be very useful, so I'm not complaining.

Minuses:
- speed (see above)
- The web interface is a bit clumsy to use at times, though the update
of a few months ago did improve things quite a bit.  It's still a bit
confusing to navigate though.

Language: I don't think the language of your project makes any
difference.  Bzr is just a source control system that happens to be
written in python, and launchpad is just a website.

We had our own mailing list infrastructure already so I can't comment
on that part, we're only using it for code hosting and bug tracking,
but for those it works very well.

Other hostings?  Our criteria for selection were roughly:

- a distributed VCS with decent Windows support (we have developers on
win32).  This pretty much ruled out git at the time (March 2008,
things may have changed).

- Easy hosting of branches.  Once you move to a DVCS, all of a sudden
having an *easy* way for anyone to host their branches so you can
really share becomes very important.  It's not realistic to ask
everyone to set up their own server just so we can pull from their
branches.

I'd also add (though I don't think this was quite so clear in March,
at least to me):

- Free hosting with equal rights for non-members of the core team.
It's really important that *anyone* with a launchpad account can
branch and host any project.  This makes the system very democratic,
encourages contributions, and frees the core team of a project from
having to worry too much about who to give 'commit rights' to (team
membership in Launchpadese).  The ipython-dev team members really just
happen to be the people who can deal with the merging at the end of
the review process, but to a large extent who's in there is
irrelevant.  Anyone who can open a launchpad account can contribute a
branch that can be reviewed on an equal footing to that of a team
member.  For example, these two branches are for all intents and
purposes on an equal level:

https://code.launchpad.net/~fdo.perez/ipython/trunk-dev
https://code.launchpad.net/~unpingco/ipython/trunk-dev

One is my copy of trunk, the other is from a developer who is not a
member of the ~ipython-dev team.  Both can be identically reviewed and
merged into the project, both are committed to only by their owner.

Given these criteria, in March 2008, it was basically down to hg or
bzr.  But there was no equivalent to launchpad for hg at the time
(there may be now, I don't know).  hg seemed a bit nicer (faster) than
bzr, but honestly launchpad was what drove our decision.

> I'm sorry to bother you about this, I hope you're reply give me some insight
> and makes it easier to make a decision pro or contra launchpad. I read the
> mailinglist archive of the launchpad thread and it reads similar to the one
> we currently have on the widelands mailinglist.

No problem, I hope this is useful.  Feel free to ask if you have
further questions.

> Greetings and thanks for ipython ;)

Glad you find it useful!

Cheers,

f