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 16:51:24 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi,

I think everyone agrees that some sort of CI tool is important/useful.
Indeed it seems its the only automated testing that we could perform
without major re-writes to the code.  

The issue is: I have no experience (and precious little time) to set
something up.  Anyone who is willing to donate time to CI can get in
contact with me and I'll give them commit access to that part of the
organization.

To clarify about the packages:

Anything that stumpwm depends on would continue to remain within the
organization.  One of the nice features of stumpwm is its small
dependency tree.  I plan on keeping it that way, in as much as any
dependencies we create from repackaging will be maintained by us.  

The idea is twofold:
1. Make stumpwm more modular from a code organization POV
2. Provide the generically useful bits as their own standalone packages
   (mainly for quicklisp, but potentially for package maintainers of
   other distros).
   
Cheers,

    Dave

J David Smith <address@hidden> writes:

> I agree that this is a good idea.
>
> I also think that a continuous integration tool running on projects in
> the stumpwm org would be a good way to help mitigate issues from
> changes to a library interface. I've set up things like this before
> (within work) for a Node.js project which we wanted to componentize,
> and it worked pretty well.
>
>  - J David Smith
>
> Quentin Stievenart writes:
>
>> 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]