2009/10/13 Stéphane Ducasse <stephane.duca...@inria.fr>: > 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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
