[STUMP] Revitalizing StumpWM

[David Bjergaard]

Hi all,

I know there's a handful (fistful?) of people who are happily using
stumpwm, but the git repo has been stagnant for a long time.  Shawn has
added me as a maintainer on github and I'm working through the open pull
requests as I have time.

While my experience hacking a window-manager is relatively limited, I
have some ideas that may add some new life to StumpWM.  

First and foremost, I want to reorganize some of the information on the
wiki so that it matches the state of the repo.  This didn't happen in
the since the wiki was imported from OddMuse two years ago.  

Second, I want to get an idea for which bugs are still out in the wild
and which were fixed but never closed.  To this end, I want the
bug/issue tracking to happen on github.  If you've filed a bug report in
the past and it hasn't been addressed please open a new one on github.
I will be removing the Bugs portion of the wiki and adding instructions
on how to file bug reports when I get time.

Once we get any outstanding bugs squashed, I want to release a 0.98
version, as the best, stable representation of the current head of git.

After that we can start active development again.  I would like to
change the way plugins are organized, as well as some simple
improvements to the build-system (including a bootstrap script to
install quicklisp and stumpwm's prereq's for instance)

Shawn's philosophy for StumpWM is a "everything-and-the-kitchen-sink
WM,"  or "the emacs of WMs." There's a lot of (under advertised) contrib
modules that various hackers have contributed in the contrib/
directory.  I would like to take a page from emacs' contribution
management and have each plugin author maintain his/her own code and
we'll include a pointer to it from the wiki.  This way there's no issues
with contrib requests not getting pulled in, and the energy barrier for
writing a plugin will be much lower.  I'm not (yet) envisioning
something like package.el, that's too much right now. Eventually it
would be nice to have a script or chunk of code that could iterate over 
the contrib repositories and pull in the latest changes.

What do you guys think? Please let me know how this sounds or if you
have any ideas on what the future of StumpWM should be.  Also, please
know that pull requests are *very* welcome. I will do my best to respond
(either with a merge) or questions quickly.

Cheers,

    Dave
Hi all,

I know there's a handful (fistful?) of people who are happily using
stumpwm, but the git repo has been stagnant for a long time.  Shawn has
added me as a maintainer on github and I'm working through the open pull
requests as I have time.

While my experience hacking a window-manager is relatively limited, I
have some ideas that may add some new life to StumpWM.  

First and foremost, I want to reorganize some of the information on the
wiki so that it matches the state of the repo.  This didn't happen in
the since the wiki was imported from OddMuse two years ago.  

Second, I want to get an idea for which bugs are still out in the wild
and which were fixed but never closed.  To this end, I want the
bug/issue tracking to happen on github.  If you've filed a bug report in
the past and it hasn't been addressed please open a new one on github.
I will be removing the Bugs portion of the wiki and adding instructions
on how to file bug reports when I get time.

Once we get any outstanding bugs squashed, I want to release a 0.98
version, as the best, stable representation of the current head of git.

After that we can start active development again.  I would like to
change the way plugins are organized, as well as some simple
improvements to the build-system (including a bootstrap script to
install quicklisp and stumpwm's prereq's for instance)

Shawn's philosophy for StumpWM is a "everything-and-the-kitchen-sink
WM,"  or "the emacs of WMs." There's a lot of (under advertised) contrib
modules that various hackers have contributed in the contrib/
directory.  I would like to take a page from emacs' contribution
management and have each plugin author maintain his/her own code and
we'll include a pointer to it from the wiki.  This way there's no issues
with contrib requests not getting pulled in, and the energy barrier for
writing a plugin will be much lower.  I'm not (yet) envisioning
something like package.el, that's too much right now. Eventually it
would be nice to have a script or chunk of code that could iterate over 
the contrib repositories and pull in the latest changes.

What do you guys think? Please let me know how this sounds or if you
have any ideas on what the future of StumpWM should be.  Also, please
know that pull requests are *very* welcome. I will do my best to respond
(either with a merge) or questions quickly.

Cheers,

    Dave