| delorie.com/archives/browse.cgi | search |
On Sat, Sep 12, 2015 at 2:15 PM, John Doty <jpd AT noqsi DOT com> wrote: > > On Sep 12, 2015, at 3:44 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote: > >> On Sat, Sep 12, 2015 at 12:08 PM, John Doty <jpd AT noqsi DOT com> wrote: >>> >>> On Sep 12, 2015, at 12:55 PM, John Griessen <john AT ecosensory DOT com> wrote: >>> >>>> On 09/12/2015 11:53 AM, John Doty wrote: >>>>> On Sep 12, 2015, at 10:25 AM, John Griessen<john AT ecosensory DOT com> wrote: >>>>> >>>>>>> On 09/12/2015 10:51 AM, John Doty wrote: >>>>>>>>> Test cases are important, but I don’t think it’s necessary to have add-on modules maintained with the core sources in order to test them together. >>>>>>> >>>>>>> >>>>>>> Why? Roland made a clear case for that. >>>>> Successful projects like Python keep core and add-ons separate. >>>> >>>> We don't have enough people to act like the python project. >>> >>> There are 51 megabytes of contributions from 83 contributors on gedasymbols.org. We’re *already* acting like the Python project, except we’re pretending we aren’t. >> >> And gedasymbols is not well used, or well-tested, or particularly >> accessible to the uninitiated. > > We could certainly do better. > >> It great to separate things into >> modules but there's no point in not storing and distributing them >> together with the core distribution. > > I think many would find a 50 MB distribution a bit much. By modern standards, this is minute. > Simply distributing a mixed bag of stuff with the core will not relieve confusion. Modules aren't just a mixed bag of stuff, they're pieces designed to work with the core. It's helpful if people know they exist and can try them easily. Gedasymbols is arguably a lot more mixed since the symbols are created in different ways, but if they had some sort of common interface for build/search etc. I think it would be worth adding them also, since the lack of them is another big weakness of gEDA. > I also see the success of the core/addon approach in other >projects. They are much bigger projects, with established ways of finding the modules. gEDA doesn't have any such way. It's easier to just distribute them with the core than make one and expect it to be adopted. > It helps interface discipline when they are kept separate. Perhaps, but it also promotes forking, which is a much bigger problem for gEDA at the moment.
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |