kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #44200
Re: Kicad 6 API
Modularization is a key part to large-scale refactoring, if you have system
that can't be subdivided then that a good indicator that you have an
architectural problem.
One of the best refactoring patterns for large systems is the "Strangler
fig pattern", where you split out a unit of functionality as a seperate
module and refactor that. In this case I'm speaking of modules nothing the
kicad sense of its bunch of seperate apps, but in the sense of a lot of
small subunits, somebody spoke above of a kicad.so library, but that is in
itself too large a chunk and things need to be a lot smaller than that.
I'm a 40 year veteran coder, c, c++, php, java, kotlin, and c#/dotnet core.
I have not been very active in OSS, maybe it's time that changed, and kicad
sounds like a good project to engage with, as it would engage with my
interests (PCBs, CNC, 3d printers etc, personal fabrication). I use fedora
Linux everywhere, I have all the tooling required.
Where can I find a good guide for getting started with the project?
On Thu, Jul 16, 2020, 07:10 Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> Hi Conrad,
>
> On 7/15/20 3:51 PM, Conrad Wood wrote:
> > On Wed, 2020-07-15 at 13:53 -0400, Mark Roszko wrote:
> >>> I also think it would enable independent software developers to
> >> build software on top of, or around kicad, further enhancing its
> >> value.
> >>
> >> They should be contributing to KiCad first ;)
> >> These plans for separation have been around for years, the problem is
> >> the amount of devs is limited and their time even more so. It is
> >> an open source volunteer effort after all.
> >
> > Isn't that a bit of a chicken-and-egg situation?
>
> Not necessarily. Refactoring can be done incrementally over long
> periods of time. It doesn't have to be an all or nothing effort. This
> is pretty much how the Linux kernel development happens.
>
> >
> > I mean, it's fairly hard to start contributing to KiCad due to its
> > complexity. (at least that is my impression - but then I might just be
> > stupid :) )
> > IMHO, splitting it up would lower the entry barrier to new-comers.
>
> EDA applications are by their nature complex so I don't know how
> splitting up complex code would lower the barrier to entry. I'm not
> suggesting that the KiCad code base couldn't be vastly improved but I
> cannot see how that will lower the barrier to entry for new developers.
>
> >
> > I'd be more than happy to contribute, but clearly I can't just "split
> > out bits into a library" on my own w/o discussion and consensus. That
> > _has_ to be a team effort, right?
>
> Any changes to the code structure would require discussion and consensus
> with the lead development team. My guess any discussion that you could
> think of has already been discussed more than once. It's generally a
> good idea to check the developer list mailing archives for previous
> discussions so we don't have to rehash the same discussion.
>
> >
> > I understand, that there never is "The Right Time" to do something like
> > it and I consider it very important not to add any extra workload on
> > already stretched people.
> >
> > Rather, with starting this discussion I hope to contribute with my
> > limited means, specifically, finding a means to spread the workload a
> > bit more evenly, and at some point, I might be able to directly
> > contribute as well.
>
> I will reiterate Seth's comments about starting small. It really is the
> most sensible path forward to becoming a member of the development team.
>
> Cheers,
>
> Wayne
>
>
> >
> > Also, for the sake of clarity, when I mentioned about on top of or
> > "around kicad" I was very much thinking of more open-source software,
> > not closed systems! Thus adding to the functionality of KiCad.
> >
> > Conrad
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References
-
Kicad 6 API
From: Conrad Wood, 2020-07-09
-
Re: Kicad 6 API
From: Nick Østergaard, 2020-07-09
-
Re: Kicad 6 API
From: Conrad Wood, 2020-07-13
-
Re: Kicad 6 API
From: Simon Richter, 2020-07-13
-
Re: Kicad 6 API
From: Conrad Wood, 2020-07-13
-
Re: Kicad 6 API
From: Jon Evans, 2020-07-13
-
Re: Kicad 6 API
From: Tim Hawkins, 2020-07-14
-
Re: Kicad 6 API
From: Seth Hillbrand, 2020-07-15
-
Re: Kicad 6 API
From: Conrad Wood, 2020-07-15
-
Re: Kicad 6 API
From: Mark Roszko, 2020-07-15
-
Re: Kicad 6 API
From: Conrad Wood, 2020-07-15
-
Re: Kicad 6 API
From: Wayne Stambaugh, 2020-07-15