launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

У пет, 09. 10 2009. у 14:45 +0100, Jonathan Lange пише:
> On Thu, Oct 8, 2009 at 1:10 AM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> > On Wed Oct 07 15:05:08 +0100 2009 Stuart Bishop wrote:
> >> Write a fully scripted install that turns a minimally installed hardy or karmic
> >> box into a Launchpad development environment.
> >
> > How is this different to the rf-setup script? Just that it works from a known
> > state and so is less likely to go wrong?
> >
> >> Developers can download and boot the virtual machine.
> >
> > Of all the free software projects I have ever hacked on this would be the
> > first that had suggested that I use a VM to do it.
> >
> > Not that it is necessarily a terrible idea, but isn't there something that
> > can be done that doesn't require running essentially a whole new machine
> > to hack on Launchpad?
> >
> 
> I agree, we need to aim for not needing a whole new machine, as well
> as aiming for your earlier post of:
>  bzr branch lp:launchpad
>  cd launchpad
>  make run
> 
> However, a simpler way to get a VM might be a good incremental step. Maybe.

I'll explain what we did during our Translations sprint to enable Arne,
Kyle and David to actually get their Launchpad instances running:

 * Prepare a tarball with lp-branches/devel and lp-sourcedeps (~600MB)
 * Get that transferred using USB keys
 * Extract it in ~/launchpad
 * Run rocketfuel-setup and let it run to completion

And that was it.  We first started by doing rocketfuel-setup before
extracting the full tarball and then killing it during rocketfuel-get
setup, but that didn't work out too well.  The above process was quite
straightforward, and we were able to get everyone to 'make run'
Launchpad in about ~2h (along with learning that rocketfuel-setup sets
some stuff up even after rocketfuel-get runs).

A monthly tarball of the above would probably help many a contributor,
since they'd be fetching only the revisions that are missing (i.e. at
worst one month of changes).

The major problem was that we were going to nuke Kyle's postgres DB, but
he said beforehand that he had a backup and that it's fine.  Not sure
what to do with anyone else where's that not an option.

Cheers,
Danilo