- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Small mini howto on moving a project to SmalltalkHub

by Igor Stasenko

On 19 December 2012 23:16, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > abergel wrote >> No no. This can not work > > Can you please provide the rationale behind that statement? :) > Because then a single person seen as a responsible for the whole project, which is not correct model for team-driven development. Projects, which developed by teams, deserve having own canonical repository, while it developers are free to commit into own local copy before committing to 'official' repo. > DISCLAIMER: Since I'm not actively participating in any alternative, I will > happily receive whatever gets done. > > Regards! > -- Best regards, Igor Stasenko.

Dec. 20, 2012

Re: [Pharo-project] Small mini howto on moving a project to SmalltalkHub

by StÃ©phane Ducasse

We spent a lot of time with nicolas talking about it. So let us focus on something else :) Stef On Dec 19, 2012, at 11:16 PM, Esteban A. Maringolo wrote: > abergel wrote >> No no. This can not work > > Can you please provide the rationale behind that statement? :) > > DISCLAIMER: Since I'm not actively participating in any alternative, I will > happily receive whatever gets done. > > Regards! > > > > -- > View this message in context: http://forum.world.st/Feature-requests-and-a-tip-for-SmalltalkHub-tp4659760… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 20, 2012

[Pharo-project] wrong ci download scripts

by Pavel Krivanek

Hi, the Pharo 2.0 job is broken because the new script name contains uppercase typo: ciNBCOgVM.sh -- Pavel

Dec. 20, 2012

Re: [Pharo-project] [Issue Tracker] issues tagged 2.0

by Marcus Denker

130 to goâ¦ (down from nearly 170 yesterday). On Dec 19, 2012, at 1:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D2.0&colspec=… > > We need to look at each one and decide > -> is this a show stopper for releasing 2.0? > - Hint: a bug that was already in 1.4 is *not* > - A "nice to have" improvement is not, either. > - Same for cleanups. > > Marcus

Dec. 20, 2012

[Pharo-project] [update 2.0] #20444

by Marcus Denker

20444 ----- Issue 7154: Better tab naming in config browser http://code.google.com/p/pharo/issues/detail?id=7154 Issue 7153: DNU on a deprecated String progress display method http://code.google.com/p/pharo/issues/detail?id=7153 Issue 7152: DNU when searching a Change Set in Change Sorter http://code.google.com/p/pharo/issues/detail?id=7152 Issue 7145: simplify MethodContext>>#tempNamed: http://code.google.com/p/pharo/issues/detail?id=7145 Diff information: http://ss3.gemstone.com/ss/Pharo20/UIManager-MarcusDenker.93.diff http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1003.diff http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-MarcusDenker.73.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1272.diff

Dec. 20, 2012

[Pharo-project] Configuration Browser tab naming

by Torsten Bergmann

>I thought the distinction you wanted to make was >identifying which Configurations the Inria Pharo Team took direct >responsibility for supporting, which I thought was a reasonable >distinction and I would find useful. No - I justed wanted to have all the Configs that worked in a specific Pharo version easily accessible to new user right from a menu. The ideas is simple: If someone downloads Pharo he usually does not know magic Gofer/Metacello scripts. He also did'nt follow the mailinglist for years to know about all the nice things that are available in Pharo world and on so many different servers (SqS, SS3, SmalltalkHub, ...) On the other side ACCESSIBILITY of packages and informations is CRUCIAL for ADOPTION. Otherwise people turn away after a short look. Thats why I created the Pharo help browser, the config browser and now work on an Pharo online help (which is alpha but accessible from the config browser already). And I'm not Inria ;) >So anyone (having done the necessary validation for 2.0) can copy into >the MetaRepoForPharo20 ? Yes - for now we do it manually. In the future I would like to see a mechanism that loads the config for a specific Pharo version and validates by running all the tests. If broken the author/community can be informed. If OK it should appear in the config browser... Bye T.

Dec. 20, 2012

Re: [Pharo-project] Configuration Browser tab naming

by Ben Coman

