Monthly Release Schedule

4 views
Skip to first unread message

Chip Salzenberg

unread,
Apr 6, 2005, 6:24:49 PM4/6/05
to Perl 6 Internals
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. - <ch...@pobox.com>
Open Source is not an excuse to write fun code
then leave the actual work to others.

Chip Salzenberg

unread,
Apr 6, 2005, 8:48:57 PM4/6/05
to Perl 6 Internals
Nick Clark brings to my attention that I'm missing a footnote:

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.

MrJoltCola

unread,
Apr 6, 2005, 10:18:01 PM4/6/05
to Chip Salzenberg, Perl 6 Internals
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:
>
> darwin
> linux-x86-gcc3.*
> win32-ms-cl

You should round that out with 64-bit Sparc.

-Melvin


Chip Salzenberg

unread,
Apr 6, 2005, 10:28:03 PM4/6/05
to MrJoltCola, Perl 6 Internals
According to MrJoltCola:

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?

Jay Scherrer

unread,
Apr 6, 2005, 10:31:18 PM4/6/05
to Chip Salzenberg, MrJoltCola, Perl 6 Internals
T least one FC3 x86_64
Jay Scherrer

MrJoltCola

unread,
Apr 7, 2005, 12:10:50 AM4/7/05
to Chip Salzenberg, Perl 6 Internals
At 10:28 PM 4/6/2005, Chip Salzenberg wrote:
>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:
> > >
> > > darwin
> > > linux-x86-gcc3.*
> > > win32-ms-cl
> >
> > You should round that out with 64-bit Sparc.
>
>How many Sparc developers have we got?

I'm not sure, one or two, but I don't count as I'm not active atm, I just
commentate. :)

>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
pre-Ultra
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
are 64-bit.

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,
though.
However, I think the next big thing is Solaris on Opteron (64-bit) for 2-4
CPU midrange.

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
also probably
make a Sun compiler available. I wish we could get tinderbox back up and
running.

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.

-Melvin


Leopold Toetsch

unread,
Apr 7, 2005, 3:21:22 AM4/7/05
to MrJoltCola, perl6-i...@perl.org

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.

> -Melvin

leo

Bryan C. Warnock

unread,
Apr 6, 2005, 11:17:26 PM4/6/05
to Chip Salzenberg, Perl 6 Internals
On Wed, 2005-04-06 at 22:28 -0400, Chip Salzenberg wrote:
> 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:
> > >
> > > darwin
> > > linux-x86-gcc3.*
> > > win32-ms-cl
> >
> > You should round that out with 64-bit Sparc.
>
> How many Sparc developers have we got?

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.


--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)

Andy Dougherty

unread,
Apr 7, 2005, 8:15:41 AM4/7/05
to Perl 6 Internals
On Wed, 6 Apr 2005, Chip Salzenberg wrote:

> 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:
>>>
>>> darwin
>>> linux-x86-gcc3.*
>>> win32-ms-cl
>>
>> 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

Jeff Horwitz

unread,
Apr 7, 2005, 10:59:41 AM4/7/05
to MrJoltCola, l...@toetsch.at, perl6-i...@perl.org
On Thu, 7 Apr 2005, MrJoltCola wrote:

> 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.

-jeff

MrJoltCola

unread,
Apr 7, 2005, 10:48:28 AM4/7/05
to l...@toetsch.at, perl6-i...@perl.org
At 03:21 AM 4/7/2005, Leopold Toetsch wrote:
>MrJoltCola <mrjol...@mindspring.com> wrote:
> > 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:
> >>
> >> darwin
> >> linux-x86-gcc3.*
> >> win32-ms-cl
>
> > You should round that out with 64-bit Sparc.
>
>You are volunteering for running smoke tests regularly ;-) Patches to
>PLATFORMS are equally welcome.

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
is invalid
because most Sparc folks are running a pre-built Perl and GCC binary that
was built
on a distributor's system. So for example, even though the system will have
both
Perl and GCC, Perl's config will say it was built with Sun's CC compiler.
Configure
fails and has to be hand hacked to work, or you have to build your own Perl
to get
the config before you build Parrot (not too tough, but should not be required).

