launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01257
Re: Call for Suggestions: Making it easier to start hacking on Launchpad
On Thu, Oct 8, 2009 at 7: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?
jml asked for ideas, so I put one out there to kick start things :-) The advantages of a VM:
- The environment is consistent between development setups, staging and production systems. We get pretty close as it is, but this approach gets closer.
- We get a work around for the well known ports issue. PostgreSQL on port 5432, Apache on port 80 and 443, Librarian, mock services, soon memcached and rabbitmq - all are fundamentally the same problem and we need to solve them all if we ever want to run multiple instances of the test suite or parallelize it on the same box.
I'll leave the disadvantages up to people who have actually tried something like this and know what they are talking about ;)
The advantage of a scripted installation is we can run automated tests to ensure the process actually works. In the past, the setup process was always a major pain because it was used so infrequently. You would go through the process ironing out all the problems and leaping all the hurdles and spend a day or three doing it. If you were a good developer, you would then update the documentation. However, that documentation was again out of date when someone next tried to follow it. Its gotten better as the team has grown simply because the process is being followed more regularly.
Our process should include a restartable mechanism for getting the Launchpad tree or priming your repository. For most of the world without high bandwidth to London, you really have to pull it down in small batches of revisions or using rsync as a simple 'bzr branch lp:launchpad' is unlikely to actually ever complete.
We should be able to stop blowing away your existing PostgreSQL installation with PostgreSQL 8.4 btw. \o/
--
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups
References