kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 7/16/20 12:13 AM, Tim Hawkins wrote:
> 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.

Parts of KiCad are very modular.  Other parts, not so much.  There is
still plenty to do in that regard.

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

Code modularity and shared object modularity are two separate issues.
If you are suggesting that we break a kicad.so into lots of smaller
libraries, I don't see the need for that except maybe to split out the
board and schematic base object code.

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

The two best sources of information for new developers are the
contributors guidelines on the KiCad website[1] and the wiki on the
KiCad source repo at GitLab[2].  There is a bit overlap between these
resources but everything you need to know is in there.  If you have any
questions, the mailing list is the place to ask.

[1]: https://kicad-pcb.org/contribute/developers/
[2]: https://gitlab.com/kicad/code/kicad/-/wikis/home

> 
> On Thu, Jul 16, 2020, 07:10 Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto: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
>     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
>