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)
--
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
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/
> 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
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
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
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
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
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
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
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!
To that end, I will not be running for reelection to the steering council.