On 27 Nov 2014, at 15:53, phil@highoctane.be wrote:
On Thu, Nov 27, 2014 at 3:37 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 27 Nov 2014, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
At times, mczs still come handy for some merges...
And Smalltalkhub is good as a safe heaven for collecting packages that are otherwise scattered all around.
nothing that a real catalog/centralised package manager alla npm/apt-get/etc cannot do it. using a package manager as a catalog feels to me like hammering a screw.
Sure, I am with you on that. I am yum - ing all day long :-)
But as you know, the Pharo Catalog descriptions are quite lonely. I'd like to take a moment to tackle that one.
In fact, there are several concerns that I find (and other members on the list share the feeling) must be addressed for commercial development.
e.g.: Stronger RDBMS support, AAA, Logs, ...
But this not really Pharo per se, but a onion ring around it. As you guys are doing 4.0, that onion ring is making 3.0 work for commercial stuff. I think that we'll always be one version behind, which is ok.
Is there a reason why Smalltalkhub would not stay working nicely?
because we do not have the strength/willing to maintain it. and each day we are: farther from âstate of the artâ source management, and farther from state of the art javascript, etc. (which is the reason why sthub
Ok, thx.
Are we talking about using bigger boxes here? Or is it a deeper issue?
keeping up-to-date a system like sthub is a lot of work, and takes a lot of time. personally, I prefer way more to spend my time in things that will have a real impact in the community (like having a modern vm) than lose it trying constantly to catch up with what others (with a lot more resources) already did.
Sure, modern vm anytime! The git worklflow is superpowerful and that's what people use these days. In a MOOC I do, all exercises and slideware are in Github...
each time I start a sub-project, my first question is: âthis stuff will have a multiplier effect in the community?â and second question is âdo we have to doit from scratch, or can we take advantage of other projects?â. As a maintainer, and being conscious of our limitations, this are the driving forces I find positive to work. (and of course, most times I do not start sub-projects at all, I just jump into a burning place and try to do my best to fix it⦠not always very successfully :P)
Nah, you rule. I wish I was as good as you are.
so, coming back to less âphilosophicalâ question:
1) do we need a state-of-the-art source code management? YES. 2) do we want to spend the few manpower we have on running into a worst solution of what is already around? I think no.
libgit2 would provide that without going through Github driver hoops, which is sweet and more welcoming to newcomers.
and exactly there is where I will put my effort (as soon as I have time) :) In the long way, Iâm quite sure is a lot more important for community than patching sthub. btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
Esteban
Phil
On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently .
If you are user of emacs there is magit , really powerful gui client and very popular among emacs users.
For gui client I have used quite a lot SmartGit
http://www.syntevo.com/smartgit/ <http://www.syntevo.com/smartgit/>
and recently a fellow python developer introduced me to Sourcetree
http://www.sourcetreeapp.com/ <http://www.sourcetreeapp.com/>
Both are free for non commercial projects. They require a license for commercial use but they are relative cheap. They come with diff tools, easy commit access , branching, merging and tons of stuff to make life easier for complex scenarios and they integrate well with bitbucket and other online repositories besides github.
But even from command line there is a lot of room for automation by creating bash scripts to make commits one step process.