Backporting fixes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Backporting fixes

Sean P. DeNigris
Administrator
I want to backport some fixes from 2.0 into 1.4. What's the best way to do that?

Also, it seems to me that, given our new development process, all bugs should be tagged for both 1.4 and 2.0 unless they specifically don't apply to 1.4...

Thanks,
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Stéphane Ducasse

On Jun 7, 2012, at 6:11 AM, Sean P. DeNigris wrote:

> I want to backport some fixes from 2.0 into 1.4. What's the best way to do
> that?
>
> Also, it seems to me that, given our new development process, all bugs
> should be tagged for both 1.4 and 2.0 unless they specifically don't apply
> to 1.4…

no new bugs tagged 1.4 are important ones for the incremental release.
We will not maintain two versions in parallel. Just **important** = show stopper fixes.

>
> Thanks,
> Sean
>
> --
> View this message in context: http://forum.world.st/Backporting-fixes-tp4633625.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Marcus Denker-4

On Jun 7, 2012, at 9:03 AM, Stéphane Ducasse wrote:

>
> On Jun 7, 2012, at 6:11 AM, Sean P. DeNigris wrote:
>
>> I want to backport some fixes from 2.0 into 1.4. What's the best way to do
>> that?
>>
>> Also, it seems to me that, given our new development process, all bugs
>> should be tagged for both 1.4 and 2.0 unless they specifically don't apply
>> to 1.4…
>
> no new bugs tagged 1.4 are important ones for the incremental release.
> We will not maintain two versions in parallel. Just **important** = show stopper fixes.

Especially as one Person's enhancement is the other persons bug... any large change
will have side effects, so we should really limit us a bit.

        -> No new features.
        -> No cleanups
        -> If a bug was there in Pharo 1.1 already and we lived with it for years, fixing it in
             the current dev version is (in many cases) enough.
             (There are exceptions, but is does not happen often).
        -> Community input is important. A ready-to-include fix with a description that it
             was tested and a note that it for sure works will not be ignored.
             For an entry that is nearly finished yet nobody even cares to test it, why bother?

The best thing is to just do it. The list is here:

http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.4

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Stéphane Ducasse
+ 1
Marcus can you add it to the pharo-project web site.

>>
>> no new bugs tagged 1.4 are important ones for the incremental release.
>> We will not maintain two versions in parallel. Just **important** = show stopper fixes.
>
> Especially as one Person's enhancement is the other persons bug... any large change
> will have side effects, so we should really limit us a bit.
>
> -> No new features.
> -> No cleanups
> -> If a bug was there in Pharo 1.1 already and we lived with it for years, fixing it in
>             the current dev version is (in many cases) enough.
>             (There are exceptions, but is does not happen often).
> -> Community input is important. A ready-to-include fix with a description that it
>             was tested and a note that it for sure works will not be ignored.
>             For an entry that is nearly finished yet nobody even cares to test it, why bother?
>
> The best thing is to just do it. The list is here:
>
> http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.4
>
> Marcus
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Helene Bilbo
In reply to this post by Sean P. DeNigris
Sean P. DeNigris wrote
I want to backport some fixes from 2.0 into 1.4. What's the best way to do that?

Also, it seems to me that, given our new development process, all bugs should be tagged for both 1.4 and 2.0 unless they specifically don't apply to 1.4...
I would appreciate this _very_ much.

What does it take to do this? I often file in bug-fixes from the issue-tracker, test it for my own projects, run the available tests - but of course i often do not understand why a fix works, or if it is well made.

For example the most horrible 1.4 shortcoming, the SLOW FileList works perfektly well with the fix proposed here: http://code.google.com/p/pharo/issues/detail?id=5880
All tests for FileSystem run still well with this fix and there is a big speedup.
I would really appreciate this in 1.4. Currently the FileList is unusable.

Best regards, Helene.
Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Marcus Denker-4

On Jun 7, 2012, at 11:07 AM, Helene Bilbo wrote:

>
> Sean P. DeNigris wrote
>>
>> I want to backport some fixes from 2.0 into 1.4. What's the best way to do
>> that?
>>
>> Also, it seems to me that, given our new development process, all bugs
>> should be tagged for both 1.4 and 2.0 unless they specifically don't apply
>> to 1.4...
>>
>
> I would appreciate this _very_ much.
>
> What does it take to do this? I often file in bug-fixes from the
> issue-tracker, test it for my own projects, run the available tests - but of
> course i often do not understand why a fix works, or if it is well made.


If you do that, can you add a note to the bug tracker that you did it?
takes 2 seconds.

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Marcus Denker-4

On Jun 7, 2012, at 11:10 AM, Marcus Denker wrote:

>
> On Jun 7, 2012, at 11:07 AM, Helene Bilbo wrote:
>
>>
>> Sean P. DeNigris wrote
>>>
>>> I want to backport some fixes from 2.0 into 1.4. What's the best way to do
>>> that?
>>>
>>> Also, it seems to me that, given our new development process, all bugs
>>> should be tagged for both 1.4 and 2.0 unless they specifically don't apply
>>> to 1.4...
>>>
>>
>> I would appreciate this _very_ much.
>>
>> What does it take to do this? I often file in bug-fixes from the
>> issue-tracker, test it for my own projects, run the available tests - but of
>> course i often do not understand why a fix works, or if it is well made.
>
>
> If you do that, can you add a note to the bug tracker that you did it?
> takes 2 seconds.

In general, I think there is a miss-conception of how things are done.

The secret is: Things are done because they are done.

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Helene Bilbo
Marcus Denker-4 wrote
On Jun 7, 2012, at 11:10 AM, Marcus Denker wrote:

>
> On Jun 7, 2012, at 11:07 AM, Helene Bilbo wrote:
>
>>
>> Sean P. DeNigris wrote
>>>
>>> I want to backport some fixes from 2.0 into 1.4. What's the best way to do
>>> that?
>>>
>>> Also, it seems to me that, given our new development process, all bugs
>>> should be tagged for both 1.4 and 2.0 unless they specifically don't apply
>>> to 1.4...

>> What does it take to do this? I often file in bug-fixes from the
>> issue-tracker, test it for my own projects, run the available tests - but of
>> course i often do not understand why a fix works, or if it is well made.
>
>
> If you do that, can you add a note to the bug tracker that you did it?
> takes 2 seconds.

In general, I think there is a miss-conception of how things are done.

The secret is: Things are done because they are done.

        Marcus
Well, of course.
My question (and Sean’s i think) were more of the kind: „explain us how things are done", and not "please do this for me“. So if it is of any value if i load a fix in a fresh 1.4 image and run tests - but as in the FileList case do not really understand what is going on - is of any help, i will gladly do it.
Helene.
Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Stéphane Ducasse
>> The secret is: Things are done because they are done.
>>
>> Marcus
>>
> My question (and Sean’s i think) were more of the kind: „explain us how
> things are done", and not "please do this for me“.