-Melvin

Chip Salzenberg

unread,
Apr 7, 2005, 10:56:28 AM4/7/05
to MrJoltCola, l...@toetsch.at, perl6-i...@perl.org
According to MrJoltCola:

> 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 is invalid because most Sparc folks are running
> a pre-built Perl and GCC binary that was built on a distributor's
> system.

Not specifically about SPARC: Is there already a configuration
roadmap, something for me to start with as I look to What Should Be?

Chip Salzenberg

unread,
Apr 7, 2005, 12:32:10 PM4/7/05
to Peter Sinnott, Jeff Horwitz, MrJoltCola, l...@toetsch.at, perl6-i...@perl.org
According to Peter Sinnott:
> I set up a tinder server a couple of weeks ago.
> Not sure if anyone else looks at it.
>
> http://unlinked.vm.bytemark.co.uk/tinder//parrot/status.html

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
implications, etc?

Peter Sinnott

unread,
Apr 7, 2005, 12:26:03 PM4/7/05
to Jeff Horwitz, MrJoltCola, l...@toetsch.at, perl6-i...@perl.org

I set up a tinder server a couple of weeks ago.


Not sure if anyone else looks at it.

The url is

http://unlinked.vm.bytemark.co.uk/tinder//parrot/status.html

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.


> -jeff
>

--
We exist to collaboratively utilize scalable deliverables and competently
engineer cutting edge leadership skills because that is what the customer
expects

MrJoltCola

unread,
Apr 7, 2005, 1:45:51 PM4/7/05
to Chip Salzenberg, Peter Sinnott, Jeff Horwitz, l...@toetsch.at, perl6-i...@perl.org
At 12:32 PM 4/7/2005, Chip Salzenberg wrote:
>According to Peter Sinnott:
> > I set up a tinder server a couple of weeks ago.
> > Not sure if anyone else looks at it.
> >
> > http://unlinked.vm.bytemark.co.uk/tinder//parrot/status.html
>
>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
>implications, etc?

It was on parrotcode or dev.perl.org at some point.
Maybe that can be reused?

-Melvin

Andy Dougherty

unread,
Apr 7, 2005, 2:51:20 PM4/7/05
to Perl6 Internals
On Thu, 7 Apr 2005, Chip Salzenberg wrote:

> 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
http://www.nntp.perl.org/group/perl.perl6.build
and probably the perl6-internals archives around the same time.

--
Andy Dougherty doug...@lafayette.edu

Brent 'Dax' Royal-Gordon

unread,
Apr 7, 2005, 3:53:42 PM4/7/05
to Chip Salzenberg, MrJoltCola, l...@toetsch.at, perl6-i...@perl.org
Chip Salzenberg <ch...@pobox.com> wrote:
> According to MrJoltCola:
> > 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 is invalid because most Sparc folks are running
> > a pre-built Perl and GCC binary that was built on a distributor's
> > system.
>
> Not specifically about SPARC: Is there already a configuration
> roadmap, something for me to start with as I look to What Should Be?

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
$ su
# ./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
Miniparrot.

--
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 Salzenberg

unread,
Apr 7, 2005, 4:05:47 PM4/7/05
to br...@brentdax.com, MrJoltCola, l...@toetsch.at, perl6-i...@perl.org
According to Brent 'Dax' Royal-Gordon:

> 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 [ANSI C only].

Excellent.

Robert Spier

unread,
Apr 7, 2005, 11:12:26 PM4/7/05
to perl6-i...@perl.org
> It was on parrotcode or dev.perl.org at some point.
> Maybe that can be reused?

Our tinderbox.perl.org volunteer is working on it. We've been nudging
him, and he's got some cool stuff going on.

Jared Rhine

unread,
Apr 26, 2005, 5:01:17 AM4/26/05
to Perl 6 Internals
[Chip == ch...@pobox.com on Wed, 6 Apr 2005 18:24:49 -0400]

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
Chip> freeze...

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?

-- ja...@wordzoo.com

War is God's way of teaching Americans geography. -Ambrose Bierce

Reply all
Reply to author
Forward
0 new messages