I think that this is generally a good idea. Splitting up stumpwm architecture in multiple, smaller packages that are still part of stumpwm is certainly a good idea.
However, I see a minor problem when splitting packages into a different projects (as for the keysyms): we should be careful that it won't create compatibility problems if ever the library interface is changed and stumpwm's source is not updated fast enough. I guess that keeping stumpwm related libraries under the stumpwm organization is the way to go to avoid this. Having a buildbot (or travis-ci) being run on every commit of stumpwm and it's libraries could also help. On 17 September 2014 16:36, David Bjergaard <dbjerga...@gmail.com> wrote: > Hi All, > > There's been some discussion on the issue tracker about repackaging some > of the code in stumpwm to be more modular. Some pieces are useful to > other projects in the CL ecosystem, and others have a semantic > difference from the rest of the core of stumpwm. > > In my short time as package maintainer, I've always appreciated the > input from the community, so if you have strong opinions please give > them here. > > You can catch up on some details of the discussion here: > https://github.com/stumpwm/stumpwm/pull/146 > https://github.com/stumpwm/stumpwm/pull/125 > > Cheers, > > Dave > > _______________________________________________ > Stumpwm-devel mailing list > Stumpwm-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
