On Wed, 21 May 2008 03:56:19 +1000 Mark Constable <[EMAIL PROTECTED]> wrote:
[ .. ] > > I've never seen this work successfully. No two users end up running the > > same code. The code can't possibly be as stable after merging in some > > huge branch as it was the day before. > > It can be if the right procedure is followed. The central Git repo > has 3 (or more) "well known" branches; "unstable" where obviously > any initial test patches get merged, "testing" where patches that > survive in unstable for a certain time get moved to, and "master" > (HEAD in svn/cvs speak) is considered "stable". Developers expose > their own patches in unstable, adventurous end users dabble with > the testing branch and most folks would use master, which could > optionally be released as tarballs as well. I really do not think the VCS used has anything to do with QA. [ .. ] > > ALL code has bugs. A release process simply makes it easier to track > > what those bugs are and manage them separately from new features... > > What I've outlined provides exposure to all 3 important levels > of code development, the inital new patches, code that is probably > okay but needs wider testing, and the final cut that could be as > stable as any dedicated tarball release. The real benefits are that > everyone is *easily* in sync with each level without having to > install a new tarball from scratch from a URL that just changed, > ie; the whole process can be more easily scripted and automated. Do you really think you can script an update from VCS on production machines ? An "URL" for a RC or release also mean a list of changes, etc.; this is usually easier to read that the commit logs. > This could happen with any VCS but I suggest Git because it's fast, > makes branching a breeze and everyone with a checkout has the entire > history and can push/pull to anyone else. > > The current method of becoming aware of a new release, find the > unique URL of said release on webpage or mailing-list, C'mon! > manually download source or binaries, perhaps build then install, > reconfigure new installation, test... could be refined. It could, but what exactly do you suggest here? The only model that works that I happen to know is postfix, where on an update the config files are updated automatically with _very_much_care_ WRT PITA. But this has nothing to do with the CVS used, micro-releases, etc. > Also, a continous rolling release allows for micro-updates which can > be a lot safer than any 3, 6 or 12 month release with a lot of > updated code. Safer for whom? This model moves the QA from the "vendor" to the end-user. Have HEAD, -STABLE and -RELEASE branches (or what ever you favorite CVS names them). Freeze -STABLE some time before the planned date for the release; have packagers, early adopters, etc. test -STABLE and betas / release candidates. Tag and release. My 2c, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> [EMAIL PROTECTED], PGP Key ID 057E9F8B493A297B
signature.asc
Description: PGP signature
!DSPAM:1011,48335621150921346719545!
