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 <stambau...@gmail.com > <mailto:stambau...@gmail.com>> 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@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
