On Thu, Nov 27, 2014 at 3:37 PM, Esteban Lorenzano <[email protected]>
wrote:

>
> On 27 Nov 2014, at 14:43, [email protected] 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.



> Esteban
>
>
> Phil
>
>
>
>
>
> On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <[email protected]>
> 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/
>>
>> and recently a fellow python developer introduced me to Sourcetree
>>
>> 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.
>>
>
>
>

Reply via email to