- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Backporting fixes

by 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 > >

June 7, 2012

Re: [Pharo-project] Backporting fixes

by Marcus Denker

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

June 7, 2012

Re: [Pharo-project] Backporting fixes

by 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. >

June 7, 2012

Re: [Pharo-project] Fuel

by StÃ©phane Ducasse

yes this is a fun rule. Now you have to have a common ancestor or a package entry point. Stef On Jun 6, 2012, at 11:55 PM, Igor Stasenko wrote: > Yeah.. > > we even can make a lint rule: > - 1 max reference per package to class from another package > unless referencing class belongs to kernel > > > modules.. they are so easy to do, if everyone would follow that rule :) > > On 6 June 2012 22:54, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Steph wants less hardcoded references to PackageInfo :) >> >> >> On Wed, Jun 6, 2012 at 10:51 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> Hmm I didn't catch it >>> >>> Martin >>> >>> On Wed, Jun 6, 2012 at 4:47 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> ok for me >>>> I'm studying PackageInfo and the rest to see what I can do. >>>> >>>>> mariano/martin >>>>> >>>>> I would like to extract PakageInfo into self packageInfo in the >>>>> fuel code. >>>>> >>>>> Yes, I like that the idea. I guess you are talking about >>>>> FuelPackageLoader in #named: and #withPacakges: right? >>>>> What about calling it direclty #package? so that we may be able to >>>>> change it later to PackageInfo or RPackage or whatever? >>>>> >>>>> >>>>> Can I do it? >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

June 7, 2012

[Pharo-project] Backporting fixes

by Sean P. DeNigris

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.

June 7, 2012

Re: [Pharo-project] Something does not work with issue tracker status

by Igor Stasenko

On 6 June 2012 23:40, Camillo Bruni <camillobruni(a)gmail.com> wrote: > we should first get the test monkey up and running... > that will take a lot of work an assures that at least the existing tests won't fail! yes. and second thing, even if we integrate half-backed solution, we can always fix it on next iteration, if it causing problems.. like that it will be some progress comparing to indefinite time when issue needs to be reviewed. but sure thing, for changes which can really screw things up, we need serious review before integration. -- Best regards, Igor Stasenko.

June 7, 2012

[Pharo-project] Pharo-1.4-Tests Â» 32,win - Build # 61 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 6, 2012

Re: [Pharo-project] FilePlugin changed it's behavior?

by Igor Stasenko

On 6 June 2012 21:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> is not failing as it says it should in the comment. >> >> Has this behavior changed lately? Â Should this be fixed in the vm side, wait for NativeBoost? Or we should just by now fix the comment and clients not to expect that? > > I think that we should put all our eggs in the same basket :) so the non native boost version should work too. Sorry for confusion.. the thing we did with NB was just a mere experiment.. File plugin should work without NB or with it.. out of the question. >> some pointer? -- Best regards, Igor Stasenko.

June 6, 2012

Re: [Pharo-project] Fuel

by Igor Stasenko

Yeah.. we even can make a lint rule: - 1 max reference per package to class from another package unless referencing class belongs to kernel modules.. they are so easy to do, if everyone would follow that rule :) On 6 June 2012 22:54, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Steph wants less hardcoded references to PackageInfo :) > > > On Wed, Jun 6, 2012 at 10:51 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hmm I didn't catch it >> >> Martin >> >> On Wed, Jun 6, 2012 at 4:47 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> > ok for me >> > I'm studying PackageInfo and the rest to see what I can do. >> > >> >> mariano/martin >> >> >> >> Â Â Â Â I would like to extract PakageInfo into self packageInfo in the >> >> fuel code. >> >> >> >> Yes, I like that the idea. I guess you are talking about >> >> FuelPackageLoader in #named: and #withPacakges: right? >> >> What about calling it direclty #package? Â so that we may be able to >> >> change it later to PackageInfo or RPackage or whatever? >> >> >> >> >> >> Can I do it? >> >> >> >> Stef >> >> >> >> >> >> >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> > >> > >> > -- Best regards, Igor Stasenko.

June 6, 2012

Re: [Pharo-project] Something does not work with issue tracker status

by Camillo Bruni

we should first get the test monkey up and running... that will take a lot of work an assures that at least the existing tests won't fail!

June 6, 2012