Preparing the sprint
Locked
12
12
 
|
Adrian, sorry i did not read your mail carefully ;-)
no we don't have an issue on the tracker yet. whilst it is an external package I think it is important enough we maintain compatibility. Is it reasonable for us to track on our tracker? I would say so, but in the past sometimes i think we have closed issues for not being pharo directly. cheers Mike _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On 12 Oct 2009, at 22:08, Lukas Renggli wrote: >> If you can post the code and maybe some comments on how to use it, >> that would be great. Maybe we can do some testing and investigation >> into the problem during the sprint. >> >> Do we have an issue for the OSProcess problem or has it been >> discussed >> before? >> >> We'll discuss where to host this server. We have several options >> there. > > We are using Mason from <http://source.wiresong.ca/mc> to build > Seaside images. We don't have a server setup yet, but it also works > locally. > > Mason is a very flexible system, it has infrastructure to build > images, build SAR archives, build documentation, load Monticello 1 and > 2 packages, load Metacello configurations, run tests, run code critics > and execute arbitrary scripts, etc. The OB and MC2 distributions are > built using Mason for example: > <http://www.wiresong.ca/static/releases/>. > > Lukas > Absolutely incredible. Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Michael Roberts-2
I think it makes sense to open a ticket in our tracker, yes.
Especially since OSProcess is an important package for us. Adrian On Oct 12, 2009, at 23:19 , Michael Roberts wrote: > Adrian, sorry i did not read your mail carefully ;-) > > no we don't have an issue on the tracker yet. whilst it is an external > package I think it is important enough we maintain compatibility. Is > it reasonable for us to track on our tracker? I would say so, but in > the past sometimes i think we have closed issues for not being pharo > directly. > > cheers Mike > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by keith1y
On 12 Oct 2009, at 22:28, keith wrote: > > On 12 Oct 2009, at 22:08, Lukas Renggli wrote: > >>> If you can post the code and maybe some comments on how to use it, >>> that would be great. Maybe we can do some testing and investigation >>> into the problem during the sprint. >>> >>> Do we have an issue for the OSProcess problem or has it been >>> discussed >>> before? >>> >>> We'll discuss where to host this server. We have several options >>> there. >> >> We are using Mason from <http://source.wiresong.ca/mc> to build >> Seaside images. We don't have a server setup yet, but it also works >> locally. >> >> Mason is a very flexible system, it has infrastructure to build >> images, build SAR archives, build documentation, load Monticello 1 >> and >> 2 packages, load Metacello configurations, run tests, run code >> critics >> and execute arbitrary scripts, etc. The OB and MC2 distributions are >> built using Mason for example: >> <http://www.wiresong.ca/static/releases/>. >> >> Lukas >> > > Absolutely incredible. > > Keith translated = "oh look its Sake" Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Adrian Lienhard
http://code.google.com/p/pharo/issues/detail?id=1299
Mike _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by keith1y
How long the community will support the deliberate decision of not
answering to a major contributor? How do you expect contribution of large open source companies to this project avoiding political or technical conflicts (or both)? Focusing only on bug-driven development and ingoring valid questions with a kind of systematic corporative silence is not the way to go. And if the managerial staff decide to continue ignoring, sooner or later you would have two problems to resolve: The unsolved pending questions plus the management of the emergence of social subsystems (if the number of contributors increases) without enough coordinators for pivots, because of the limited size of contributors for a niche technology like Smalltalk. Censorship of uninformed newcomers is common and an implicit norm, censorship of a known member is disgusting. Such attitude is limiting involvement and participation in the community, because implicitly define clear roles which affects the discussion space and group dynamics. Finally, I do not want a holy war here, I just want responses without personal attacks and without quoting out of context fallacies. Cheers, Hernán 2009/10/12 keith <[hidden email]>: > > On 12 Oct 2009, at 17:45, Stéphane Ducasse wrote: > >> Mike is it related to the testServer publihsed on squeaksource? >> Because ESUG will also sponsor a summer talk project on the topics. >> So if we could join forces it would be great. >> >> For the server this is not clear yet. Internally we have our server >> that we could use but >> we have to check the security. >> >> I'm waiting that marcus arrives to check that with him and damien. >> >> Stef > > Why why why why why is compete more attractive than contributing. > > Let me explain.... > > Step 1. We would like a test server. > Step 2. Is anyone working on this already? > Step 3. Would anyone like to collaborate to specify and work on a test > server? > > Bob is already written it just needs configuring, TestReporter is > already written, > and has been available for 3 years or more. > > The same thing is happening again and again and again. > > Why did anyone even start working on Metacello when Sake/Packages was > already there a year before hand. > > Why are the steps above not the default way of working for the > community? It is beyond incredulity. > > Keith > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Dale
On 12 Oct 2009, at 22:04, Dale Henrichs wrote:
Not much of a team player this dude then. How about this one... And so, my fellow Smalltalkers: ask not what your community can do for you - ask what you can do for your community. My fellow coders of the world: ask not what Pharo will do for you, but what together we can do for the freedom of man etc etc etc Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hernanmd
Hernan
> > How long the community will support the deliberate decision of not > answering to a major contributor? > How do you expect contribution of large open source companies to this > project avoiding political or technical conflicts (or both)? this is not that we do not reply. This is that keith is always saying the same. Now I do not have to power to say to people not to develop their own stuff and also people have the freedom not to understand - sake - now you can ask jannik for example: we started to write something on installer and sake but we got confused on sake (may be with a physical meeting at esug this would make a lot of point clearer) - not to like some part of the installer - not to contribute - not have the time to understand something - prefer to build thier own even if this is limited - For example I tried to check the SUnitextensions and I could not find them. Did you see me not integrating something in Pharo Did you see me not mentioning rio? Even if they are some points I do not like. > > > Focusing only on bug-driven development and ingoring valid questions > with a kind of systematic corporative silence is not the way to go. > And if the managerial staff decide to continue ignoring, sooner or > later you would have two problems to resolve: The unsolved pending > questions plus the management of the emergence of social subsystems > (if the number of contributors increases) without enough coordinators > for pivots, because of the limited size of contributors for a niche > technology like Smalltalk. > > Censorship of uninformed newcomers is common and an implicit norm, > censorship of a known member is disgusting. sorry hernan but I cannot let you say that in this mailing-list. Did we ever not reply to a newbie email? > Such attitude is limiting involvement and participation in the > community, because implicitly > define clear roles which affects the discussion space and group > dynamics. > > Finally, I do not want a holy war here, I just want responses without > personal attacks and without quoting out of context fallacies. Are my answer satisfactory? Now I have a question: - do you use sake personnally? - do you have positive experience? - did you check the code? what is your feedback? - is there tests? - what do you think about task definition pros and cons? You can replace Sake but RIO, Sunit extensions (if you find it) Please do it. So far in our group people succeeded to make TestServer running for Moose and if they come and tell me that sake is better/easier/ then we will probably switch Now I asked the summertalk student to also consider evaluating Sake and we will see. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/10/13 Stéphane Ducasse <[hidden email]>:
> Hernan > >> >> How long the community will support the deliberate decision of not >> answering to a major contributor? >> How do you expect contribution of large open source companies to this >> project avoiding political or technical conflicts (or both)? > > this is not that we do not reply. This is that keith is always saying > the same. > Now I do not have to power to say to people not to develop their own > stuff > and also people have the freedom not to understand > - sake > - now you can ask jannik for example: we started to write something > on installer and sake > but we got confused on sake (may be with a physical meeting at esug > this would make a lot of point clearer) > - not to like some part of the installer > - not to contribute > - not have the time to understand something > - prefer to build thier own even if this is limited > > - For example I tried to check the SUnitextensions and I could not > find them. > > Did you see me not integrating something in Pharo > Did you see me not mentioning rio? Even if they are some points I do > not like. Please, do not misunderstand me, you're doing a terrific job with Pharo. My concerns were more about the political stuff. >> >> >> Focusing only on bug-driven development and ingoring valid questions >> with a kind of systematic corporative silence is not the way to go. >> And if the managerial staff decide to continue ignoring, sooner or >> later you would have two problems to resolve: The unsolved pending >> questions plus the management of the emergence of social subsystems >> (if the number of contributors increases) without enough coordinators >> for pivots, because of the limited size of contributors for a niche >> technology like Smalltalk. >> >> Censorship of uninformed newcomers is common and an implicit norm, >> censorship of a known member is disgusting. > > sorry hernan but I cannot let you say that in this mailing-list. > Did we ever not reply to a newbie email? I expressed myself bad, that claim for newcomers is a general rule in other open source projects (not Pharo fortunately), when they enter a mailing list, they do not know the project's history and start "spamming" with already answered topics. > >> Such attitude is limiting involvement and participation in the >> community, because implicitly >> define clear roles which affects the discussion space and group >> dynamics. >> >> Finally, I do not want a holy war here, I just want responses without >> personal attacks and without quoting out of context fallacies. > > Are my answer satisfactory? > Now I have a question: > - do you use sake personnally? > - do you have positive experience? > - did you check the code? what is your feedback? > - is there tests? > - what do you think about task definition pros and cons? > > You can replace Sake but RIO, Sunit extensions (if you find it) > Please do it. We've used Monticello Configurations in our application. It was enough for our needs. However I've invested time in understanding the Installer/Sake/Packages triad (I have problems with the documentation). I've annotated this in my personal swiki for future use. In a more generic level and this is somewhat out of topic (sorry), I'm mostly a user of Pharo, but what I perceive is competition between some tools. Competition is good... sometimes. What I mean is: There are some developers which support innovation activities? Good. There are some developers which support stabilization over a robust development platform? Fantastic. What I suspect sometimes is a mixing of both scenarios, and from a consumption point of view it could be negative, because some people do not want to hear about alternatives at all, namely : Monticello, ChangeSets/ChangeSorter, CVSTProject (?), SqueakARchive, Installer, ScriptLoader, Sake, Universes, etc. And the relations and complex interactions between them. It is time consuming to study each source code management tool (plus the latest ones), and I know professional busy programmers which simply do not have the time to make a review, they don't want to invest in training. If the community could vote for a tool, I think that would clarify: -The preferred source code management tool (based on true production experience with Smalltalk). -The interest in having just one main tool for SCC (or at least the perception people have with CPAN or dpkg or rpm). -The interest in alternatives or additional functionality. -The previous experience with some other tools, this way you can see if there's a profile from users of CVS, etc. Well, yet another idea. Best regards, Hernán > > So far in our group people succeeded to make TestServer running for > Moose and > if they come and tell me that sake is better/easier/ then we will > probably switch > > Now I asked the summertalk student to also consider evaluating Sake > and we will see. > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
So you are the lead on pharo and you have never used universes? Sorry but using I cant find SUnitExtensions when the package is and has always been called "SUnit-improved" as an excuse is is totally ridiculous.
I have no idea what you mean by this question. This is all backwards. Your questions are all demonstrating the old pharo code snobbery which really isn't relevant to the argument at all. The whole point is to have a plan and a vision that people work towards so that we end up with a coherent solution that does what we and the community need. If something is not quite up to scratch then you/me/anyone can join in and contribute to bring it up to speed. Code snobs are welcome and helpful, if they contribute, rather than compete. Rejecting things just because its a few tests short is simply demonstrating a lack of interest in the overall concept. The repositories are open and have always been open for you to contribute to. Let me outline the basics of the plan... I cant say whether these things work in pharo or not. 0. Installer = for bootstrapping stuff anywhere including kernel minimal gui-less images. (gofer whatever that is, is not for kernel images, so you havent got anything to fulfill this role) If you were committed to not undermining the vision of "the DSM for installing things", you would develop gofer as InstallerGofer available via Installer gofer addPackage: 'PackageA'; latest; quietly; install. Then you would have the same functionality, but you would be contributing to the vision rather than setting up as competition from the outset. You would also have additional benefits such as tools for loading Gofer in all forks, see 0a below. 0a InstallerScripts for bootstrapping stuff with scripts that may differ in different forks. (ScriptLoader is a pharo only hack - so you haven't got anything to fulfil this role either) 1. Monticello, Monticello Configurations, and PackageInfo = the same in all forks, with all forks merged so that we can move MC forward with Atomic loading and binary loading. 2. SUnit - same in all forks, with categorisation of tests, tagging as to what works where. 3. LPF for bootstrapping and loading all of the above in all forks. 4. Sake (vision = minimal support for tasks with dependencies) It doesnt matter if you dont like a single bytecode of the sake code, the principle is "a package that gives the minimal support for make like task graphs". If you happen to be a make/rake expert, then enter the dialog and tell me what I am doing wrong, we could start again from scratch if you like, I don't care. But please DONT compete for the sake of it. 5. Sake/Packages (minimal gui-less package manager available in all forks) defining what works where. Again, if you don't like it, enter the dialog, and help, don't judge from afar. Sake/Packages may not be perfect, but it has done better than any other previous squeak dependency manager. The API is better than Metacello, and its easier to use, and more versatile. So, if you don't deliver something similar to this plan, AND deliver it in all forks with equivalent functionality, then whatever you do undermines this vison for everyone. This is exactly what has happened. The vision has been undermined to the point of being hounded out of existence. This email is the last death throe. Hence the reason that I have been speaking up, repeatedly, the vision is now pretty much completely undermined and almost gone, because it is unsustainable. It is unsustainable because the leaders in our community will not put any commitment to any visions other than their own, and those for the most part only exist in their own heads. (i.e. when you or andreas sit down to decide what bug to fix, or what you are going to refactor there is no published detailed plan you are working to) You apparently loaded MC1.5 once, (whereas I have been using it for 2 years) and decided that it left lots of loose ends, the reason was because you didnt unload the previous version of MC correctly. Your version of collaborating with people on a plan, is to poke around in squeaksource on your own, load a package that you think is the right one, and when it doesnt work, simply tell everyone that you couldnt find it. Perhaps you are still in the dark ages, when we didnt have irc or a package manager for squeak which understood dependencies. All you have to do in an LPF image is Installer install: 'Packages'. and you would be able to load SUnit-improved without a problem. We have had all of this stuff working for all of the time I have been trying to persuade you to use it. Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hernanmd
> > I expressed myself bad, that claim for newcomers is a general rule in > other open source projects (not Pharo fortunately), when they enter a > mailing list, they do not know the project's history and start > "spamming" with already answered topics. And that is exactly what killed off 3.11 Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |