Subject: split fvwm2 and modules?

From: Dominik Vogt <[email-masked]>
Date: Mon, 25 Jan 1999 16:36:53 +0100

I'd like to discuss if we should split off the modules from the
fvwm2 distribution. It seems this large package causes unnecessary
trouble.

pros:

 - smaller package (well, not really)
 - no need to create fvwm2 packages if a module is buggy and vice
   versa

cons:

 - people will possibly use incompatible versions. This can in
   part be prevented by checking if the module package has a
   compatible version info when compiling
 - we'd have to be careful not to make disruptive changes
   without updating the version info for the modules/fvwm2

Dominik

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: [email-masked] (Paul D. Smith)
Date: 25 Jan 1999 16:55:04 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> I'd like to discuss if we should split off the modules from the
  dv> fvwm2 distribution. It seems this large package causes unnecessary
  dv> trouble.

Something to consider for the future, perhaps.  Probably our
oft-expressed desire to remove some of the modules is A Good Thing, and
a good start.

However, I think some belong with the core Fvwm.  Should we make
FvwmPager separate?  Or FvwmAuto?  Or FvwmWinList or FvwmButtons?  I
think those modules are so often used they should come with the core.
Ditto for other things in "modules".

And remember that some modules, and more in the future, require others
to work (right now FvwmAnimate requires FvwmForm).

In general, I'd only think a split a good idea if it was to remove
things that we really think hardly anyone uses.  If it's just to avoid
more frequent releases or decrease download time, then personally I
think the hassle of always having to get (and create, etc.) two packages
instead of one outweighs the problems, so far.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Tue, 26 Jan 1999 09:07:31 +0900

dominik_vogt> I'd like to discuss if we should split off the modules
dominik_vogt> from the fvwm2 distribution. It seems this large package
dominik_vogt> causes unnecessary trouble.

We should not forget we already did it before, and get back again.

People tends to say "yeah, why this package doesn't have module XXX ?"
IMHO, it's not a smart way, if it is just for "small tarball" and/or
"avoid to bundle buggy module".

Yes, splitting the fvwm-core version and fvwm-modules version is maybe 
a better way, however, I believe we must say "hey, which version of
fvwm-modules should I fetch, for fvwm-core version 2.X.X ?"

Again, we should not forget we already did it before. I'm afraid that
easy package spliting brings us an unwanted confusion.

-- -
Makoto `MAR' MATSUSHITA

---

From: [email-masked]
Date: Tue, 26 Jan 1999 09:11:08 -0500 (EST)

On 25 Jan, Dominik Vogt wrote:

> I'd like to discuss if we should split off the modules
> from the fvwm2 distribution. It seems this large package
> causes unnecessary trouble.

Yes, it's easier to split some stuff off (FvwmIconMan and FvwmCommand
were both being actively maintained outside the fvwm tree at one point
in the not so distant past).  Somebody can take over the development of
the individual modules, and they won't get bogged down by somebody
else's schedule.

The down side to this is that for each "package" that is maintained, the
user will have to download the distribution, configure it, and build it.
Now, for your average software hacker, this isn't a big deal, but as
more and more people start using Linux and other workstation and
server level machines, they are going to want distributions to be EASIER
to install, not more complicated.  Think how easy it is to install
software for those toy operating systems put out by a company in
Redmond.

Further, if you are going to split off just SOME of the modules, which
ones?  Here's the current (2.1.10) listing of the entries in the modules
directory:

FvwmAnimate    FvwmBanner     FvwmForm       FvwmM4         FvwmSaveDesk
FvwmAudio      FvwmButtons    FvwmIconBox    FvwmPager      FvwmScroll
FvwmAuto       FvwmCpp        FvwmIconMan    FvwmRearrange  FvwmTalk
FvwmBacker     FvwmEvent      FvwmIdent      FvwmSave       FvwmWinList

Which of these are you going to remove?  I personally use FvwmButtons,
FvwmPager, FvwmForm, FvwmIdent, FvwmM4, and FvwmTalk.  I doubt that my
particular choices, or anybody else's, could be considered universal.

Anyway, if there is a consensus to release the modules as a separate
distribution, then libfvwm.a in fvwm-2.2 should be renamed to
libfvwm-2.2.a, so that the modules can search for it at configure time
(or we might need to generate a ./fvwm-config script that will allow
the modules to test which version of fvwm is currently installed).

If we don't do this in 2.2, then I anticipate a possible versioning
problem in the future if you split out the modules.

-- 
Larry Gensch					      [email-masked]

       "I suggest a new strategy, R2:  Let the Wookiee win." -- C-3PO

---

From: Dan Espen <[email-masked]>
Date: Tue, 26 Jan 1999 09:25:26 -0500

> > causes unnecessary trouble.

My own opinion is, if the package is under 1.4M, (diskette sized),
the package isn't too big.

I know we are doing inadequate testing on some of the modules,
but putting them in a separate package will just make it worse.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Dominik Vogt <[email-masked]>
Date: Tue, 26 Jan 1999 15:28:47 +0100

> software for those toy operating systems put out by a company in

It's a pain in the ass. You don't have under control what happens
and usually the software overwrites some dlls with other version
numbers that are already in use by other applications. The average
user won't compile fvwm2 himself anyway.

> particular choices, or anybody else's, could be considered universal.

No, you misunderstand what I mean. I'd move *all* modules and extras
into the same new package. THis additional package would be an add on
to the core and not able to build anything. You'd have to untar it into
the same directory to build it at all. And we could easily check
consistency by giving the modules the same version number as the core.
Like this:

fvwm-2.2 and fvwmmodules-2.2 given

Then fvwm-2.w gets a bugfix and is called 2.2.0.1. The first three
digits are the same, so you can use both packages together.
The you have a fix in some modules and make fvwmmodules-2.2.0.1.
Still no probelm. Now we make some disruptive fixes in the core
and call it fvwm-2.2.1. Now the versions don't match anymore
and a fvwmmodules-2.2.1 will be created.

The version numbers look a bit odd, but IBM does this with
AIX and it works well.

All the user has to do in addition is to download and untar
another package. Anything else can be handle by automake (at
least I hope so).

> the modules to test which version of fvwm is currently installed).

No need to do this since the modules won't even compile separately.

> problem in the future if you split out the modules.

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 25 Jan 1999 23:43:46 +0100

> to work (right now FvwmAnimate requires FvwmForm).

I wouldn't want to distribute the modules independently, only
separate from the fvwm2 core.

> instead of one outweighs the problems, so far.

I was referring to this trouble with FvwmWinList: one obscure module
shows up a bug and we have to make a new beta for the complete
package. The decision about 2.2 would be much easier if we could
fix this in a separate package.

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]