The Great Pumpkin
Jesse Vincent
of the highlights of any Halloween was a Peanuts/Charlie Brown special
called "The Great Pumpkin[1][2]" Each year, Linus would spend Halloween
in a pumpkin patch awaiting the arrival of the "Great Pumpkin". The Great
Pumpkin is a Santa-Claus like figure. He does bring toys like Santa. But
unlike Santa, who gives away toys because it's his job, he gives away
toys because it's the right thing to do[3]. Linus never gets to meet
the Great Pumpkin, but that doesn't shake his faith. He waits patiently.
I'm tired of being Linus. And I don't want perl porters around the world
to spend their Halloweens wondering whether there is a Great Pumpkin
or not.
To this end, I asked our former pumpkings for their blessing to pick up
the patch pumpkin and shepherd 5.12 into existence.
After talking with a fair number of folks over the course of the
spring and summer, I have, I hope, gotten us onto a monthly schedule
for blead with a release engineering talent pool a few people deep.
5.11.1 definitely went much more smoothly than 5.11.0. We'll see how
much Yves wants to maim me after he does 5.11.2 on the 20th. But every
release gets more automated and every release gets smoother. blead is
on a reasonable trajectory. Already, we're starting to see contributors
stepping up to test and stabilize in advance of the monthly releases.
At this point, it's time to start planning for 5.12, 5.14 and
forward. Rafael has suggested "Perl 5.12 for Christmas." At this point,
we will be lucky if we hit Coptic Christmas[4]. However, I would rather
aim for Christmas 2009 and miss than aim for "some date later in the
future" and miss.
The plan for Perl 5 Release 12 is as follows:
* Blead will feature-freeze on November 21. (just after Yves ships 5.11.2)
After that point, no feature should be added or removed from blead.
After that point, dual-lifed modules should only be updated from CPAN
versions to fix major bugs or security issues.
Exceptions will be considered on a case by case basis.
* See if anyone tries to kill me in my sleep
* We will polish and bugfix and push on others to fix bugs in
blead/5.12-to-be until we have something that we feel is of a higher
quality than the current release of 5.10.
(During this time, monthly release of blead will continue)
* When I believe that blead is of sufficient quality to ship, I'll issue
a final call for testing in advance of an RC.
* Get former pumpkings to sanity-check the release-worthyness. If they
give us a "no-go", we'll iterate until they consider the state of blead
to be a solid, shippable 5.12.0.
* Ship 5.12.0RC1
* Yell at people to test the RC
* Yell at people to test the RC
* Yell at people to test the RC
* Ship RC_ to fix bugs found/reported/discovered to be serious enough
to block a release.
* Repeat as necessary
* Ship 5.12.0
* Yell at people to test 5.12.0
* Ship 5.12.1RC1 30 days after 5.12.0 with whatever bugfixes, cleanups,
improvements were found to be necessary when users _actually_ test
the release.
* Ship 5.12.1 with a methodology similar to that used for 5.12.0
* branch maint-5.12 and reopen the blead tree
Assuming that we're happy with the results, my intent is that we spin
up the same process for Perl 5 Release 14 next October or November.
Historically, our pumpking has been:
* our release engineer
* our mediator
* our decision maker
* our project manager
* our primary patch applier
* our hard-core C code reviewer
* our internals guru
* our language designer
* our sacrificial punching bag
* and many other things...
I'm doing what I can to delegate and automate release engineering,
though I know that the ultimate responsibility always falls on the
person stubborn enough to claim responsibility. Many other parts of
the pumpking role are the sorts of things I spent a lot of time on when
I was foolhardy enough to stare into the gaping maw of Perl 6 as their
nominal project manager.
My language design tends to the conservative. I'd rather see the core
made more flexible, extensible and easier to maintain than see language
features added or removed.
I am not a skilled C hacker. I don't expect to magically become a skilled
C hacker. I am not a perlguts rockstar. I'm going to have to lean on those
of you who _are_ excellent C and perlguts hackers, but that's work you're
already doing (and that I'm grateful for).
Best,
Jesse
[1] Yes, the same special every year. I had a very boring and sheltered
childhood.
[2] http://en.wikipedia.org/wiki/The_Great_Pumpkin
[3] http://en.wikipedia.org/wiki/The_Great_Pumpkin#Differences_between_the_Great_Pumpkin_and_Santa_Claus
[4] Thursday, January 7, 2010 (December 25 on the Julian Calendar)
--
David Golden
> To this end, I asked our former pumpkings for their blessing to pick up
> the patch pumpkin and shepherd 5.12 into existence.
Hurrah! +1 While not a former pumpking, I think the work you've done
to get 5.11.X moving demonstrates you have what it takes.
> * Blead will feature-freeze on November 21. (just after Yves ships 5.11.2)
> After that point, no feature should be added or removed from blead.
> After that point, dual-lifed modules should only be updated from CPAN
> versions to fix major bugs or security issues.
> Exceptions will be considered on a case by case basis.
I can already tell you that the CPAN Meta Spec 2.0 design process is
wrapping up around then and there will be major changes to the
toolchain modules to support it probably in the month of December.
You'll need to decide if you want to get those changes (or some of
them) into Version 12 or let them slip to 14. No decision needed now,
but I want to put in a placeholder for discussions later.
> * See if anyone tries to kill me in my sleep
Do you favor katana or nunchucks? ( http://xkcd.com/225/ )
-- David
Curtis Jewell
up to date with you as we go through this, here is what I'm going to be
doing so I can feel comfortable releasing an adequately-tested version
of Strawberry Perl 5.12.x:
On Sat, 31 Oct 2009 13:20 -0400, "Jesse Vincent" <je...@fsck.com> wrote:
...
> The plan for Perl 5 Release 12 is as follows:
>
> * Blead will feature-freeze on November 21. (just after Yves ships
> 5.11.2)
> After that point, no feature should be added or removed from blead.
> After that point, dual-lifed modules should only be updated from CPAN
> versions to fix major bugs or security issues.
> Exceptions will be considered on a case by case basis.
I should be able to build a "Strawberryish" 5.11.2 after the United
States Thanksgiving [Nov 26th] if 5.12.0 RC1 is not available at that
point. (I may still be making the big changes
[relocatability/merge-module use/64-bit] at that point.)
> * See if anyone tries to kill me in my sleep
>
> * We will polish and bugfix and push on others to fix bugs in
> blead/5.12-to-be until we have something that we feel is of a higher
> quality than the current release of 5.10.
>
> (During this time, monthly release of blead will continue)
>
> * When I believe that blead is of sufficient quality to ship, I'll issue
> a final call for testing in advance of an RC.
>
> * Get former pumpkings to sanity-check the release-worthyness. If they
> give us a "no-go", we'll iterate until they consider the state of blead
> to be a solid, shippable 5.12.0.
>
> * Ship 5.12.0RC1
>
> * Yell at people to test the RC
And to help in that testing, I'll commit to making a "Strawberryish"
5.12.0RC1 available within 10 days of the RC1 tarball's release (it
should be sooner, but the time frame you're aiming for may create
problems with other commitments.)
I should also be able to make future RC's available within 3 days of
release once the first one is done.
...
> * Ship 5.12.0
If we're aiming for Christmas - or even for Coptic Christmas - for this,
then I'll commit to having a beta released within a week to 10 days.
Since that beta would come during the RC period for Strawberry's January
release, I won't do a non-beta release for January, most likely. Part
of the reason is that 5.12.0 would be beta-tested as both 32-bit and
64-bit versions, as mentioned in previous messages.
> * Yell at people to test 5.12.0
>
> * Ship 5.12.1RC1 30 days after 5.12.0 with whatever bugfixes, cleanups,
> improvements were found to be necessary when users _actually_ test
> the release.
In this case, then Strawberry WON'T end up doing a full release for
5.12.0, as I'm going to have to do a build for this RC before I would
feel comfortable taking a new release of 5.12.0 out of beta as far as
Strawberry is concerned. [I prefer to have a month of "beta" time for
the bugs to shake out - 2 weeks at an absolute minimum]
> * Ship 5.12.1 with a methodology similar to that used for 5.12.0
This would probably end up being the release that would be paired with
5.10.x for a non-beta release for the April 2010 cycle. I'm in the
process of deciding whether to give up on building 5.8.x versions of
Strawberry for January... (if I can make Strawberry 5.10.1.1 "any
location" installable using -Duserelocatableinc for January 2010, then I
probably will. If not, then April 2010 for sure.)
> * branch maint-5.12 and reopen the blead tree
>
> Assuming that we're happy with the results, my intent is that we spin
> up the same process for Perl 5 Release 14 next October or November.
If you decide on November 2010 to start the "Perl 5 Release 14" process,
then start earlier in the month, please. That way, I have enough time
to build RC's in the "big changes" month and hopefully have a final
version that I can beta-test, at worst, late in the "beta-test" month.
October would be better. But I'll live with whoever the pumpking at that
time decides.
For those of you who don't know (most of you?), the release cycle for
Strawberry that I have to shoehorn releases of Perl into is:
1) Make big changes, and break things in February, May, August, or
November
2) Finalize the big changes, fix things, and beta-test in March, June,
September, or December
3) Release candidates, and hopefully the final version, (with a maint
branch) in April, July, October, January
--Curtis
--
Curtis Jewell
csje...@cpan.org http://csjewell.dreamwidth.org/
pe...@csjewell.fastmail.us http://csjewell.comyr.org/perl/
"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c
Strawberry Perl for Windows betas: http://strawberryperl.com/beta/
David E. Wheeler
> To this end, I asked our former pumpkings for their blessing to pick
> up
> the patch pumpkin and shepherd 5.12 into existence.
Yay!
> The plan for Perl 5 Release 12 is as follows:
<snip content-disposition="sane" />
+1
> Assuming that we're happy with the results, my intent is that we spin
> up the same process for Perl 5 Release 14 next October or November.
+100 Awesome news, thanks.
> I'm doing what I can to delegate and automate release engineering,
> though I know that the ultimate responsibility always falls on the
> person stubborn enough to claim responsibility. Many other parts of
> the pumpking role are the sorts of things I spent a lot of time on
> when
> I was foolhardy enough to stare into the gaping maw of Perl 6 as their
> nominal project manager.
A position, I notice, that you managed to make largely irrelevant,
yes? Good job, that.
> My language design tends to the conservative. I'd rather see the core
> made more flexible, extensible and easier to maintain than see
> language
> features added or removed.
Does that mean that you'll be making language design decisions, or
relying on others?
> I am not a skilled C hacker. I don't expect to magically become a
> skilled
> C hacker. I am not a perlguts rockstar. I'm going to have to lean on
> those
> of you who _are_ excellent C and perlguts hackers, but that's work
> you're
> already doing (and that I'm grateful for).
Sounds like a terrific plan. Thanks for stepping up, Jesse.
Best,
David
Jesse
> >made more flexible, extensible and easier to maintain than see
> >language
> >features added or removed.
>
> Does that mean that you'll be making language design decisions, or
> relying on others?
After seeking the counsel and advice of those more experienced and wiser
than I, yes, I expect that I will make decisions. Of course, I'd be
happiest if you lot come up with appropriately [in]sane ideas and
implementations and I just get to kick back, relax and take all the
credit. ;)
Best,
Jesse
Jesse
> wrapping up around then and there will be major changes to the
> toolchain modules to support it probably in the month of December.
> You'll need to decide if you want to get those changes (or some of
> them) into Version 12 or let them slip to 14. No decision needed now,
> but I want to put in a placeholder for discussions later.
My inclination is "big changes moments before we'd like to ship" are
something I'd like to avoid. That said, as your design process finishes
up and implementation begins, keep p5p in the loop. If there are things
we can do to ease the transition to the new toolchain, or help users
not get hurt, well, I like my users unhurt. Then they won't try to hurt
me. [see below]
> > * See if anyone tries to kill me in my sleep
>
> Do you favor katana or nunchucks? ( http://xkcd.com/225/ )
Not telling. I reserve the right to defend myself, no matter what
license you attack me with.
Best,
Jesse
Jesse
On Sat, Oct 31, 2009 at 02:22:43PM -0600, Curtis Jewell wrote:
> Considering that I'm (because of Strawberry) going to be needing to keep
> up to date with you as we go through this, here is what I'm going to be
> doing so I can feel comfortable releasing an adequately-tested version
> of Strawberry Perl 5.12.x:
Fantastic. If there are things we can do to help keep strawberry in the
loop or up to date, please do raise them on p5p. (That goes for other
vendors who ship Perl as a product, with a product or make art with the
source code. Whatever. If the Perl release matters to you, then your
involvement in the release process will help make sure everything goes
smoothly.)
> I should be able to build a "Strawberryish" 5.11.2 after the United
> States Thanksgiving [Nov 26th] if 5.12.0 RC1 is not available at that
> point. (I may still be making the big changes
> [relocatability/merge-module use/64-bit] at that point.)
*nod* How much do you tend to need to massage the Perl distribution to
get it into shape for Strawberry? Are things that would make sense to
bring upstream to the core?
> > * Yell at people to test the RC
>
> And to help in that testing, I'll commit to making a "Strawberryish"
> 5.12.0RC1 available within 10 days of the RC1 tarball's release (it
> should be sooner, but the time frame you're aiming for may create
> problems with other commitments.)
Understood. Do note that that timeframe depends entirely on what people
find for bugs. If we can get a strawberryish distribution that we can
drop the RC source code into as it stabilizes, that would be excellent.
How plausible is it for an arbitrary porter to build a distribution that
is identical to strawberry from a given git revision?
>
> If we're aiming for Christmas - or even for Coptic Christmas - for this,
> then I'll commit to having a beta released within a week to 10 days.
> Since that beta would come during the RC period for Strawberry's January
> release, I won't do a non-beta release for January, most likely. Part
> of the reason is that 5.12.0 would be beta-tested as both 32-bit and
> 64-bit versions, as mentioned in previous messages.
Given Strawberry's focus as an end-user binary distribution, I'm
thrilled that our target date (which depends entirely on us getting all
our RC blockers taken care of quickly and not running into more) means
that we just miss one of your release dates. That makes it _very_ easy
to tell people that they should be testing the new release and to get
comfortable with it before foisting it on the Strawberry-using world ;)
> > * Yell at people to test 5.12.0
> >
> > * Ship 5.12.1RC1 30 days after 5.12.0 with whatever bugfixes, cleanups,
> > improvements were found to be necessary when users _actually_ test
> > the release.
>
> In this case, then Strawberry WON'T end up doing a full release for
> 5.12.0, as I'm going to have to do a build for this RC before I would
> feel comfortable taking a new release of 5.12.0 out of beta as far as
> Strawberry is concerned. [I prefer to have a month of "beta" time for
> the bugs to shake out - 2 weeks at an absolute minimum]
That, again, doesn't bother me too much. The goal of getting the first
update to 5.12 out in that kind of timeframe is to make sure that any
bugs that shake out in the first stable release of 5.12 get sorted out
quickly and end up in as few production deployments as possible.
> > * Ship 5.12.1 with a methodology similar to that used for 5.12.0
>
> This would probably end up being the release that would be paired with
> 5.10.x for a non-beta release for the April 2010 cycle. I'm in the
> process of deciding whether to give up on building 5.8.x versions of
> Strawberry for January... (if I can make Strawberry 5.10.1.1 "any
> location" installable using -Duserelocatableinc for January 2010, then I
> probably will. If not, then April 2010 for sure.)
>
Sounds good.
> > * branch maint-5.12 and reopen the blead tree
> >
> > Assuming that we're happy with the results, my intent is that we spin
> > up the same process for Perl 5 Release 14 next October or November.
>
> If you decide on November 2010 to start the "Perl 5 Release 14" process,
> then start earlier in the month, please. That way, I have enough time
> to build RC's in the "big changes" month and hopefully have a final
> version that I can beta-test, at worst, late in the "beta-test" month.
> October would be better. But I'll live with whoever the pumpking at that
> time decides.
Definitely! That's part of why I announced the intent _now_.
Best,
Jesse
David Golden
>> I can already tell you that the CPAN Meta Spec 2.0 design process is
>> wrapping up around then and there will be major changes to the
>> toolchain modules to support it probably in the month of December.
>> You'll need to decide if you want to get those changes (or some of
>> them) into Version 12 or let them slip to 14. No decision needed now,
>> but I want to put in a placeholder for discussions later.
>
> My inclination is "big changes moments before we'd like to ship" are
> something I'd like to avoid. That said, as your design process finishes
> up and implementation begins, keep p5p in the loop. If there are things
> we can do to ease the transition to the new toolchain, or help users
> not get hurt, well, I like my users unhurt. Then they won't try to hurt
> me. [see below]
Here's the timeline:
* tomorrow: I declare the "public comment" period closed
* before Dec 1: CPAN Meta Spec working group debates patches until we
have sufficient consensus on a new spec
* We implement the new spec
So... assuming the patches converge quickly and the working group can
decide quickly, we could accelerate the implementation process.
(sigh... November was already looking like a hellish month for me).
Major areas of implementation:
* CPAN spec writer/parser/validator -- as it looks like we're moving
to JSON as the format for 2.0+, we'll need to bring the (perl) JSON
distribution into core and create a simple META file wrapper around it
it and Parse::CPAN::Meta, depending on the file format. That should
be relative quick and I think we can get it done in time for Version
12.
* CPAN/CPANPLUS -- need to be updated to look for (and prefer)
META.json files and to use the new META spec handler module. Their
behaviors may need to be altered in subtle ways to be consistent with
the spec. E.g. it looks like there is going to be a new "prefers"
prerequisite type that is not an absolute "requires", but should be
installed except on resource constrained systems or if a user opts
out. This allows authors to say 'requires Params::Validate' and
'prefers Params::ValidateXS' and the like.
If that doesn't get done in time for Version 12, or is deemed too
risky, it can probably slip. It means people may not benefit from
META 2.0 changes in newly released distributions unless they upgrade
CPAN/CPANPLUS, but there will be a period of adoption anyway before
META 2.0 becomes widespread
* Distribution generators (M::B, EU::MM, M::I) -- need to be changed
to generate legal 2.0 META files. This will be the most significant
effort as there will be many subtle and not-so-subtle changes. But as
this only affects authors, they can reasonably upgrade their tools
before releasing new distributions.
As a side note, it would be great to get all three of M::B, EU::MM and
M::I generating the new MYMETA files for CPAN toolchain to communicate
dependencies in a standardized way. CPAN.pm already supports it in
core; I don't know about CPANPLUS; Module::Build dev supports it;
there's been some work on M::I and EU::MM, but I don't know the
status.
If I had to prioritize an area of work for November, I'd actually pick
MYMETA over the 2.0 spec. It's lower risk and higher reward.
-- David
Jesse
> It means people may not benefit from
> META 2.0 changes in newly released distributions unless they upgrade
> CPAN/CPANPLUS, but there will be a period of adoption anyway before
> META 2.0 becomes widespread
At this point, does the toolchain group have a good sense of what "may
not benefit from" means? Will people be unable to install modules using
the new spec? Will they have to manually resolve dependencies? Or will
there be some sort of glue in the PAUSE/CPAN toolchain to make it
transparent to users?
It sounds like the new infrastructure is going to make a lot of module
installation issues a lot easier to deal with once it's fully
operational. I just want to make sure that we understand the
reprecussions of a partial adoption before we ship 5.12.
Best,
Jesse
David Golden
>> It means people may not benefit from
>> META 2.0 changes in newly released distributions unless they upgrade
>> CPAN/CPANPLUS, but there will be a period of adoption anyway before
>> META 2.0 becomes widespread
>
> At this point, does the toolchain group have a good sense of what "may
> not benefit from" means? Will people be unable to install modules using
> the new spec? Will they have to manually resolve dependencies? Or will
> there be some sort of glue in the PAUSE/CPAN toolchain to make it
> transparent to users?
One of the bigger changes visible to end users will be clarified
semantic around prerequisites. Particularly, the creation of the
"prefers" category that I mentioned for modules that are optional but
really should be installed. Right now, CPAN/CPANPLUS completely
ignore "recommends" in META.yml. In the near future, CPAN/CPANPLUS
should install "requires" and "prefers" by default and should give
users the option of installing "recommends". This is a better approach
that haphazard prompting that happens today in *.PL files.
That's one example.
David
Jesse Vincent
Two years ago today, I picked up the patch pumpkin. It feels like
a lifetime ago. (I'll spare you the montage sequence of fifteen-plus
release engineers typing madly to put together the 28 releases we've
put out in the past two years.)
It's time for me to step back.
I'm thrilled to announce that Ricardo Signes (RJBS) has agreed to be our
next pumpking. He has a fine balance of level-headedness, pragmatism,
language design skill, and an almost fanatical devotion to Perl 5. Over
the past month, he and I have chatted extensively about the future of
Perl 5 and I have no doubt that he will be an excellent project leader.
No two pumpkings are alike - Rik will certainly do some things differently
than I have, but I have the utmost faith that he'll do things well. He
and I agree on the broad outlines of the vision for the future of Perl 5
that I spoke about this summer and wrote about on p5p earlier this fall,
though I know he and I differ on some of the implementation details.
You can rest assured that you'll see Perl 5.15.5 on November 20, 2011,
followed by 5.15.6 on December 20, 2011 and 5.14.3 sometime in late
December. Perl 5.16 will appear early in Q2 2012.
Stepping back has been an incredibly difficult decision for me. I find
myself increasingly focused on my new startup and know that Perl 5
deserves more from the pumpking than I'm able to give it. At the same
time, the past couple years have been an amazing experience and I feel
truly privileged to have had the opportunity to work with so many of you.
Thank you all so much!
Best,
Jesse
--
Abigail
> Dearest Porters,
>
> Two years ago today, I picked up the patch pumpkin. It feels like
> a lifetime ago. (I'll spare you the montage sequence of fifteen-plus
> release engineers typing madly to put together the 28 releases we've
> put out in the past two years.)
>
> It's time for me to step back.
be where it's now if it wasn't for your work.
And good luck to Ricardo.
Abigail
--
The pumpking is dead! Long live the pumpking!
Leon Timmermans
Leon
Paul Johnson
>
> Two years ago today, I picked up the patch pumpkin. It feels like
> a lifetime ago. (I'll spare you the montage sequence of fifteen-plus
> release engineers typing madly to put together the 28 releases we've
> put out in the past two years.)
>
> It's time for me to step back.
Perl in general seems to be in good health and I believe that a lot of
that can be attributed to your leadership.
I have no doubt that Rik will continue the long line of Perl pumpkings
of whom I am in awe.
(Is pumpkin passing at Hallowe'en now becoming traditional?)
--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net
Dave Mitchell
--
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
-- Monty Python, "Finland"
Alberto Simões
Ricardo, thanks for your offer. These will be difficult (but pleasant)
times :)
Cheers
ambs
CEHUM
David Golden
> I'm thrilled to announce that Ricardo Signes (RJBS) has agreed to be our
> next pumpking.
years and for putting Perl 5 on a solid footing.
Ricardo -- thank you (not only for your hard work) but for
volunteering to keep us moving forward.
-- David
Craig A. Berry
contributions that have made Perl core development a smooth-running
machine these last couple of years, not the least of which is
arranging for such a competent and energetic successor and a smooth
transition. Don't forget us when your start-up takes off and you
become a billionaire philanthropist :-).
Jesse Vincent
of a stranger.
Best,
Jesse
Shlomi Fish
On Tue, 1 Nov 2011 11:48:11 +0100
Paul Johnson <pa...@pjcj.net> wrote:
> On Mon, Oct 31, 2011 at 06:28:09PM -0400, Jesse Vincent wrote:
> > Dearest Porters,
> >
> > Two years ago today, I picked up the patch pumpkin. It feels like
> > a lifetime ago. (I'll spare you the montage sequence of fifteen-plus
> > release engineers typing madly to put together the 28 releases we've
> > put out in the past two years.)
> >
> > It's time for me to step back.
>
chaos that is my perl5-porters mail folder. I thank Jesse for being such a wonderful pumpking and Ricardo for volunteering to be the new one.
Regards,
Shlomi Fish
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
"Humanity" - Parody of Modern Life - http://shlom.in/humanity
Nobody expects the Randal Schwartz condition!
— David Fetter
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Ricardo Signes
> a lifetime ago.
tradition established, the next pumpking will do the job for sixteen years.
They will fly by, trust us!
Who will this lucky soul be? Sawyer!
Sawyer bravely volunteered to take on the pumpkin, and I know he will do a good
job of it. For those of you who have not worked with him before, I will assure
you that he is a patient, thoughtful, intelligent, humble human being.
I will still release Perl v5.24.0 and v5.25.0 on schedule, after which time I
will consider myself off the hook, and Sawyer on it. I have tried to keep
things in a state that will not cause him too much distress.
Good luck, Sawyer! Remember, if the coming sixteen years seem daunting, at
least you got in now, and now when the term was up to a cool 256.
--
rjbs
Father Chrysostomos
> Good luck, Sawyer! Remember, if the coming sixteen years seem daunting, at
> least you got in now, and now when the term was up to a cool 256.
enough to take over?
Ricardo Signes
like free software developers.
--
rjbs
Alberto Simões
On 24/04/2016 18:42, Samuel Smith wrote:
> I was wondering who it was going to be. Thank you Sawyer for
> volunteering. Now we can embed Dancer straight into core.
That should be the first thing. Now that CGI is out, we need a
substitute :D
Good work, Sawyer.
Best,
Alberto
Samuel Smith
volunteering. Now we can embed Dancer straight into core.
Shlomi Fish
Regards,
Shlomi Fish
Father Chrysostomos
> I was wondering who it was going to be. Thank you Sawyer for
> volunteering. Now we can embed Dancer straight into core.
'Mojolicious.pm'? :-)
Shlomi Fish
just an off-topic nitpick.
> > Two years ago today, I picked up the patch pumpkin. It feels like
> > a lifetime ago.
>
> Jesse held the pumpkin for two years. I have squared that, to four. The
> tradition established, the next pumpking will do the job for sixteen years.
> They will fly by, trust us!
years-squared (or year^2 or year**2 or year²). Since a year is about
3.15 * 10**7 seconds then a year squared would be about 9.9225 * 10**14
seconds-squared . Time squared is not a measurement of time, but may sometimes
be useful because in physics for example, acceleration is measured in
metres-per-second-squared (or in general distance divided by time squared), see
https://en.wikipedia.org/wiki/Acceleration .
What you can do is divide two years by a year to get simply a plain "2"
number, square that and multiply again by a year, but you'll get a different
result if you divide the time duration by a different unit of time (e.g: a day
or a second).
Anyway, cheers, and hope you have a happy Passover in case you celebrate it,
and whose duration squared lasts for one week squared or 49 squared days.
Regards,
Shlomi Fish [Squared]
--
Shlomi Fish
Laziness will bring the downfall of mankind, but I can’t be arsed to do
anything about it.
Peter Rabbitson
> Time squared is not a measurement of time
Shlomi Fish
https://en.wikipedia.org/wiki/Time_Cube which I found amusing. Thanks for the
reference.
Regards,
Shlomi Fish
Georg Moritz
> * Jesse Vincent <je...@fsck.com> [2011-10-31T18:28:09]
>> Two years ago today, I picked up the patch pumpkin. It feels like
>> a lifetime ago.
>
> Jesse held the pumpkin for two years. I have squared that, to four. The
> tradition established, the next pumpking will do the job for sixteen years.
there is an ambiguity which I wish was resolved favouring the lower end.
This would give us 5 pumpkings in 248 years instead of just 2 in 272.
Which, I firmly believe, wouldn't put us into such a hurry on our path to
immortality. Left-shift by one would be good enough in these times...
venceremos
0--gg-
--
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Glenn Golden
> Squaring two years does not give one four years , but instead four
> years-squared (or year^2 or year**2 or year²). Since a year is about
> 3.15 * 10**7 seconds then a year squared would be about 9.9225 * 10**14
> seconds-squared . Time squared is not a measurement of time, but may
> sometimes be useful because in physics for example, acceleration is
> measured in metres-per-second-squared (or in general distance divided
> by time squared),
>
that the computer you'll be doing most of your pumpkinging on might weigh
perhaps 5 kg with a screen area of say 0.25 m^2 or so, your total energy
expenditure in Joules over those 4 yr^2 of pumpkinging should be only about
5 kg * 0.25 m^2 / 4e15 s^2 ~= 3.13e-16 J ,
which is nearly nine orders of magnitude less than the energy expended
during a typical flea jump [1].
So probably you shouldn't worry about the workload. :)
(Wait... what?)
[1] Burrows, M, "How Fleas Jump", http://jeb.biologists.org/content/212/18/2881
Andy Dougherty
> * Jesse Vincent <je...@fsck.com> [2011-10-31T18:28:09]
> > Two years ago today, I picked up the patch pumpkin. It feels like
> > a lifetime ago.
>
> Jesse held the pumpkin for two years. I have squared that, to four. The
> tradition established, the next pumpking will do the job for sixteen years.
> They will fly by, trust us!
contributions to perl and to the supporting culture have been most
appreciated. Perl is a richer language and the community is a better
place because of your dedication and leadership.
Thank you.
--
Andy Dougherty doug...@lafayette.edu
Karl Williamson
Abigail
>> From the keyboard of Ricardo Signes [24.04.16,08:00]:
>
>> * Jesse Vincent <je...@fsck.com> [2011-10-31T18:28:09]
>>> Two years ago today, I picked up the patch pumpkin. It feels like
>>> a lifetime ago.
>>
>> Jesse held the pumpkin for two years. I have squared that, to four. The
>> tradition established, the next pumpking will do the job for sixteen years.
>
> Since 2 is the only number $x for which $x * $x == $x * 2 == $x << 1
Because if we're nitpicking, we'll nitpick.
Abigail
Shlomi Fish
Josh Juran <jju...@gmail.com> wrote:
> On Apr 25, 2016, at 11:55 AM, Shlomi Fish <shl...@shlomifish.org> wrote:
>
> > Anyway, cheers, and hope you have a happy Passover in case you celebrate it,
> > and whose duration squared lasts for one week squared or 49 squared days.
>
> Matzah.
>
Heh, heh. :-)
Regards,
Shlomi Fish
> Josh
>
Scott Baker
Just to add my $0.02...
I think your tenure on the PSC has been a major "net good" for Perl. Perl itself, the processes, the community and ecosystem have come a long way in the last four years.
I always look forward to reading your P5P emails from you because
they're very clear, concise, and positive. There is some amount of
"noise" on P5P, but everything that comes from you is "signal".
That's a fancy way of saying you raise the Signal to Noise ratio
on this list (and all around Perl) in a very significant manner.
You underestimate your contribution to Perl, but I'm here to tell you it's been considerable.
- scottchiefbaker
In the end, this was not to be. The era of the keeper of the patch pumpkin ended in 2020 with the adoption of perlgov and creation of the Perl Steering Council. I had retired from perl5-porters, but came back to try to help with what felt like something of a crisis. I didn't intend to stick around for three years, but here we are.
I am generally pleased with the work we got into the last two releases perl, but I don't think my contributions can, at this point, significantly impact the project's effective momentum and direction. I once read an article saying that burnout can be the result of an extended effort leading to negligible results. I want to avoid that fate, and to focus on things where I feel I will make a difference in the future, the way I feel I have, in the past, with Perl.
To that end, I will not be running for reelection to the steering council. I will continue to perform whatever small duties are required between now and the end of the election, but after that, you should expect me to return to my pre-2020 role as mostly-quiet lurker on the list.
I am proud of my work with p5p, and hope those of you with whom I collaborated are, too. I'm going to keep writing Perl for a long time to come, so I look forward to seeing what the team produces next!
John SJ Anderson
To that end, I will not be running for reelection to the steering council.
pe...@tux.freedom.nl
> I am proud of my work with p5p, and hope those of you with whom I
> collaborated are, too. I'm going to keep writing Perl for a long
Thanks for all the work you have put into the perl project.
Killing derailing discussions
Keeping us motivated
Getting structure into ideas
Relating ideas
Being a great person to talk with
Being a great person to game with
Being a great person to drink with
I'm sure we'll meet again (Sorry Vera Lynn) some sunny day
--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
Nicholas Clark
> I am generally pleased with the work we got into the last two releases perl, but I don't think my contributions can, at this point, significantly impact the project's effective momentum and direction. I once read an article saying that burnout can be the result of an extended effort leading to negligible results. I want to avoid that fate, and to focus on things where I feel I will make a difference in the future, the way I feel I have, in the past, with Perl.
>
Thanks for all that you have given to (and given up for) Perl
Oh my, what else can I write? By my (possibly buggy) analysis of
perlhist.pod you've made as many maint releases of Perl as I have, but then
also cat herded seven .0 releases to my zero. I doubt that this is going
going to be surpassed (by any mortal human).
You're a much better language (re)designer than I am, brought a lot of
insight that I missed, and have way more patience and diplomacy than me.
Keep doing what you find fun, and please visit at some point.
(the where is not for publication, but the when is - the first half of the
month is always better as that's when the best brewery in town is open)
Nicholas Clark