Hi James, thanks for your message. Could you please point me to the (say 5) most serious problems that the official kicad website has. I might have some time/ability to fix it.
thanks Fab. On Tue, Feb 4, 2014 at 3:00 AM, James Hagerman <[email protected]>wrote: > Hi there, > > I've been lurking and haven't gotten into the KiCad source code yet. I > joined the dev list to get help with building under OS X. This bzr/git > debate is something I've been wondering about as well. > > I initially had issues installing bzr and bzr-tools under OS X. I tried > using the KiCad Homebrew installer and it installed bzr and bzr-tools for > me and then compiled KiCad. I know nothing of bzr on other platforms. > > Honestly: I don't think switching to git is actually going to solve the > REAL issue behind why new devs want to see KiCad move to git. I think it's > mostly a _documentation_ issue. > > The KiCad website and KiCad Launchpad page are full of broken or > misleading links to old, outdated, or conflicting information. Binaries > (and libraries) for all platforms are not readily available on either site. > > There is no simple, one stop location for documentation. It's spread > through forums, email chains, bug reports, old email archives (left over > from sourceforge), and a random slurry of blog posts by randoms all over > the web. > > One solution to the bzr/git debate could be: Spend time fixing up the > KiCad sites. Name some to the task. Shove all the git/bzr back-and-forth > into one place while ALSO providing the rest of the info newcomers (devs or > users) need to get rolling. > > Besides, a GitHub fork DOES exist and was being updated pretty regularly > when I last checked... If bzr WAS a boundary to new devs, they'd all just > start working off of that git fork and drop bzr on it's ass regardless... > But that hasn't happened... > > Just my 3cents, > James Hagerman > > > On Mon, Feb 3, 2014 at 11:37 AM, Wayne Stambaugh <[email protected]> > wrote: > >> On 2/2/2014 9:16 AM, Mitch Davis wrote: >> > On Sat, Feb 1, 2014 at 10:40 PM, Joel Holdsworth >> > <[email protected]> wrote: >> >> discouraged by the friction. >> > >> > Amen. >> > >> > Mitch. >> > >> >> Is using Bazaar really enough "friction" (your word not mine) to prevent >> developers from contributing to KiCad? I hope not. That would be a >> very sad commentary indeed. In the 25 years or so of software >> development, I've used almost every open source and quite a few >> proprietary VCSs. I never found any of them that difficult to learn (at >> least as far as the client is concerned) to use it as an excuse for not >> contributing to a project. If I thought for a second that switching to >> GIT would make life significantly easier or bring a flood of new highly >> skilled developers to the project, I would agree to it in a heartbeat. >> Either I am not that naive or too stubborn change just for the sake of >> the latest and greatest VCS. The question to ask should not be whether >> or not to use GIT, it should be which tool best serves the needs of the >> project. As long as we host the project on Launchpad, Bazaar is >> probably the best fit unless all of the Launchpad specific tools in >> Bazaar have been ported to GIT. If they have, I haven't seen them so >> please point me in the right direction so I can test them. We have so >> many more important issues to resolve than keeping up with the latest >> VCS. For those who weren't around for the transition from >> Subversion/SourceForge to Bazaar/Launchpad, there was a lot of hand >> holding required for several months by the lead developers. I >> personally am not ready to go through that again any time soon. While I >> agree that the lack of development on Bazaar is not a good thing, it >> doesn't mean that we should immediately abandoned ship a switch to GIT. >> What happens when GIT matures to the point where development slows down >> or the next great VCS becomes more popular than GIT? Do we kick it to >> the curb and jump on the next "great" thing? If someone can provide >> quantifiable data that GIT will speed up development and/or bring more >> developers in the project, I would be willing to open up the discussion >> again. >> >> Wayne >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> > > On Mon, Feb 3, 2014 at 5:19 PM, Chris Morgan <[email protected]> wrote: > >> On Mon, Feb 3, 2014 at 2:37 PM, Wayne Stambaugh <[email protected]> >> wrote: >> > On 2/2/2014 9:16 AM, Mitch Davis wrote: >> >> On Sat, Feb 1, 2014 at 10:40 PM, Joel Holdsworth >> >> <[email protected]> wrote: >> >>> discouraged by the friction. >> >> >> >> Amen. >> >> >> >> Mitch. >> >> >> > >> > Is using Bazaar really enough "friction" (your word not mine) to prevent >> > developers from contributing to KiCad? I hope not. That would be a >> > very sad commentary indeed. >> >> I'm in the same boat with vcs. I've used pvcs, cvs, svn, clearcase and >> git and I'd like to think I know them very well. >> >> I'd like to add (or re-add since this is a new thread and I've brought >> this up before) my vote for git. >> >> Bazaar was too much friction for me and kept me from being able to get >> started and contribute to the project. >> >> Chris >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
