[ruby-core:54606] Plan to the first 2.0.0 patchlevel release.

[ruby-core:54606] Plan to the first 2.0.0 patchlevel release.

[Tomoyuki Chikanaga]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

Hello, Rubyists.

I'd like to release the first 2.0.0 patchlevel release about 2nd week of
May (after the japanese holidays week).
I will backport for some major issues, then move to release preparation
phase.
I've heard that [Bug #8040] has been expected to included in next release.

If you have some important issues, please tell me.
And when I create a test package, please help to check it.

Thank you for your kind support.

[-- Attachment #2: Type: text/html, Size: 576 bytes --]

[ruby-core:54743] Re: Plan to the first 2.0.0 patchlevel release.

[Marc-Andre Lafortune]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

Hi,

It would be great if #8357 would also make it too.

Thanks!

On Fri, Apr 26, 2013 at 1:15 PM, Tomoyuki Chikanaga
<nagachika00@gmail.com>wrote:

> I'd like to release the first 2.0.0 patchlevel release about 2nd week of
> May (after the japanese holidays week).
> I will backport for some major issues, then move to release preparation
> phase.
> I've heard that [Bug #8040] has been expected to included in next release.
>
> If you have some important issues, please tell me.
> And when I create a test package, please help to check it.
>
> Thank you for your kind support.
>

[-- Attachment #2: Type: text/html, Size: 1060 bytes --]

[ruby-core:54815] Re: Plan to the first 2.0.0 patchlevel release.

[Aman Gupta]

Could you please backport the following:

#8015
#8092
#8093
#8095
#8142
#8143
#8149

On Thu, May 2, 2013 at 6:13 AM, Marc-Andre Lafortune
<ruby-core-mailing-list@marc-andre.ca> wrote:
> Hi,
>
> It would be great if #8357 would also make it too.
>
> Thanks!
>
> On Fri, Apr 26, 2013 at 1:15 PM, Tomoyuki Chikanaga <nagachika00@gmail.com>
> wrote:
>>
>> I'd like to release the first 2.0.0 patchlevel release about 2nd week of
>> May (after the japanese holidays week).
>> I will backport for some major issues, then move to release preparation
>> phase.
>> I've heard that [Bug #8040] has been expected to included in next release.
>>
>> If you have some important issues, please tell me.
>> And when I create a test package, please help to check it.
>>
>> Thank you for your kind support.
>
>

[ruby-core:54826] Re: Plan to the first 2.0.0 patchlevel release.

[Tomoyuki Chikanaga]

Hello,

Thank you for your replies.

> It would be great if #8357 would also make it too.
I've backported r40561 at r40575.

> #8015
As I announced at [ruby-core:52534], new features will not be backported.

> #8092
> #8093
> #8095
These were already backported via [Backport #8147], [Backport #8146]
and [Backport #8145].

> #8142
> #8143
> #8149
These seem like performance optimization patches.
The optimization patches have less priority for backport.
I think a patch achieves noticeable performance improvement could be treated
as "a bug fix". It'll fixes a heavy performance reduction ;-)
But now, just before the coming release, I want to be conservative.

Thanks,


2013/5/6 Aman Gupta <ruby@tmm1.net>:
> Could you please backport the following:
>
> #8015
> #8092
> #8093
> #8095
> #8142
> #8143
> #8149
>
> On Thu, May 2, 2013 at 6:13 AM, Marc-Andre Lafortune
> <ruby-core-mailing-list@marc-andre.ca> wrote:
>> Hi,
>>
>> It would be great if #8357 would also make it too.
>>
>> Thanks!
>>
>> On Fri, Apr 26, 2013 at 1:15 PM, Tomoyuki Chikanaga <nagachika00@gmail.com>
>> wrote:
>>>
>>> I'd like to release the first 2.0.0 patchlevel release about 2nd week of
>>> May (after the japanese holidays week).
>>> I will backport for some major issues, then move to release preparation
>>> phase.
>>> I've heard that [Bug #8040] has been expected to included in next release.
>>>
>>> If you have some important issues, please tell me.
>>> And when I create a test package, please help to check it.
>>>
>>> Thank you for your kind support.
>>
>>
>

[ruby-core:54831] Re: Plan to the first 2.0.0 patchlevel release.

[Jon]

> > #8142
> > #8143
> > #8149
> These seem like performance optimization patches.
> The optimization patches have less priority for backport.
> I think a patch achieves noticeable performance improvement could be treated
> as "a bug fix". It'll fixes a heavy performance reduction ;-)
> But now, just before the coming release, I want to be conservative.

I don't understand your comment.

Is your concern that the internal improvement patches are too complex to backport this close to the
coming release, but you plan to backport them for the next 2.0.0 patchlevel release?

Jon

[ruby-core:54834] Re: Plan to the first 2.0.0 patchlevel release.

[Aman Gupta]

On Mon, May 6, 2013 at 6:05 AM, Tomoyuki Chikanaga
<nagachika00@gmail.com> wrote:
> Hello,
>
> Thank you for your replies.
>
>> It would be great if #8357 would also make it too.
> I've backported r40561 at r40575.
>
>> #8015
> As I announced at [ruby-core:52534], new features will not be backported.
>
>> #8092
>> #8093
>> #8095
> These were already backported via [Backport #8147], [Backport #8146]
> and [Backport #8145].

Great, thanks.

>
>> #8142
>> #8143
>> #8149
> These seem like performance optimization patches.
> The optimization patches have less priority for backport.
> I think a patch achieves noticeable performance improvement could be treated
> as "a bug fix". It'll fixes a heavy performance reduction ;-)
> But now, just before the coming release, I want to be conservative.

These three patches are very short and simple, so I believe they are
worth backporting. The chance for regression is very small.

However, I understand if you would prefer to be conservative for the
upcoming release.

  Aman

>
> Thanks,
>
>
> 2013/5/6 Aman Gupta <ruby@tmm1.net>:
>> Could you please backport the following:
>>
>> #8015
>> #8092
>> #8093
>> #8095
>> #8142
>> #8143
>> #8149
>>
>> On Thu, May 2, 2013 at 6:13 AM, Marc-Andre Lafortune
>> <ruby-core-mailing-list@marc-andre.ca> wrote:
>>> Hi,
>>>
>>> It would be great if #8357 would also make it too.
>>>
>>> Thanks!
>>>
>>> On Fri, Apr 26, 2013 at 1:15 PM, Tomoyuki Chikanaga <nagachika00@gmail.com>
>>> wrote:
>>>>
>>>> I'd like to release the first 2.0.0 patchlevel release about 2nd week of
>>>> May (after the japanese holidays week).
>>>> I will backport for some major issues, then move to release preparation
>>>> phase.
>>>> I've heard that [Bug #8040] has been expected to included in next release.
>>>>
>>>> If you have some important issues, please tell me.
>>>> And when I create a test package, please help to check it.
>>>>
>>>> Thank you for your kind support.
>>>
>>>
>>
>

[ruby-core:54903] Re: Plan to the first 2.0.0 patchlevel release.

[Tomoyuki Chikanaga]

Hello,


> I don't understand your comment.
>
> Is your concern that the internal improvement patches are too complex to backport this close to the
> coming release, but you plan to backport them for the next 2.0.0 patchlevel release?
No.
Basically, optimization is not a subject of backport.
If you think they are worth enough to backport, please move the
tickets to Ruby200 project,
or file a backport ticket with your reason.


2013/5/6 Jon <jon.forums@gmail.com>:
>> > #8142
>> > #8143
>> > #8149
>> These seem like performance optimization patches.
>> The optimization patches have less priority for backport.
>> I think a patch achieves noticeable performance improvement could be treated
>> as "a bug fix". It'll fixes a heavy performance reduction ;-)
>> But now, just before the coming release, I want to be conservative.
>
> I don't understand your comment.
>
> Is your concern that the internal improvement patches are too complex to backport this close to the
> coming release, but you plan to backport them for the next 2.0.0 patchlevel release?
>
> Jon
>

[ruby-core:54904] Re: Plan to the first 2.0.0 patchlevel release.

[Jon]

> 2013/5/6 Jon <jon.forums@gmail.com>:
> >> > #8142
> >> > #8143
> >> > #8149
> >> These seem like performance optimization patches.
> >> The optimization patches have less priority for backport.
> >> I think a patch achieves noticeable performance improvement could be treated
> >> as "a bug fix". It'll fixes a heavy performance reduction ;-)
> >> But now, just before the coming release, I want to be conservative.
> >
> > I don't understand your comment.
> >
> > Is your concern that the internal improvement patches are too complex to backport this close to the
> > coming release, but you plan to backport them for the next 2.0.0 patchlevel release?
> >
>
> On Sat, 11 May 2013 00:45:11 +0900
> Tomoyuki Chikanaga <nagachika00@gmail.com> wrote:
> No.
> Basically, optimization is not a subject of backport.
> If you think they are worth enough to backport, please move the
> tickets to Ruby200 project,
> or file a backport ticket with your reason.

I now understand the issue, thank you.

I have a different perspective on #8142, #8143, and #8149 and ask that you reconsider backporting
the patches to ruby_2_0_0 (not 1_9_x) for the following reasons:

1) While it is true that by removing unnecessary allocations and duplications these patches could be
viewed as optimizations, the patches could also be viewed as fixes to an "incorrect" original impl.
By "incorrect" I mean that Aman's code which performs fewer allocations and duplications is likely
what the original author would have preferred if he would have had more real-world usage info before
creating the original code. Yes, the old see-into-the-future gift ;)

2) The scope and size of the patches are small.

3) The patches do not appear to be the cause of new regressions on rubyci.org or ci.rubyinstaller.org.

4) Ruby 2.0.0 is the latest release and likely has not been accepted as the mainstream production-ready
version by a majority of users. Aman's patches make 2.0.0 more attractive, not less, and appear to have
minimal risk. Rather than incenting people to maintain private patch queues to gain the benefits of these
patches, the patches belong on the official ruby_2_0_0 branch.

As an aside (and regardless of what you decide) thank you for your spectacular efforts maintaining 2.0.0. In
my time with MRI I can't remember a time of such timely and regular backporting. Fabulous! :)

Jon