← Back to team overview

kicad-developers team mailing list archive

Re: Re: Kicad libraries for pcbnew


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?


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.

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.

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

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.

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....... ?

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.

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 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....


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.


Follow ups