Re: reviving sawfish development - conclusion

["Robert Personen" <psyquark gmail com>]

It is good that someone is willing to step up and be a project manager
(even if not a developer).

Is there any interest in taking over librep and rep-gtk maintenance?
librep might have some patches (and definitely needs documentation)
and rep-gtk could probably use some updates to support new gtk2
features.

mailing list, webpage and wiki seem to be covered, is there a desire
for a IRC channel?


> ================== FUTURE PLANS =================
>
> I certainly will NOT allow people to wreak havoc in the repository.
> I think that we should proceed in following way:
>
>
> 1. make a new sawfish release from current SVN, name it 2.0 since it
>    is a release after many years.


I would have to agree with what others have already said, there does
not seem to be enough changes in SVN or from other sources to warrant
a 2.0 release.  I would say a 1.3.1 release from SVN if it is stable
and then maybe a 1.4 release including any other patches that are
still out there.


> 2. this will direct attention towards sawfish from many different
>    distributions. And they will start talking about maintaining local
>    patches specific to each distribution. So we will stronly encourage
>    them to submit their patches as soon as they can.
>
> 3. Then make a sawfish release 2.1 shorthly thereafter with all the
>    patches included.
>
> 4. from that point on - merge patches from distrubutions - since most
>    often they are only directed towards making sawfish compile on that
>    certain platform, or some platform-specific bugs.
>
> 5. Now we will have a stable codebase to work with: tabs support,
>    xgl/compiz, etc....

The goal for a 2.0 release should not be to add compositing fun but
rather to cleanup, modularize and understand the current code base.  I
would hope that sawfish would be separated into a few parts: a
loader/stub (sawfish and sawfish-client), the base X bindings
(rep-X11), the base lisp code that drives the WM, lisp extensions and
rep extensions.  The reason is that it would allow for easier
documentation/planning and allow for a move to XCB if desired.

All the base functionality required for those 3d tricks should be
developed as separate modules and stand alone apps before any attempt
is made to integrate it with the main WM.   None of them require being
in the same address space and environment as sawfish for the purposes
of testing base functionality and base use.  Developing the bindings
and using them in the WM at the same time will only bring instability
and headaches.  Once the the base functionality is stable (API and
code) then the base sawfish can be configured to detect and use the
new modules.