Really simple:
        - we go to the issue list
        - try to load the code
        - read the code
        - check if there is a test
        - check that all the tests are working (or that new ones are not broken
So any input is important.


> So if it is of any value
> if i load a fix in a fresh 1.4 image and run tests - but as in the FileList
> case do not really understand what is going on - is of any help, i will
> gladly do it.



Stef
Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Sean P. DeNigris
Administrator
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote
no new bugs tagged 1.4 are important ones for the incremental release.
I'm not talking about bugs /tagged/ 1.4, but bugs /in/ 1.4. I'm seeing bug in the bug tracker that effect 1.4 and 2.0 that are tagged 2.0 by reflex and no one gets a chance to consider whether they should be also fixed in 1.4.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Ben Coman
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:

> + 1
> Marcus can you add it to the pharo-project web site.
>
>  
>>> no new bugs tagged 1.4 are important ones for the incremental release.
>>> We will not maintain two versions in parallel. Just **important** = show stopper fixes.
>>>      
>> Especially as one Person's enhancement is the other persons bug... any large change
>> will have side effects, so we should really limit us a bit.
>>
>> -> No new features.
>> -> No cleanups
>> -> If a bug was there in Pharo 1.1 already and we lived with it for years, fixing it in
>>             the current dev version is (in many cases) enough.
>>             (There are exceptions, but is does not happen often).
>> -> Community input is important. A ready-to-include fix with a description that it
>>             was tested and a note that it for sure works will not be ignored.
>>             For an entry that is nearly finished yet nobody even cares to test it, why bother?
>>    
Just a random idea... that perhaps the issue tracker tags and templates
could be updated to advise of this philosophy.
* Remove template "Pharo 1.4 Enhancement".
* Template "Pharo 1.4 Bug" currently has an empty description.  Include
Steph's description above - particularly the bit about recording which
Pharo version a fix has been tested on..  The template label might be
changed from "Milestone-1.4" to "Maintenance-1.4" - since that milestone
has already passed.

cheers, Ben

>> The best thing is to just do it. The list is here:
>>
>> http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.4
>>
>> Marcus
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
>>    
>
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Sean P. DeNigris
Administrator
In reply to this post by Marcus Denker-4
Marcus Denker-4 wrote
so we should really limit us a bit.
...
Absolutely, that list is very reasonable. I'm thinking specifically of annoyances introduced in the last version or two (e.g. in 1.3 the "DebugIt" shortcut is broken, and was working in 1.2). These are contained and frustrating, but may not be showstoppers in the way that I think of that word.

I think this is a really important topic because we don't want to give our users, esp. new and business ones, the feeling that they are immediately unsupported on release. That's why I was especially excited about the new release policy which specifies two bug fix releases to the currently released version over the first year.

Marcus Denker-4 wrote
The best thing is to just do it.
Let me be more specific. What I meant by "how", is technically what do I do with a slice from 2.0 in 1.4? For example, let's say SLICE-Issue-5871-FileReferencegtgtrenameTo-should-assume-same-folder-SeanDeNigris.1 gets integrated into 2.0. Several versions have passed in both contained MC packages from 1.4. In this case, I looked at all the changes and they're comment fixes and other benign items, but... if there were also incompatible changes, how would I get just the relevant ones into 1.4.

I'm looking for some code /like/ this - given FileSystem-Core-SeanDeNigris.12, either merge or make a changeset of just the changes between it and its immediate ancestor (i.e. just the fix).

Cheers,
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Marcus Denker-4

On Jun 7, 2012, at 3:06 PM, Sean P. DeNigris wrote:

>
> Marcus Denker-4 wrote
>>
>> so we should really limit us a bit.
>> ...
>>
> Absolutely, that list is very reasonable. I'm thinking specifically of
> annoyances introduced in the last version or two (e.g. in 1.3 the "DebugIt"
> shortcut is broken, and was working in 1.2). These are contained and
> frustrating, but may not be showstoppers in the way that I think of that
> word.
>
Is there a fix?

> I think this is a really important topic because we don't want to give our
> users, esp. new and business ones, the feeling that they are immediately
> unsupported on release. That's why I was especially excited about the new
> release policy which specifies two bug fix releases to the currently
> released version over the first year.
>
>
Yes, but bug fix releases don't make the actual fixes happen automatically.

> Marcus Denker-4 wrote
>>
>> The best thing is to just do it.
>>
> Let me be more specific. What I meant by "how", is technically what do I do
> with a slice from 2.0 in 1.4? For example, let's say
> SLICE-Issue-5871-FileReferencegtgtrenameTo-should-assume-same-folder-SeanDeNigris.1
> gets integrated into 2.0. Several versions have passed in both contained MC
> packages from 1.4. In this case, I looked at all the changes and they're
> comment fixes and other benign items, but... if there were also incompatible
> changes, how would I get just the relevant ones into 1.4.
>
> I'm looking for some code /like/ this - given
> FileSystem-Core-SeanDeNigris.12, either merge or make a changeset of just
> the changes between it and its immediate ancestor (i.e. just the fix).
>
You ask the author to re-do the fix in 1.4. Yes, this is a lot of work. That is why
it just can't be done with everything.

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Igor Stasenko
In reply to this post by Helene Bilbo
On 7 June 2012 13:37, Helene Bilbo <[hidden email]> wrote:

>
> Marcus Denker-4 wrote
>>
>> On Jun 7, 2012, at 11:10 AM, Marcus Denker wrote:
>>
>>>
>>> On Jun 7, 2012, at 11:07 AM, Helene Bilbo wrote:
>>>
>>>>
>>>> Sean P. DeNigris wrote
>>>>>
>>>>> I want to backport some fixes from 2.0 into 1.4. What's the best way to
>>>>> do
>>>>> that?
>>>>>
>>>>> Also, it seems to me that, given our new development process, all bugs
>>>>> should be tagged for both 1.4 and 2.0 unless they specifically don't
>>>>> apply
>>>>> to 1.4...
>>
>>>> What does it take to do this? I often file in bug-fixes from the
>>>> issue-tracker, test it for my own projects, run the available tests -
>>>> but of
>>>> course i often do not understand why a fix works, or if it is well made.
>>>
>>>
>>> If you do that, can you add a note to the bug tracker that you did it?
>>> takes 2 seconds.
>>
>> In general, I think there is a miss-conception of how things are done.
>>
>> The secret is: Things are done because they are done.
>>
>>       Marcus
>>
>>
>
> Well, of course.
> My question (and Sean’s i think) were more of the kind: „explain us how
> things are done", and not "please do this for me“. So if it is of any value
> if i load a fix in a fresh 1.4 image and run tests - but as in the FileList
> case do not really understand what is going on - is of any help, i will
> gladly do it.
> Helene.
>

Helene, don't think that confirming that it works (or not) don't have a value.
It has HUGE HUGE HUGE HUGE HUGE HUGE value.
Actually it is one of the most important things: i tend to have lack
of confidence in changes i make,
and i don't want to rush them into image unless someone will take a
look at them or confirm it works for them. And many others doing the
same. Review is very important to assure quality of changes.

And you'll do a lot of contribution by simply loading the code and
test if it works.
And sure thing it would be better if you could understand the nature of changes
but it is impossible since there are too many changes in too many areas,
so we must put a trust to people who did the fix, and most probably
know better than you (or pretends to have ;)

> --
> View this message in context: http://forum.world.st/Backporting-fixes-tp4633625p4633670.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Backporting fixes

Sean P. DeNigris
Administrator
In reply to this post by Marcus Denker-4
Marcus Denker-4 wrote
Yes, but bug fix releases don't make the actual fixes happen automatically.
...
You ask the author to re-do the fix in 1.4. Yes, this is a lot of work. That is why
it just can't be done with everything.
Arg... The intention of my original question was obviously not clear. Let me start over. I'm sitting in front of the bug tracker with some time. I want to re-do some 2.0 fixes in 1.4. What's the best/easiest way?

Thanks,
Sean
Cheers,
Sean