stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] Making StumpWM more modular


From: David Bjergaard
Subject: Re: [STUMP] Making StumpWM more modular
Date: Wed, 17 Sep 2014 21:57:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi,

Please keep the thread on topic.  I know that this is tangentially
related, but I would prefer the discussion be based around:
a. How to package parts of stumpwm (pretty much has run its course already)
b. Which parts of stumpwm could benefit from being separate cl-blah
   packages that we would control from the stumpwm organization? (this
   one is more involved as it depends on the utility of the code as well
   as how tightly coupled to the codebase the particular functionality
   is).
   
Cheers,

    Dave

Mehul Sanghvi <address@hidden> writes:

> That sounds great. I'll start looking into it over the next few days.
>
> On Wed, Sep 17, 2014 at 9:12 PM, Kan-Ru Chen (陳侃如)
> <address@hidden> wrote:
>
>     But you could apt-get install sbcl and clisp on travis-ci.
>     
>     There is also a cl-travis[1] project provides template for travis
>     integration.
>     
>     [1] https://github.com/luismbo/cl-travis
>     
>     Kanru
>     
>     
>     
>     Mehul Sanghvi <address@hidden> writes:
>     
>     > travis-ci does not provide SBCL or CLISP support.
>     >
>     > I'd be interested to help with this, as CI is what I do on a
>     daily basis.
>     >
>     >
>     > On Wed, Sep 17, 2014 at 10:55 AM, Quentin Stievenart <
>     > address@hidden> wrote:
>     >
>     >> 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
>     <address@hidden> 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
>     >> > address@hidden
>     >> > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>     >>
>     >> _______________________________________________
>     >> Stumpwm-devel mailing list
>     >> address@hidden
>     >> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>     >>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]