Torsten Bergmann wrote: > I think the naming is more related to historic > development: my original implementation just had one tab > named "Configurations". > > Esteban later added "Untrusted" since these are the ones > that are not (yet) tested in the according Pharo version. > It's a nice addition since it makes them easily accessible > as well. > > However I now changed the tab names to "Core" and "Community" > in > > http://code.google.com/p/pharo/issues/detail?id=7154 > > > Reminder: > ========= > It is still required that people try out the "Community" > ones and if they are working fine in Pharo 2.0 copy them to > > http://ss3.gemstone.com/ss/MetaRepoForPharo20 > > so they appear in "Core" > > So anyone (having done the necessary validation for 2.0) can copy into the MetaRepoForPharo20 ? I had misunderstood. I thought the distinction you wanted to make was identifying which Configurations the Inria Pharo Team took direct responsibility for supporting, which I thought was a reasonable distinction and I would find useful. If the idea was to gather all Configurations that worked in Pharo 1.4 to make it easier to jumpstart testing them in 2.0, then I was incorrect to suggest renaming that to "Community". I was thinking a "Community" tab would be packages validated for 2.0 but those outside the Core Pharo Team. Rethinking this, perhaps having a "Consortium" tab would be useful. This would be an additional benefit for members to populate, giving a higher profile for any of the packages they provide or the products depend on. The side benefit for members is that wider usage of the packages they depend on means more eyeballs and hands improving those packages. The benefit for me as an end user would be a list of packages that are likely used somewhere in a real customer facing product with attendant professional level of care and maintenance by others. Along the same lines there might be an "Association" tab for members of the PUA to use. The benefit to me as an end-user is seeing which packages are liked/supported by those with a higher level of commitment to Pharo. This doesn't necessarily need the main developer to be a member, just that a member finds it of use to themselves. To avoid needing to manage multiple MetaRepoForXXXX on squeaksource server side, perhaps the Configuration Browser can pull a status file from the PC & PUA websites. On the websites members could see a list of Configurations in the MetaRepoForPharo20 and "Like" the ones they want. ConfigurationBrowser could continue to pull the Configurations from just one location, and the categorization done on the basis of these status files. A "Backward Compatibility" tab might be useful to segregate out things like ConfigurationOfFileDirectory, clearing identifying it as deprecated so as not to confuse newcomers, and also provide a jumpstart for anyone wanting to port old pre-Pharo code to Pharo. "Consortium" might be inclusive of "Core" to avoid having too many tabs, and also since maybe many Consortium projects might be private/commercial and this list might remain lightly populated. anyway, just random thoughts bubbling over, cheers -ben

Dec. 20, 2012

Re: [Pharo-project] Small mini howto on moving a project to SmalltalkHub

by Esteban A. Maringolo

abergel wrote > No no. This can not work Can you please provide the rationale behind that statement? :) DISCLAIMER: Since I'm not actively participating in any alternative, I will happily receive whatever gets done. Regards! -- View this message in context: http://forum.world.st/Feature-requests-and-a-tip-for-SmalltalkHub-tp4659760… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 19, 2012

Re: [Pharo-project] Small mini howto on moving a project to SmalltalkHub

by Alexandre Bergel

Thanks to all of you for your answers. It is clearer to me now Alexandre Le 19 dÃ©c. 2012 Ã 12:31, GÃ¶ran Krampe <goran(a)krampe.se> a Ã©crit : > Hey! > > On 12/19/2012 11:10 AM, Alexandre Bergel wrote: >> By the way, is there a way to see what are the projects that are on SmalltalkHub? > > If you read Nicolas answer in this thread before I changed the subject line, then you will see that no, currently one can't, but yes, of course we should and Nicolas is hacking on it :) > >> It is still not clear to me what are the benefits to use SmalltalkHub. > > As I see it: > > - Fully open source. It uses MongoDB at the bottom, not Gemstone. > > - Fast. The architecture with Amber + a RESTful backend + Mongo should make it very responsive and fast. > > - Modern look and feel and githubish features (watchers for example). > >> The problem with squeaksource.com is clearly identified: it is highly unstable. However ss3.gemstone.com looks reasonable. I can browse the project, version of it, see the list of active projects. It seems that SmalltalkHub does not show this? > > I would chalk up anything that is "missing" as simply "still missing". But we should simply add the features we need. > >> Talking about wished feature, it would be nice to see from which countries/cities download and contribution are made... >> >> I really hope to not start a long discussion. This is not my objective :-) > > As a side note - I love OODBs and I love multitransactional super large persistent shared memory (Gemstone) :) but I still think SS3 seems very sluggish in some ways. Yesterday I was searching the projects for "XMLSupport" - it is of course at the far end of the alphabet ;) - and I repeatedly didn't even get an answer... > > So I suspect SS3 is in some ways very naively built (which of course is the beauty of Gemstone in many ways, that one can just build it as if it was all in the image). > > From Smalltalkhub I *expect* excellent speed because IMHO a modern app with such modern tools should simply be very fast. > > regards, GÃ¶ran >

Dec. 19, 2012

Re: [Pharo-project] Small mini howto on moving a project to SmalltalkHub

by Alexandre Bergel

No no. This can not work Alexandre Le 19 dÃ©c. 2012 Ã 21:03, "Esteban A. Maringolo" <emaringolo(a)gmail.com> a Ã©crit : > Why not ~ducasse/Pharo? (~user/project) > > It promotes a culture of projects forking and pull requests to integrate > changes back. Isn't that a way to avoid the stagnation of projects? > > Regards! > > > > > > > -- > View this message in context: http://forum.world.st/Feature-requests-and-a-tip-for-SmalltalkHub-tp4659760… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 19, 2012