Opened 16 years ago

Closed 16 years ago

#48 closed defect (fixed)

Make a sane development workflow

Reported by: price Owned by: broder
Priority: minor Milestone:
Component: other Version:
Keywords: Cc:

Description

Running at Packaging Capability Level AAA --- i.e., putting every change we make into a Debian package --- turns out to mean more overhead work than we're collectively willing to do, so that many things actually wind up in random SVN checkouts in people's home directories. We should find a lower-overhead way of working while in development, one that keeps things sanely source-controlled and reproducible and that we're actually willing to keep to. When the service is mature, like scripts.mit.edu as of 2006 rather than as of 2004, then we might move back to a higher-development-overhead, super-packaged style of operation.

Probably this means having canonical checkouts in places like /srv of purpose-made directories in SVN, so that fully integrating a change means a commit, a svn update in the canonical checkout, and perhaps a launch from there.

Change History (4)

comment:1 Changed 16 years ago by broder

  • Status changed from new to assigned

So...instead of trying to put everything into Debian packages, do people have any objections to having a code checkout in /srv and a couple of files in the init.d directory in svn as well so that things actually come up properly on boot? While it is possible that we'll want to go back to using Debian packages when we're closer to an actual release, this will at least allow us to keep everything actually in version control.

I would be trying to design this so that it is intentionally difficult to checkin files in /etc that aren't in init.d, just to avoid the craziness that scripts has to deal with.

If people don't have objections to this, I'll probably start implementing within the next couple of days.

comment:2 Changed 16 years ago by price

  • Resolution set to fixed
  • Status changed from accepted to closed

Ultimately Evan implemented a hybrid solution, where directories like /var/www/sipb-xen-www (in which the web interface lives) are SVN checkouts. So in those directories, you make the change once, live, then check it in, and the next build of the package reflects the change.

comment:3 Changed 16 years ago by broder

  • Priority changed from major to minor
  • Resolution fixed deleted
  • Status changed from closed to reopened

I actually specifically didn't package sipb-xen-www, since it was most likely to be in a state of high flux. However, sipb-xen-dns on sipb-xen-dev and sipb-xen-dhcp on black-mesa do work this way.

I'm not actually done yet - I still need to deal with the VNC proxy, the iptables rules, and possibly a few other things.

comment:4 Changed 16 years ago by anonymous

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.