Re: 5.10.2
Nicholas Clark
> Following my relatively painless experience with 5.13.8, I'm willing to
> do the release engineering work for a 5.10.2. I invite Jesse to specify
> terms of reference for commits to maint-5.10, and releasability criteria
> for 5.10.2.
OK, you might be about to have some "fun", as either:
1: You need to merge over the cpan/dist/ext rearranging
or
2: Anything you merge may need some considerable amount of editing
Also, I realise that you might change your mind based on the level of "fun"
that you turn out to have, but are you just thinking of doing a 5.10.2 as
"maint-5.10 rides off into the sunset", or that or that 5.10.3 would be
plausible sometime later?
[Because the current best-guess answer to that might affect the terms of
reference for a 5.10.2]
Nicholas Clark
Zefram
>1: You need to merge over the cpan/dist/ext rearranging
>or
>2: Anything you merge may need some considerable amount of editing
I would not expect to retrofit the rearrangement. So yes, paths in
patches will need editing. It's fairly mechanical editing, easy to
get right. I'm prepared for some merge pain, and for release automation
to be less complete than it is for 5.13.
> are you just thinking of doing a 5.10.2 as
>"maint-5.10 rides off into the sunset", or that or that 5.10.3 would be
>plausible sometime later?
>
>[Because the current best-guess answer to that might affect the terms of
>reference for a 5.10.2]
Interesting, I didn't think that would make a difference. I'm
volunteering specifically for a 5.10.2, not for an indefinite series
of 5.10.x. But this is not a specific desire for 5.10.2 to be terminal;
it's a case of avoiding committing to too big a project.
What role do you foresee for 5.10.3, and what happens to 5.10.2 if there
won't be one?
-zefram
Nicholas Clark
> Nicholas Clark wrote:
> > are you just thinking of doing a 5.10.2 as
> >"maint-5.10 rides off into the sunset", or that or that 5.10.3 would be
> >plausible sometime later?
> >
> >[Because the current best-guess answer to that might affect the terms of
> >reference for a 5.10.2]
>
> Interesting, I didn't think that would make a difference. I'm
> volunteering specifically for a 5.10.2, not for an indefinite series
> of 5.10.x. But this is not a specific desire for 5.10.2 to be terminal;
> it's a case of avoiding committing to too big a project.
I wasn't *sure*, but I think it's as much a psychological thing
a: you start to be aware that you really mustn't screw up, as you've ruled
out allowing yourself another release
b: everyone else (if they care about the release) tries harder to get their
"thing" in, else they've missed the boat. Whereas "there will be another
one along in a while" might make it easier to declare a cut off.
> What role do you foresee for 5.10.3, and what happens to 5.10.2 if there
> won't be one?
Not sure, but arguably it's actually more useful from a communication/
marketing/expectation-setting perspective than from a "what goes in it".
5.10.1 *wasn't* described as "the final maint-5.10" release, so rightly or
wrongly some people will be assuming that more might well happen.
Having a 5.10.2 announced as "This is the maint-5.10 sunset release. Start
planning your migration" feels like the right way to get the message out,
balancing the positive with the can-be-perceived-as-not-so-positive
[by everyone effectively enjoying for free the hard work of people such as
yourself kind enough to volunteer]
The questions about 5.10.3 is really
a: "What happens after 5.10.2 if something in it gets a CVE?"
b: "Are we able to make a clear, coherent, communicable, credible support
and lifecycle policy?" (and stick to it)
Nicholas Clark
Jesse Vincent
On Mon, Dec 20, 2010 at 11:33:02AM +0000, Zefram wrote:
> Nicholas Clark wrote:
> >1: You need to merge over the cpan/dist/ext rearranging
> >or
> >2: Anything you merge may need some considerable amount of editing
>
> I would not expect to retrofit the rearrangement. So yes, paths in
> patches will need editing. It's fairly mechanical editing, easy to
> get right. I'm prepared for some merge pain, and for release automation
> to be less complete than it is for 5.13.
And, indeed, our maint policy wouldn't let you get away with too much
that would touch those parts of the tree.
> Interesting, I didn't think that would make a difference. I'm
> volunteering specifically for a 5.10.2, not for an indefinite series
> of 5.10.x. But this is not a specific desire for 5.10.2 to be terminal;
> it's a case of avoiding committing to too big a project.
>
> What role do you foresee for 5.10.3, and what happens to 5.10.2 if there
> won't be one?
These are valid questions. By our current policy, 5.10 is only even
nominally supported for a little while longer.
I'm not seriously opposed to your plan, though I'd like to proceed with
some level of caution. With our current policies and procedures, having
3 "active" branches going will be somewhat of a strain on our resources
(as even 2 is still being somewhat interesting for us)
Is there a particular bug or issue in 5.10 that triggered your desire to
jump on this particular sword or are the rose-tinted glasses included in
the current release engineer kit just of a particularly high quality?
Before committing myself fully to blessing this plan, I'd really like to get
a sense of what you'd want to see backported into 5.10.2.
I think that Nick's(?) suggestion of an official "sunset" announcement
along with 5.10.2 is a reasonable one, but we should certainly have
contingency plans for a 5.10.3 in the event of a regression.
All that being said, thank you for volunteering. I do appreciate it.
Best,
Jesse
Zefram
> By our current policy, 5.10 is only even
>nominally supported for a little while longer.
This leads to an obvious answer for Nicholas's question about a
hypothetical 5.10 CVE: once 5.14 is out, we're not making any guarantees
about support for 5.10.
>Is there a particular bug or issue in 5.10 that triggered your desire to
>jump on this particular sword
Mainly a lingering feeling from 5.10.1 time that we weren't done yet.
It seemed quite early in the 5.10 lifecycle, such that 5.10 users could
expect a more mature version to come along later. In reflecting on it
now, I also wonder about users upgrading by one major version at a time
so as to get due notice of deprecations: in the 5.8.9->5.10.1->5.12.2
chain, 5.10.1 feels like a weak link.
I suppose this viewpoint suggests a "sunset" 5.10.2, with no expectation
of a 5.10.3. At least, no 5.10.3 unless we later decide to change our
maint policy to explicitly support three maint branches.
There's only one specific item that I have in mind for 5.10.2, which
is the fix for [perl #68590], a personal itch. That came up during
the 5.10.1 RC phase, so the fix narrowly missed going into 5.10.1.
However, if the terms of reference for 5.10.2 were very narrow, only
permitting fixes for regressions from 5.8, then this fix wouldn't be
allowed in. It's not a vital fix for anything I do anyway, since there
is an effective-but-unclean workaround (Lexical::SealRequireHints).
> are the rose-tinted glasses included in
>the current release engineer kit just of a particularly high quality?
I had thought for some time that 5.10.2 was worth the effort, and I
suggested to Nicholas offline that I might be up for volunteering for it
if no one else did. But the pumpking burnout phenomenon was a worry,
with everyone describing how arduous making a release is. When making
me a dev release engineer came up, I resolved to treat the experience as
a taste of what 5.10.2 would involve, and to make a decision afterwards
about whether it was so horrific as to put me off.
In the end, 5.13.8 went pretty smoothly. The formerly-arcane process
has been codified well. Not only did I know what had to be done at
each step, I also understood why it had to be done, and was able to
apply clue when things didn't work perfectly. At no point did I find
myself in danger of getting out of my depth, and I never got stressed.
So the conclusion is that I'm comfortable with at least this subset of
the pumpking job, and can do more.
>Before committing myself fully to blessing this plan, I'd really like to get
>a sense of what you'd want to see backported into 5.10.2.
I haven't gone looking to make a list of specific things to backport.
I'm open as to how wide a net we'd cast.
-zefram