kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> Dick Hollenbeck wrote:
>> 
>>>>> But I just don't like the infrastructure of the project, I view a yahoo mailing list as a lousy way to keep track of concerns like this.
>>>>>
>>>>>
>>>>> We need better tools people. Especially if we are ever to successfully attract, retain, and organize more developers.
>>>>>
>>>>>
>>>>> Has everyone had the time to review some of the tools over at Launchpad? 
>>>>> 
>>>>> 
>>>> Dick,
>>>>
>>>> Sorry I took so long to post this but I've busy. I looked at the Launchpad tour and it looks promising. I haven't used any of these tools except Bazaar so I can't really speak to their effectiveness. I like the idea distributed version control but the last time I used Bazaar, it was slow even on a fairly modest size project that was less than one tenth the size of Kicad. I think it was around version 1.5 so things may have improved since then.
>>>>
>>>> 
>>>> 
>>>>> I know that sourceforge has recently added tons of tools also, like trac, git, bazaar, but the the tools are all un-knowledgeable of each other, not integrated with one another in the way that the tools at launchpad seem to be. 
>>>>>
>>>>> This yahoo mailing list cannot be the best we can come up with, say what you want about any other suggestions, I maintain that this yahoo mailing list is pretty inadequate in my view, especially since about 50% of the traffic on it seems to be more user centric than developer centric, and I am guilty of that also.
>>>>> 
>>>>> 
>>>> Agreed. I think too many things get lost here. I imagine an integrated solution would work better assuming it wasn't too cumbersome to use.
>>>>
>>>> 
>>>> 
>>> Launchpad has some planning tools there which allow brainstorming design 
>>> alternatives to be discussed along with posting example code attachments. 
>>>
>>> 
>>>>> Somebody is going to have to make some decisions if this project is ever going to get into gear. And those decisions will require volunteers to implement.
>>>>> 
>>>>> 
>>>> This is probably the biggest stumbling block. I think most developers would prefer an easier way to communicate ideas and share code than what we are currently using. 
>>>> 
>>> I agree, and I like the ability of Launchpad to support multiple source 
>>> trees on the project.
>>>
>>>
>>> Having a distributed version control system would also be an 
>>> improvement. Which is your favorite distributed version control system?
>>> 
>> 
> 
> Thanks Wayne. I value your opinion.

It always means something when someone you respect values your opinion.
Thanks Dick. I appreciate it.

>> The more I mess around with it, the more impressed I am with GIT. We
>> know it scales well and can handle anything we can throw at it and will
>> be well supported for the foreseeable future. It's command line
>> interface has been updated to the point where using it isn't that much
>> different than any of the other VCSs. It has some really interesting
>> looking power user commands. I don't that I would ever need to use any
>> of them but it's nice to know they are there. I don't know if Launchpad
>> supports GIT directly or if their integrated tools will work with GIT.
>> 
> 
> Not like they do with Bazaar.

That's what I figured so it makes sense to stay with Bazaar to take
advantage of the integrated tools. What you may gain in speed with GIT
will likely not be worth what you loose in the convenience of the
integrated tools.

>> I personally have no problems using Bazaar. It would be nice to have a
>> sandbox Bazaar repo of Kicad to see if the performance issues have been
>> addressed.
>> 
> 
> I may do that, but for the next week I think I will simply use bzr-svn 
> against the existing repo and see what it smells like. If I cannot get 
> a read I'll set up a sandbox.

Let me know when you get it set up. I would like to try it out an see
how it compares to the last time I used Bazaar.

>> I think using a distributed VCS is the most important thing.
> 
> I don't disagree, but to a person walking across the desert, even a 
> bicycle looks fantastic. What Canonical have done is probably more like 
> a paradigm shift, and we may find that there are things that will make 
> us even more happier than a bicycle would. We have to realize that some 
> of this inventiveness is brand new, so we may not even have a frame of 
> reference. What if instead of stumbling onto a bicycle, we stumble onto 
> an air-conditioned MAG-LEV train that travels at 300 MPH, free, and 
> complete with all the conveniences of travel....... ?

I've standing at the station waiting for that train for a long time:)

> Distributed version control is a major benefit, it will let us work more 
> efficiently, but I think there are things in our future which will help 
> everyone even more.
> 
> 
> I am fearful of git for a number of reasons, one of which is that casual 
> windows builders would be tormented with installing git. Having to 
> install Cygwin, perl, bash, to run git, is a non-starter for most 
> Windows users, it is a main reason why I pushed so hard for CMAKE. I 
> hate Windows, hate it even more with Cygwin on it. Plus frankly, with 
> git, I think that we could easily fall into a trap of idolizing the 
> Linux project as "the right way to do everything". I don't want any 
> part of that.

I'm probably not the best person in the world to ask this question.
I've been using Cygwin on windows for at least 10 year because I prefer
a sane shell environment even on windows. I learned to compute on a DEC
MicroVAX and VMS. I am perfectly comfortable with the command line and
prefer it for most of my development work. This question may be better
answered by the folks who prefer IDE's. Honestly, most of the tools
don't take that long to learn to use and I am more than willing to role
up my sleeves and wade through the documentation to learn how to use it.
Most people spend more time grumbling about learning to use new tools
than it takes to learn how to use them. Any steps we can do to improve
life for developers is a good thing.

> There may be some advantages to getting experience using bazaar and its 
> python underpinnings. It is easier to park web-based code on top of 
> it. Maybe some day there will be a web-based electronic part library 
> in the cloud, which has integrated version control.
> 
> 
> I try to minimize the number of C apps that I look at these days. It is 
> too demeaning, like programming on your hands and knees. C++ is more 
> dignified, I can stomach it. But C is for OSes, not for apps. That is

The only time I use C anymore is for embedded work. I can't imagine
trying to use GTK and GLib directly to build Kicad. Computers these
days are too fast and have too much memory and disk space to deal with
all the memory allocation headaches of using C. Seeing yet another
linked list implementation, makes me want to scream at my computer.
Give me the C++ container classes any day.

Wayne

> not to say that as a git user I would ever have to look at its source, 
> but I am saying that I would prefer to have to delve into python than 
> C. Especially C that Linus wrote with 8 character tabs, is not for 
> me. I have to kick my editor in the ass 5 times a day switching back 
> and forth to 8 character tabs so I can put out a Linux patch. I gave up 
> on tabs 20 years ago. before Linux was even written.
> 
> What we are doing in Kicad is far superior, working in a true high level 
> language, and dreaming about getting on that rocket train....
> 
> 
> Dick
> 
> 
> 
> 
> 
>> One of the
>> reasons I stopped working on the drawing code was that the experimental
>> code I was writing was making a mess of the code base with all of the
>> #ifdef/#endif code. I also realized that I probably do not have the
>> time to do it by myself. It would be nice to create an experimental
>> drawing code branch and have several people pulling from multiple
>> developer branches as the code progress and ideas are hashed out. Once
>> the new drawing code was stable it could be merged into the main branch.
>>
>> Wayne
>>