[Pharo-project] Backporting fixes
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 -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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.
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
+ 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
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 >> >> >> > > > >
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 -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625p4633694.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
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 -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625p4633704.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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. -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625p4633681.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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. -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625p4633647.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
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
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. -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625p4633670.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
On 7 June 2012 13:37, Helene Bilbo <thereluctantprogrammer@fastmail.fm> 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.
participants (6)
-
Ben Coman -
Helene Bilbo -
Igor Stasenko -
Marcus Denker -
Sean P. DeNigris -
Stéphane Ducasse