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
* 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
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:
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. - <ch...@pobox.com>
Open Source is not an excuse to write fun code
then leave the actual work to others.
According to Chip Salzenberg:
> * 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_.
[**] I'm a Debian developer, so this is good-natured slagging.
You should round that out with 64-bit Sparc.
How many Sparc developers have we got?
On related questions: Could you unpack for me the status of 32-bitness
vs. 64-bitness in the Sparc world? Are all (most of) the chips
64-bit, and for how long? The kernels? The apps?
I'm not sure, one or two, but I don't count as I'm not active atm, I just
>On related questions: Could you unpack for me the status of 32-bitness
>vs. 64-bitness in the Sparc world? Are all (most of) the chips
>64-bit, and for how long? The kernels? The apps?
All of the UltraSparc chips are 64-bit, which makes 64-bit Sparc about a decade
old now, 1995 I think (since early Solaris versions, 2.5 at least).
Virtually all of
Sparc/Solaris is 64-bit nowadays, but there are quite a few hobbyists with
boxes still running out there. Anyway, Solaris supports 32-bit and 64-bit apps.
The kernel is 64-bit. Companies like Oracle are starting to phase out releases
for 32-bit versions of their products. 4 out of the 7 boxes in my office
All of my customers run big monsters (8-16 cpus with 64-128GB RAM) and
as best I can tell Sun is still ruling the RISC/UNIX world even though the
UltraSparc isn't the fastest per CPU. Its a darn fun chip to program for,
However, I think the next big thing is Solaris on Opteron (64-bit) for 2-4
I have told Leo and others that I will provide access to Solaris 10 on
UltraSparc II and III
processors when I get the time to build a zone on one of my boxes. I'll
make a Sun compiler available. I wish we could get tinderbox back up and
I know there is a ton of Linux and OS X out there, but most mission
critical apps are
still running on Solaris, HPUX or AIX in my business, though I am seeing a slow
adoption of Redhat Enterprise Linux.
You are volunteering for running smoke tests regularly ;-) Patches to
PLATFORMS are equally welcome.
We should add linux-x86_64-gcc3.* to the list of primary targets. But we
should make sure that these targets are really tested, at best with an
official tinderbox setup again.
Not many active ones.
> On related questions: Could you unpack for me the status of 32-bitness
> vs. 64-bitness in the Sparc world? Are all (most of) the chips
> 64-bit, and for how long? The kernels? The apps?
The last four generations of SPARCs are 64-bit, and can execute 64-bit
and 32-bit applications concurrently, dependent on the kernel. All the
recent SPARC-based kernels are 64-bit. IIRC, Solaris 10 on SPARC and
x86-64 now use the same code base (unlike the previous 32-bit x86
kernels). Applications are still mixed, and (from my experience),
predominantly 32-bit, unless some specific feature is needed.
While the SPARC's still a viable chip to target, it's probably the
tertiary driver, IMHO. Making sure Parrot works in both 32-bit and
64-bit environments is most important - at a minimum, some LP64 platform
for the monthlies: ILP64 platforms can follow later (quarterlies?).
(After all, there won't be much pure 32-bit left after too long.)
The Solaris environment is probably secondary - Solaris headers, paths,
tools, compilers, etc. - but it doesn't necessarily matter whether it's
SPARC-based or not.
> According to MrJoltCola:
>> At 06:24 PM 4/6/2005, Chip Salzenberg wrote:
>>> * 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:
>> You should round that out with 64-bit Sparc.
> How many Sparc developers have we got?
I generally try to keep an eye on Solaris/SPARC to make sure it doesn't
break, but I'm not guaranteed to have the quick turnaround time you
envision. It'll probably work most months, but perhaps shouldn't be
featured as one of the "target" platforms.
Andy Dougherty doug...@lafayette.edu
> Where did Tinderbox go anyway? I don't mind running a tinderclient at all.
i ran a tinderclient on my ultra 60 for a while before the tinderbox went
away. i think i was the only solaris box out there, and i'd be more than
happy to run it again when and if tinderbox comes back.
Which I still do periodically. I don't know when/why Sparc ever fell out of
the mix. This was the reference platform for the byteordering patches.
>We should add linux-x86_64-gcc3.* to the list of primary targets. But we
>should make sure that these targets are really tested, at best with an
>official tinderbox setup again.
Where did Tinderbox go anyway? I don't mind running a tinderclient at all.
I can tell you now Sparc / GCC is broken for most due to our broken Configure.
Our config pulls out the params that were used to build Perl with, and this
because most Sparc folks are running a pre-built Perl and GCC binary that
on a distributor's system. So for example, even though the system will have
Perl and GCC, Perl's config will say it was built with Sun's CC compiler.
fails and has to be hand hacked to work, or you have to build your own Perl
the config before you build Parrot (not too tough, but should not be required).
Not specifically about SPARC: Is there already a configuration
roadmap, something for me to start with as I look to What Should Be?
I understand that tinderbox is an automated system for test builds
with result collation. Is there any need for a tinderbox central
point being "official" (e.g. perl.org machine), or will a random
server (no offense Peter :-)) do just as well? No security
I set up a tinder server a couple of weeks ago.
Not sure if anyone else looks at it.
The url is
The email address to submit build reports is (I think)
tind...@unlinked.vm.bytemark.co.uk. If thats not working
the email address is in the mailing list archives.
We exist to collaboratively utilize scalable deliverables and competently
engineer cutting edge leadership skills because that is what the customer
It was on parrotcode or dev.perl.org at some point.
Maybe that can be reused?
> Is there already a configuration roadmap, something for me to start with
> as I look to What Should Be?
I'm not aware of one. There's been lots of discussion over the years both
on the perl6-internals list and on the now-defunct perl6-build list, but
but I don't have much useful saved in my back files.
A fair amount of useful stuff is probably in the 2001 perl6-build archives
and probably the perl6-internals archives around the same time.
Andy Dougherty doug...@lafayette.edu
From what I recall, we're planning a bootstrapping system. The
configuration/build system will be written in a Parrot language
(possibly, but not necessarily, Perl 6), with PBC files included in
the distribution. To bootstrap, we'll have platform-specific shell
scripts or batch files sufficient to build Miniparrot, a
stripped-down, no-configuration, ANSI C-only version of Parrot. So
the steps will be something like:
$ CC=gcc makemini/generic-unix.sh # Skip if you have an old Parrot
$ (mini)parrot configure.pbc
$ (mini)parrot build.pbc
$ ./parrot test.pbc
# ./parrot install.pbc
This implies that we won't require a 'make' (and won't have to attempt
to make different 'make's work); all you'll need is a compiler,
linker, and C library. This also implies that configure.pbc and
build.pbc will probably have to be carefully written to work with the
limited process-manipulation abilities of an ANSI-constrained
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
Chip> * On the third to last day of the month, someone (me, by
Chip> default) will create a release document...
Chip> * Starting on the first of the month, there will be a code
Is it on?
Chip> No changes should be committed during the slush except for...
Any value to just starting an svn branch for each release, stabilizing
that, then tagging upon release? Freezing the trunk can slow momentum
a bit, though of course merging is extra work, and fewer people will
test the pre-release branch than the trunk.
Chip> darwin linux-x86-gcc3.* win32-ms-cl
Others> [x86_64, sparc]
What's the official decision, Fearless Leader?
War is God's way of teaching Americans geography. -Ambrose Bierce