Subject: Re: Fvwm and Scwm

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 17 Jul 1998 10:59:33 EDT

"Eric S. Raymond" <[email-masked]> wrote:
> I think so, too.  As a person who's not in either the fvwm or scwm camps,
> but who's been around the track a few times, I may have a strategy to suggest
> for accomplishing it.  It'll take a little give and goodwill on both sides.
>
> I can see a merge working given three commitments:
>
> 1. The scwm people must provide a fully capable .fvwm2rc-to-.scwmrc
>    translator.
>
> 2. Scwm must support all existing fvwm2 modules.

We want to do both of these things anyway, although your phrasing it
this way implies a much higher level of priority and a higher degree
of robustness and completeness.

>
> 3. The fvwm people must accept that for the first few releases (until
>    guile gets space-tuned), the scwm/fvwm3 code may have a bigger footprint
>    than the existing fvwm2.  
>
> In other words: if the scwm people will live with a requirement that
> scwm be painlessly upward-compatible with fvwm2, and the fvwm2 people
> will cut them *temporary* slack on the footprint issue, we can all
> make this work.

[included for context, but I can't speak to this directly]

> There's a reason I emphasize `temporary'.  We're talking about replacing
> the ad-hoc config code with Guile.  A key advantage of this is that it
> would allow fvwm to leverage lots more brains than just the fvwm workers.
> Better dynamic-loading and modularization for Guile is critical-path
> for lots of projects besides ours.  It's much more likely that Guile 
> will improve dramatically than that we will ever get motivated enough to
> clean up the ad-hoc cruft in fvwm2's present guts.

I have to agree on this point and strongly emphasize it. Guile is
maintained by a group of people who are really smart about language
design and implementation. There are also a number of projects that
depend on Guile enough that people actively report Guile bugs, send
patches, and make actual improvements to the core that enhance Guile
in numerous ways. 

Furthermore, the Guile developers place a high priority on supporting
apps that use Guile. In particular, they have been very willing to fix
bugs for us and to listen to our feature requests and architectural
suggestions, even when these were things that were important for scwm
but perhaps not crucial for Guile per se. I can only imagine the level
of responsiveness increasing if fvwm and scwm merged, resulting in a
project that both worked the guile core really hard and had a really
high profile.

> Eventually, here's what I hope we can all agree to deliver:  a version of
> scwm that, when called through a link named fvwm2, reads .fvwm2rc,
> translates it on the fly to Guile, and runs just like fvwm2 (modulo
> bug fixes).

Although upward compatibility would obviously be essential, I am
unsure if this specific way of stating it (run through a link called
fvwm2 and get fvwm2 behavior) is necessarily the greatest thing. I say
this not because I don't think it's feasible, but because I think
people who want something that looks acts and feels just like fvwm2
should consider just using fvwm2. There's still a lot of people who
use fvwm1 because it better meets there needs. Of course, it is
possible that a guilified fvwm will be able to do everything fvwm2
does, only better, including the typical use memory footprint. In this
case, a very close emulation mode would be worth cconsidering.

> The program used for .fvwm2rc-to-Guile translation should, of course,
> be available standalone for people who want to go pure Guile right away.

Well, that's the way the initial version will work, at least.

 - Maciej
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 17 Jul 1998 11:50:41 -0400

> of robustness and completeness.

The implication is quite intentional.  That priority and robustness
and completeness is the freight I believe you will have to pay (and
*should* have to pay) for actually becoming fvwm3.  Politically, if
not technically.
 
> fvwm2 and get fvwm2 behavior) is necessarily the greatest thing.

You have a basic decision to make.  Are you serious about world
domination?  Do you really want to become the mainstream of fvwm
development, and capture the fvwm name and associated reputation?
Then I don't think you can duck, dodge, or temporize away this
requirement.

So far, you and Greg have been very convincing in arguing the
increased elegance and flexibility of scwm and the superior
cleanliness of the scwm code.  You're vulnerable on three other
issues; stability, footprint, and compatibility.

My take is that you can get away with handwaving at most one of these.
If you try to fudge two or more, the fvwm2 community will likely yawn
and invite you to piss off -- *and be right to do so*.

You can't nail down the stability issue, not with Guile still in alpha.
You score at best a draw on footprint, depending on whether your
audience is willing to consider libguile a `sunk cost' like libc.

Therefore, you *must* nuke the compatibility problem.  It's the only
way you have to show the fvwm2 people you're serious about holding
up your end of a merge.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

A wise and frugal government, which shall restrain men from injuring
one another, which shall leave them otherwise free to regulate their
own pursuits of industry and improvement, and shall not take from the
mouth of labor the bread it has earned. This is the sum of good
government, and this is necessary to close the circle of our
felicities.
	-- Thomas Jefferson, in his 1801 inaugural address
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 17 Jul 1998 12:23:24 EDT

> *should* have to pay) for actually becoming fvwm3.  Politically, if

I realize that it was intentional, and I accept that in case of a
merge that your phrasing and it's implication are correct. In other
words, I personally accept these burdens. I think Greg will also agree
that these are fair requirements for a merge. My point was just that
these are things we are doing already, and accepting this burden only
means raising the priority relative to other things.

> Then I don't think you can duck, dodge, or temporize away this

Please note that I did not say that it was technically infeasible or
even difficult. In fact, with a comple fvwmrc translator and 100%
compatible module interface (something that did not happen on either
count for the fvwm1 -> fvwm2 scwitch!), both of which I fully accept
need to happen, this is a matter of adding on the order of 10 lines of
C code to check argv[0] and run some special code if it equals
"fvwm2". So I have no desire to dodge this part of the requirement in
the sense of not wanting to put in the work. 

I just question whether on technical grounds, the specific issue of
having an "fvwm2" symlink is technically a good idea (for reasons
stated in my previous message). In fact, I almost decided not to raise
this nitpick for fear of being misconstrued as I seem to have been,
i.e. as ducking the necessity of 100% total backward compatibility.

> way you have to show the fvwm2 people you're serious about holding

I agree with all this, except that <nitpick>Guile is not still in
alpha, it is in heavy development between releases, but that is a
different issue.</nitpick>

But, I think it is fair to say about all three of all these issues
that we are working on them, and commit to serious improvement. Scwm
is in a phase of development where, for most of the current users,
adding features, fixing bugs and cleaning up the code are much more
important than backwards compatibility, stability (in the sense of
interfaces not changing as opposed to the sense of few bugs - scwm is
less buggy than some theoretically more mature window managers) or
resource consumption. But as the development cycle progresses, all of
these issues will be afressed on way or another. In case of a merge,
they will all get much higher priority earlier on.

In any case, I am already working on a fvwmrc->scwmrc translator, and
improvements to the fvwm2 module compatibility code are being worked
on by several people, including me. In fact, one person who just sent
me patches expressed the desire to personally enhance the code to be
able to run all exisiting fvwm modules perfectly.

 - Maciej