Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.sdsmt.edu!news.mid.net!news.dra.com!netaxs.com!hunter.premier.net!netnews.worldnet.att.net!arclight.uoregon.edu!dispatch.news.demon.net!demon!awfulhak.demon.co.uk!awfulhak.demon.co.uk!awfulhak.demon.co.uk!not-for-mail
From: brian@awfulhak.demon.co.uk (Brian Somers)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: FreeBSD release procedures
Date: 24 Jul 1996 17:37:26 +0100
Organization: Coverform Ltd.
Lines: 46
Message-ID: <4t5jg6$e6@anorak.coverform.lan>
NNTP-Posting-Host: localhost.coverform.lan
X-NNTP-Posting-Host: awfulhak.demon.co.uk
X-Newsreader: TIN [version 1.2 PL2]
As J"org has suggested that releasing FreeBSD is a nightmare from
a developers point of view, I thought it may be of interrest to
tell people how releasing should work IMO. I've spent a *lot*
of time thinking about this, and had most of it implemented in
the last place I worked.
It's based on a program called mk. It's not on the 'net 'cos I
believe there's already a program out there called mk. This program
is a "make" replacement that fixes everything in "make" that's broken
by design, but imposes some restrictions. The advantages far outweigh
the restrictions as (IMO) most of these restrictions are things that "you
shouldn't really do". I won't go into the specifics of mk, but it does
two things of interrest:
1. You can list the component source code for a target. A target
can be the entire system.
2. You can build a local version of a target that includes only
a specific set of modifications.
I have also written a release mechanism (one that includes the sources
of mk, but is not free as I was being paid by someone at the time). This
release mechanism is trivial given the functionality of the mk program.
It allows the developer to "couple" source file changes, associating a
modification number with all of the bookout/updates. When booking out
of sccs or rcs or whatever, a front end program records the source file
associations. Another front end updates all source for a given modification
number. Your "live" source tree is something that should always compile
as you can rebuild the system locally (with just your mods) without effecting
the live source code.
When this is in place, you can then build new releases by writing a small
front-end program that gives you a selection of the modification numbers
that have been updated. This program simply gets the relevent source
revisions and writes them into the new source tree. You can even make
this program allow multiple source tree levels - ie. RELEASE-2.1.5,
RELEASE-2.2.0, RELEASE-2.2.1, Test, Development.
I cannot see any flaws (except that I didn't explain in great detail) with
my ideas except that it doesn't support branching in any shape or form.
I never liked branching 'cos it's a pig to track and integrate.
Any suggestions ? Is it worth me writing this article in more detail ?
--
Brian <brian@awfulhak.demon.co.uk>
Don't _EVER_ lose your sense of humour....