I've recently had it suggested that Parrot use a regular release
schedule, which tends to maintain momentum and provide many happy
opportunities for spreading propaganda^Wnews of our progress.
So, wearing my Fearless Leader hat, I announce that from now on we'll
be releasing on a regular schedule. I'd like to think that enough is
getting done to have a monthly release, which would look like this:
* On the third to last day of the month, someone (me, by default)
will create a release document describing the new goodies since
the last release. (If something neat comes in at the last minute
after the doc is drafted, no biggie, we'll just add it.) I'll
decide on the version number and the mascot -- but I'll take
nominations. :-)
* Starting on the first of the month, there will be a code freeze,
or really more of a slush. No changes should be committed during
the slush except for (1) things that can't possibly break the
build (e.g. documentation spelling changes), and (2) fixes for
bugs that are preventing release.
* Test builds will be made on all of our required platforms[*];
absolutely minimal changes will be made in order to fix those
builds that are not 'good enough'.
* When the builds are 'good enough' or I've decided that making
them good enough would take too long: Leo or I will tag CVS, make
a tarball, upload the source to the Appropriate Place, and plaster
the release announcement on every virtual wall and lamp post.
* Then the code slush will be lifted and we'll be off to the races
again.
The primary missing item in this new scheme, AFAICT, is:
* What platforms are required for release? I'd guess that we'd get
almost of all of our developers (and users, for that matter) with:
darwin
linux-x86-gcc3.*
win32-ms-cl
So that'd be my list. (Note that it's not that I don't care about
the other platforms, I just don't want to warp the release cycle if
less-used platforms are not working at the end of a given month.)
* What should the standard be for "good enough" in the build? Quite
a few tests will be expected to fail on all platforms. We don't
want a standard that's so rigid it would be at home in the Debian
project[**], but it would be nice to have _something_.
Oh, and for this cycle: Three weeks and counting. :-)
[*] In this stage of the project, "required" should probably be read
as "highly desired"; some platforms could be Just Not Ready at
the end of the month, and if so, the worst they should suffer is
waiting one more month. (Or using CVS.)
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
Open Source is not an excuse to write fun code
then leave the actual work to others.
