Subject: proposal/volunteer for 2.0.47/48

From: Dominik Vogt <[email-masked]>
Date: Sun, 25 Oct 1998 14:20:29 +0100

Hi folks,

I have a proposal to make for the way to 2.0.47/48:

1) I create a new branch with my menu positioning patch
   very soon (perhaps even today). I have been ill for
   a week and a half and have been quite busy with fvwm
   to fight boredom. The original menu position stuff is
   now only a small part of the whole patch along with
   enhancements if the lib, FvwmPager, FvwmButtons and
   fixes of various bugs in the lib and fvwm2.

2) Dan and I take an effort to merge FvwmAnimate and
   'menu position' into one branch and label it 2.0.47e.

3) We integrate Germans patches into 2.0.47e and name it
   2.0.47f. Correct me if I am wrong, but I think with
   these three patches merged we have the three biggest
   outstanding chunks of work unified.

4) Tests - tests - tests until we are convinced we have a
   sound version. This phase would be limited to the workers
   list.

5) Merge in the hosts of smaller patches that accumulated
   over time and label it 2.0.47.

6) Ask for volunteers to beta-test the new 2.0.47 on both
   lists until things run really smooth.

7) Make a bugfixing release 2.0.48.

I could imagine the following schedule:

(1) 10-27 (tuesday)
(2) 11-06 [2.0.47e]
    How far are you with your FvwmAnimate branch, Dan?
(3) 11-13 [2.0.47f]
(4) 11-27
    if everyone helps
(5) 12-11 [2.0.47]
(6) 12-31
    How long will this take? I have no experience with
    this but would estaimate three weeks.
(7) 01-01-1999 [2.0.48]

This schedule does not seem very tight and it might
be best like this as we all probably have not the time
we might want to spend for our f... virtual window
manager :-)

Now the part I am sure I *will* regret.
Well ... err, I - would volunteer to organize the way
up to 2.0.48. Please, do not hesitate to voice any
objections. In fact I am working on fvwm2 for only two
months now and I hope this disqualifies me for such a
job ;-) Please, if anyone feels more competent to do this
(I am sure all of you are) just tell us you will do it
and that I can just keep on torturing you with k's of
patches in dozens of files (hehe).

Ciao

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://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: Dominik Vogt <[email-masked]>
Date: Sun, 25 Oct 1998 15:12:48 +0100

After 2.0.48 the next important things to do might be:

1) Switch to autoconf soon
2) Do the GSFR finally

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Mon, 26 Oct 1998 11:14:13 -0500

>     How far are you with your FvwmAnimate branch, Dan?

I'm going to declare FvwmAnimate officially done as of this morning.

In this morning's changes, I removed a warning  message that was being
generated during restart,  due   to an  incorrect asterisk  in  a menu
title, and  I  added a  "Custom"  entry  to the builtin   menus.   The
"Custom" entry  brings up FvwmForms to allow  complete control  of all
FvwmAnimate settings.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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: [email-masked] (Paul D. Smith)
Date: 26 Oct 1998 13:11:25 -0500

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

  dv> After 2.0.48 the next important things to do might be:
  dv> 1) Switch to autoconf soon
  dv> 2) Do the GSFR finally

If we can't get autoconf into 2.0.48 then _please_ lets put it into a
quickie-followup immediately afterwards, and not wait for the GSFR.

If fvwm was properly autoconf'd I know _I'd_ be able to test it on a lot
more machines, much more often than I do now.  It's simply too much of a
pain to configure new releases on all the different systems I use
without autoconf.

-- 
-------------------------------------------------------------------------------
 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://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: Dominik Vogt <[email-masked]>
Date: Sun, 25 Oct 1998 17:22:07 +0100

> If we can't get autoconf into 2.0.48 then _please_
> lets put it into a quickie-followup immediately
> afterwards, and not wait for the GSFR.

I would do it as soon we have a clean code base to
work on.

> If fvwm was properly autoconf'd I know _I'd_ be able
> to test it on a lot more machines, much more often
> than I do now.  It's simply too much of a pain to
> configure new releases on all the different systems
> I use without autoconf.

That would be great. Has anybody any experience on
how much effort switching to autoconf would be? I am
willing to help there but know nothing about autoconf
(except that it works well ;-) )

Ciao

Dominik

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 26 Oct 1998 13:28:25 EST

>From previous experience, I can say that blatant stealing from the
fvwm95 autoconf version will get a lot of the way there. Of course, it
would be nice to clean up afterwards to actually test for all
functions and headers that need to be tested for, but that can be done
by waiting for people with weird systems to report breakage. Also,
assuming it is still desirable to be able to build the main binary as
`fvwm', `fvwm2' or anything else, and have paths change appropriately,
that will take a bit of extra work, but it can be done with a
configure-time option which is much nicer than hand-editing the iamke
template.

An even bigger win would be to use Automake as well as Autoconf, but
that requires more work. Automake has some really nice features in the
Makefiles it generates, including automatic dependency tracking and a
`make uninstall' rule.

 - Maciej Stachowiak

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 26 Oct 1998 13:32:46 EST

> (except that it works well ;-) )

As I said before, I did it early in scwm's history, and so did the
fvwm95 people. I think the best way to grok autoconf is to read the
manual, do the changes based on an examle configure.in and Makefile.in
and then read the manual again and fix the things that could be done
better.

An extra-ambitious person might want to try switching the code to
automake at the same time as autoconf, but I can't reccomend this
unless said person has hacked autoconf stuff before.

 - Maciej

---

From: Dan Espen <[email-masked]>
Date: Mon, 26 Oct 1998 13:56:17 -0500

> (except that it works well ;-) )

Don't forget, the work has already  been done.  It is sitting, waiting
for us at:

http://www.cs.mcgill.ca/~stever/software/fvwm/

---

From: Steve Robbins <[email-masked]>
Date: Mon, 26 Oct 1998 14:03:08 -0500 (EST)

> Makefiles it generates, including automatic dependency tracking and a

Hey guys, 

Like I've been saying since about last December: THIS HAS ALL BEEN DONE!
See

	http://www.cs.mcgill.ca/~stever/software/fvwm

--
Steve Robbins                              <[email-masked]>

Standing on the beach with a gun in my hand
staring at the sea, staring at the sand ...

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Mon, 26 Oct 1998 20:33:00 +0100 (MET)

>    outstanding chunks of work unified.

	Well, if you can wait for a week or two (currently I'm busy
applying for grants for my postgraduate studies :), I'll post
a new version with some improvementes (mainly more help, more
options and maybe a similar way to define buttons and decorations
diagonal gradients).

> patches in dozens of files (hehe).

	The question is no who is more competent (you have 
almost done more in two months that eveybody else in two years!)
the question is time, we have the experience of Dan saying
he would work on fvwm2, but he didn't rembenber a day ONLY has 24 
hours (just kidding:), well I think if you really want (soon you will
be regreting that decision) you could take up the job, and although
I think the same (I mean doing it myself) after rethinking it (for just a 
minute) I discover I will not be able to study second course of Mathematics,
Administrating a LAN, study my postgraduate courses and organize fvwm2
development all in a year (I DO remember a day has 24 hours!), although
I hope I would contribute with patches and testing (hey these 20 users the
LAN has will keep stuck with fvwm2 development versions for a long time XD

	I vote for you!

<>-------------------------------------+-----------------------------------<>
   One O.S. to rule them all,          |  German Gomez Garcia
      One O.S. to find them.           |  [email-masked]
   One O.S. to bring them all          |
      and in the darkness bind them.   |  "Wur Qanar Wur Stilor Wur Kas"
<>-------------------------------------+-----------------------------------<>

---

From: Dan Espen <[email-masked]>
Date: Mon, 26 Oct 1998 14:48:16 -0500

German Jose Gomez Garcia <[email-masked]> writes:
> we have the experience of Dan saying
> hours (just kidding:)

We  don't want to  re-write history here.  I  have never offered to be
the owner of fvwm2.

In fact, I proposed  that  we can keep   this project moving   forward
without anyone being identified as the owner.

Just 24 hours?  Even if I skip lunch?

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 25 Oct 1998 18:53:21 +0100

> options and maybe a similar way to define buttons and decorations

After all these months (or even years) a week should not
matter.

> > up to 2.0.48 ...

> ... the question is time, we have the experience of Dan saying
> hours (just kidding:),

Please remember this is a limited offer for the beginning.
I don't want to think much farther than 2.0.48 for the
moment.

> well I think if you really want

No, I don't, but I can not stand watching fvwm going
down the river, so I will do it.

> (soon you will be regreting that decision)

I already am, believe me.

> ... (I DO remember a day has 24 hours!) ...

You probably wouldn't believe me that I have no time
at all to work on fvwm, wouldn't you? Most of the work
I did was in the early morning hours and during three
weeks I had been ill. And then there is my dancing
partner and I'm sure the two kittens I get in a few
weeks have other ideas how I should spend my scarce
spare time. In other words: I would *love* it.

> (hey these 20 users the LAN has will keep stuck with fvwm2
> development versions for a long time XD

Ahem, wouldn't your LAN users like to play beta testers
8-)=) ?

Thanks for your encouragement.

Dominik

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Tue, 27 Oct 1998 00:17:03 +0100 (MET)

> Just 24 hours?  Even if I skip lunch?

	I'm getting a lamer as I get older..... :) It was typo, when I said
Dan I wanted to say Brady (sorry Dan, just that I read your mail, and your
name displaced Brady from my mind)

PS: Well, writting so late in the night makes these things happen often than
desirable....

---

From: Jonas Luster <[email-masked]>
Date: 27 Oct 1998 02:39:51 +0100

> (except that it works well ;-) )

Oh, it's a pain in the *****. I've switched one of the programs I'm
involved (inn, a Newsserver) to autoconf as a test before the 2.0
Release which is based on autoconf from scratch.

You need some very deep understanding of what's going on, how it is
done and some days with your ctags-files before even thinking about
generating a config.in that runs on most machines.

The documentation is somewat .. ummm .. funny to read and there's zero 
to none good additional in-deep-a-hacker-would-read docs to refer
to. I printed out autoconfs from most of the files I found at my
systems (thanks FreeBSD-Ports it's easy to find out which programs are 
already autoconfed) and went thru' em one rainy german sunday.

A good starting point is provided with the KDE-developers-Dist. in
which Kalle Dallheimer explains the useage of autoconf and provides
some templates. I'm willing to volunteer a bit, but I must admint I've 
not even read thru' the fvwm-source by now so I can only be of a
general kind of help.

readya,
	jonas

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 27 Oct 1998 02:08:30 -0500 (EST)

I think hard consideration for a default method of maintaining "Themes" in
Fvwm2 ASAP is warranted.

There have been two reasonable starts that I have noticed;
http://fvwm.themes.org/
http://www.staticbomb.com/fvwm2gnome/

John Anderson at fvwm.themes.org is going to change their theme format to
make it compatible with fvwm2gnome and add additional features from there.

I do not know the time line, but I would suggest that as soon as those two
are compatible, that fvwm-workers adopt this as the default  "documented"
method of configuring themes for fvwm2.

I for one would be more then glad to convert my sites defaults to this
format, as it will really strengthen fvwm's offering.

Oh, and while I am makeing suggestions; Someone should really update the
"FVWM" at http://www.hpc.uh.edu/fvwm/ with a GIMP replacement! Maybe a
contest would be in order.... The old one was cool before script-fu.

Randall

---

From: Dan Espen <[email-masked]>
Date: Tue, 27 Oct 1998 08:39:43 -0500

> http://www.staticbomb.com/fvwm2gnome/

I recently checked themes.org, and liked the  themes I saw, however, I
wasn't totally satisfied with the way the themes are packaged.

I know this is  a hard problem, and  I don't mean to criticize anyone.
What  I would like is some  menu I could pop  up  and pick the theme I
wan't to use.  I think we are  a long way  from that.  The theme I saw
included a replacement   .xinitrc,   and introduced  a long   set   of
customiziations I would have to insert in my .fvwm2rc.

As fvwm2  stands today, its  shipping with some icons, mini-icons, and
Brady recently added  some   textures, and root treatments.    None of
these  are installed anywhere  by the installation  process.  They are
not even mentioned in the INSTALL file.

Sometime, post configure,  I   was planning  to upgrade the    install
process to at  least install some of  this stuff, probably in a  "lib"
directory.  The next  step would be to  build in some menus that would
configure some of this stuff in, automatically add the "lib" directory
to the pixmappath, etc.

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 27 Oct 1998 09:11:10 -0500 (EST)

On Tue, 27 Oct 1998, Dan Espen wrote:

: "Randall S. Winchester" <[email-masked]> writes:
: > 
: > I think hard consideration for a default method of maintaining "Themes" in
: > Fvwm2 ASAP is warranted.
: > 
: > There have been two reasonable starts that I have noticed;
: > http://fvwm.themes.org/
: > http://www.staticbomb.com/fvwm2gnome/
: 
: I recently checked themes.org, and liked the  themes I saw, however, I
: wasn't totally satisfied with the way the themes are packaged.

It has changed from "recently", infact it changed since I saw it last week!

: What  I would like is some  menu I could pop  up  and pick the theme I
: wan't to use.  

Fvwm2Gnome does this -- extracted from config/menus.config;

# This is used to create the dynamic themes menu
AddToMenu Themes "Available Themes"      Title
PipeRead "~/.fvwm2gnome/bin/ThemeMenu ~/.fvwm2gnome/themes"

AddToMenu Backgrounds "Backgrounds"        Title
PipeRead "~/.fvwm2gnome/bin/bgmenu ~/.fvwm2gnome/backgrounds" 

: As fvwm2  stands today, its  shipping with some icons, mini-icons, and
: Brady recently added  some   textures, and root treatments.    None of
: these  are installed anywhere  by the installation  process.  They are
: not even mentioned in the INSTALL file.

But they are just random, unoganized examples people have contributed over
time. There is currently nothing in the way of organized themes, as everyone
is configuring fvwm differently. 

: Sometime, post configure,  I   was planning  to upgrade the    install
: process to at  least install some of  this stuff, probably in a  "lib"
: directory.  The next  step would be to  build in some menus that would
: configure some of this stuff in, automatically add the "lib" directory
: to the pixmappath, etc.

I think if you spend a couple hours on the URL's above you will see there is
really alot there, or getting ther quicker then fvwm-workers will ever get.
We should embrace their work.

Randall

---

From: Dan Espen <[email-masked]>
Date: Tue, 27 Oct 1998 09:22:57 -0500

> We should embrace their work.

Absolutely, don't get me wrong, their work is  essential.  I just have
this crazy idea, I can take it a little further.

After  I sent   my  last mail,  I  checked   out the  stuff  with  the
"PipeReads", which  is a step in  the right direction, but there still
was   a  lot of stuff  to   add by hand  to  the  config file, and the
pipeReads are against "~/.fvwm2gnome/bin/" which requires each user to
install themes in a non-shared place.

Jason, could we install  some links from our home  page to these theme
sites?

---

From: [email-masked] (Paul D. Smith)
Date: 27 Oct 1998 09:23:25 -0500

%% Dan Espen <[email-masked]> writes:

  de> Sometime, post configure, I was planning to upgrade the install
  de> process to at least install some of this stuff, probably in a
  de> "lib" directory.  The next step would be to build in some menus
  de> that would configure some of this stuff in, automatically add the
  de> "lib" directory to the pixmappath, etc.

I would like to urge anyone considering this sort of thing to examine
the GNU standards.  I personally would like to see FVWM conform to this:
in particular, having sharable items like pixmaps, etc. installed into
${prefix}/share/fvwm2 so it doesn't have to be duplicated across
multiple architectures.

Technically, and I would prefer, all the modules would go into
${prefix}/libexec/fvwm2 as well, but I suppose that's not very
compatible with X hierarchies (although I don't install fvwm into my X
hierarchy, myself).  As long as the autoconf'd version keeps all the
proper variables, etc. I can override them to get what I want.
Typically only libraries (libfvwm2.a) belong in ${prefix}/lib.

When autoconf is installed I'll be happy to run it through "trial by
fire" for adherence to standard practice, etc.; I've been familiar with
autoconf/automake for a while, both to build packages and as an author.

I have much less familiarity with libtool but I think it would be great
if libfvwm was made more comprehensive and turned into a shared lib so
that all the modules and FVWM itself could share it; this would reduce
system load and libtool makes this easily portable.

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 27 Oct 1998 10:05:04 -0500 (EST)

: "Randall S. Winchester" <[email-masked]> writes:
: > On Tue, 27 Oct 1998, Dan Espen wrote:
: > 
: > : "Randall S. Winchester" <[email-masked]> writes:
: > I think if you spend a couple hours on the URL's above you will see there is
: > really alot there, or getting ther quicker then fvwm-workers will ever get.
: > We should embrace their work.
: 
: Absolutely, don't get me wrong, their work is  essential.  I just have
: this crazy idea, I can take it a little further.
: 
: After  I sent   my  last mail,  I  checked   out the  stuff  with  the
: "PipeReads", which  is a step in  the right direction, but there still
: was   a  lot of stuff  to   add by hand  to  the  config file, and the
: pipeReads are against "~/.fvwm2gnome/bin/" which requires each user to
: install themes in a non-shared place.

Yes, of course, looking in a site wide directory would be issential.
I agree it still needs more work, but having those two compatible and fvwm
also supporting this will make a strong driving force in the right
direction, and allow us all to gain from each other.

But if we are working on the same interface, we can move it along together.

: Jason, could we install  some links from our home  page to these theme
: sites?

Randall

---

From: Jason L Tibbitts III <[email-masked]>
Date: 27 Oct 1998 09:38:30 -0600

>>>>> "RSW" == Randall S Winchester <[email-masked]> writes:

RSW> Oh, and while I am makeing suggestions; Someone should really update
RSW> the "FVWM" at http://www.hpc.uh.edu/fvwm/ with a GIMP replacement!
RSW> Maybe a contest would be in order.... The old one was cool before
RSW> script-fu.

If someone hands me a logo, I will put it on the page.

If someone hands me another set of pages, I will replace what's there.

If someone wants to maintain the pages, we can work something out.

I have little free time left over after work on Majordomo and I'm terrible
at web pages anyway.

 - J<

---

From: "Andrew T. Veliath" <[email-masked]>
Date: Tue, 27 Oct 1998 12:54:47 -0500

.........----------------==================----
..--==-  Sun, 25 Oct 1998 18:53:21 +0100,
..--==-  Dominik Vogt (DV) discussed:

 DV)  I already am, believe me.

 )) ... (I DO remember a day has 24 hours!) ...

 DV)  You probably wouldn't believe me that I have no time at all to
 DV)  work on fvwm, wouldn't you? Most of the work I did was in the
 DV)  early morning hours and during three weeks I had been ill. And
 DV)  then there is my dancing partner and I'm sure the two kittens I
 DV)  get in a few weeks have other ideas how I should spend my scarce
 DV)  spare time. In other words: I would *love* it.

Well, if you do pick up as maintainer, I'd hope you open up CVS access
to give selective others write access (like we have in GNOME).  If you
choose not to maintain, I would also be interested in doing the
maintaining :-).

--
	Andrew

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 26 Oct 1998 17:13:39 +0100

> choose not to maintain, I would also be interested in doing the

As I said before, I do not want to do it indefinitely,
just up to the next release or two (although there are
so many things that should get done after that ;-) ).
I am already spending nearly half as much time with fvwm
as with my work - not a very healthy relation one might
think (and one would be right). But I am happy to see
the list busy again. It seems to have come finally out
of the lethargy of the last months.

Anyway, how about sharing the work between us two.
Perhaps this way the workload will be a little less.

Bye

Dominik

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 27 Oct 1998 13:17:34 -0500 (EST)

---

From: Jason L Tibbitts III <[email-masked]>
Date: 27 Oct 1998 13:22:09 -0600

>>>>> "ATV" == Andrew T Veliath <[email-masked]> writes:

ATV> Well, if you do pick up as maintainer, I'd hope you open up CVS access
ATV> to give selective others write access (like we have in GNOME).

I'll give CVS access to anyone who needs it.  Acceptance by the list
members is pretty much all that I require.

 - J<

---

From: Dan Espen <[email-masked]>
Date: Tue, 27 Oct 1998 14:31:43 -0500

> members is pretty much all that I require.

And... Andrew has been around long enough for my vote.

---

From: [email-masked] (Paul D. Smith)
Date: 27 Oct 1998 14:55:47 -0500

%% Jonas Luster <[email-masked]> writes:

  jl> The documentation is somewat .. ummm .. funny to read and there's
  jl> zero to none good additional in-deep-a-hacker-would-read docs to
  jl> refer to.

There are a number of docs and howto's available now, and the autoconf
developer's list is very active these days.  Autoconf has a new
maintainer (one of the big problems is that it's been languishing for
quite a while) and autoconf 2.13 should be available soon.

And in combination with automake and libtool (if you build libraries),
which are also increasingly active these days, you can do some really
great stuff without much work.  Automake is really nice; I converted GNU
make to use it and it's great.  Handles so much crap for you :-/.

A few sites to get you started:

  http://www.cygnus.com/~ian/configure/
  http://www.amath.washington.edu/~lf/tutorials/autoconf/
  http://peti.gmd.de/autoconf-archive/

As I've mentioned, I'd be happy to help with this.  I suggest the best
way to proceed is, as soon as we decide to incorporate it, someone merge
the existing autoconf stuff to the latest version, then folks like me
who do a lot of autoconf'ing and have some odd systems can shake it down
and provide lots of ... ah ... comments :) and patches to get it working
correctly.

---

From: Austin Donnelly <[email-masked]>
Date: Wed, 28 Oct 1998 10:16:00 +0000

> And... Andrew has been around long enough for my vote.

Indeed - Andrew has my support too.

Austin

---

From: Steve Robbins <[email-masked]>
Date: Wed, 28 Oct 1998 10:13:31 -0500 (EST)

> and provide lots of ... ah ... comments :) and patches to get it working

Well!

This sudden upsurge in interest in autoconf inspired me to merge the
autoconf changes into the current CVS sources.  I'm ironing out the final
build problems now, and it should appear on my website by this evening.

Since the autoconf stuff requires a *lot* of changes, it was technically
easier for me to incorporate the 2.0.46 --> 2.0.47 diffs into my
autoconfigured fvwm, rather than the other way around.  I did this by
pulling down the head CVS branch, and diffing it against the stock 2.0.46
upon which I based the autoconf'd version. 

Unfortunately, I had to apply several of the patch hunks by hand.  As a
consequence, all I can guarantee about this first autoconfigured 2.0.47
version is that it compiles on my systems.  Actually, I will likely only
have time to test on my linux box before upload.  

So don't download this and use it in production ;-)

Please DO download it, and at least try to compile it.  Send all comments
to me or to the list.

The 2.0.46 series of autoconfigured fvwm was successfully compiled -- and
is currently in production use by my lab -- on: linux 2, dec alpha, sunos
4, and IRIX 5.  I will run builds on these later this evening. 

Look for the full autoconfigured fvwm2 package on:

It will be there by 6PM EST today.

---

From: Brady Montz <[email-masked]>
Date: 28 Oct 1998 12:37:30 -0700

> without anyone being identified as the owner.

I think this would probably work.

-- 
 Brady Montz
 [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 28 Oct 1998 15:56:18 -0500

%% Brady Montz <[email-masked]> writes:

  >> without anyone being identified as the owner.

  bm> I think this would probably work.

I agree, although we might take a clue from the Perl5Porters: they have
one person in charge of each release; they rotate it among people who
volunteer.  That person, called the "pumpking" who holds the release
"pumpkin", is in charge for that release: he/she decides what the "goal"
of the release will be (e.g., for 5.005 it was integrating some thread
support), if any, and can choose to accept or reject any patches or
submissions.  Typically all bug fixes are accepted and most other
changes that aren't too sweeping will be, too, but the pumpking has the
final say.

That person accepts and integrates patches in the "mainline" branch and
creates test releases, accepts bug reports, etc.  They're responsible
for deciding when the release is "done"--from my perspective this has
been the single biggest problem with FVWM: no one seems to step up and
say "this is done enough, ship it!"  Getting _more_ releases out the
door is key in this kind of an environment, I think.

I think this is a good model; my worry with a pure group concensus is
that it'll never be agreed that the thing is "done enough".

Looks like Dominik is it for 2.0.47, at least.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Oct 1998 22:29:43 +0100

> changes that aren't too sweeping will be, too, but the pumpking has the

Thats an interesting idea and not a bad one. This way I might
have some private life again this year ;-) We will need much
better infrastructure however. Maintaining a buglist in a file
a things like this will make this nearly impossible.
 
> say "this is done enough, ship it!"

That is exactly the problem. The list has held it's
breath for too long while waiting for a decision from
the maintainers. That Brady didn't have enough time for
the job is perfectly understandable (personally I think
I will not stand the pressure very long) and noone has
the right to say something bad about him.

The list has to build up a driving force in the direction
of new releases! You all know how long it has been since
the last release; this *must* change. It would not be good
if this was all linked to a single person, it must come
from everyone on the list. In fact I believe it would be
ideal if I made myself superflous as fast as possible.

> Getting _more_ releases out the

dito

> that it'll never be agreed that the thing is "done enough".

Not just that. A group consensus will never be reached
becaus there is nobody who says that the consensus is
reached. Discussions in mailing lists tend to go on
forever, not because the people discussing were unable
or unwilling to stop. It is just the nature of this
medium.
 
> Looks like Dominik is it for 2.0.47, at least.

I will happily resign when we have found a good solution.
In the meantime I agreed to do the work until the end
of the year (which should be the same date as 2.0.48).

Bye

Dominik
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 28 Oct 1998 16:48:35 EST

> changes that aren't too sweeping will be, too, but the pumpking has the

Actually, there is one higher authority, Larry Wall, to whom anything
can be appealed. Having a final authority in the form of a single
person or a small officially declared standing committee is a good
thing - otherwise achieving final decisions can be painful/impossible.
 
 - Maciej

---

From: [email-masked] (Paul D. Smith)
Date: 28 Oct 1998 17:06:59 -0500

%% Maciej Stachowiak <[email-masked]> writes:

  ms> Actually, there is one higher authority, Larry Wall, to whom anything
  ms> can be appealed. Having a final authority in the form of a single
  ms> person or a small officially declared standing committee is a good
  ms> thing - otherwise achieving final decisions can be painful/impossible.

Yes, I know about Rule 1 :)

But I couldn't think of anyone to fill that bill, so I didn't mention
it.

---

From: Dan Espen <[email-masked]>
Date: Wed, 28 Oct 1998 20:59:46 -0500

> But I couldn't think of anyone to fill that bill, so I didn't mention

I think you are exactly correct in not mentioning it.
Since Rob doesn't seem to even participate in the mailing lists,
there is no direct comparision.

---

From: Steve Robbins <[email-masked]>
Date: Wed, 28 Oct 1998 22:51:57 -0500 (EST)

> changes that aren't too sweeping will be, too, but the pumpking has the

Interesting idea.  OK: I propose to be pumpking for the next release.  The
goal being autoconf.

I know Dominik has already laid out a timeline for future improvements.  I
think, however, that slipping in autoconfiguration BEFORE that has several
benefits:

(1)  The changes to actual source code are minor, so it is as stable as
version 2.0.47 is.

(2)  Having autoconf in NOW increases the pool of people willing to test
out future (possibly unstable) versions.

(3)  Using autoconf allows the use of sane #ifdefs, rather than the
current rats' nest.  This allows for code cleanup, and promotes
higher-quality code in future submissions. 

To expand on point #3: there is a good article by Henry Spencer and Geoff
Collyer -- the C-news guys -- called "Ifdef considered harmful".  It
should be required reading before starting coding.  I wish I had a
reference for it handy, but a web search should find it.  [I can mail out
a postscript copy to anyone who asks.]

I'd rather have one of your minutes
than a year with all the hours in it.

---

From: Steve Robbins <[email-masked]>
Date: Wed, 28 Oct 1998 23:44:37 -0500 (EST)

On Wed, 28 Oct 1998, Steve Robbins wrote:

> reference for it handy, but a web search should find it.  

Whoa -- it turns out to be hard to find with a simple web search.  After
much effort, I did track down this paper.  You can find it at:

	http://x.bell-labs.com/user/geoff/ifdefs.ps.Z

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 29 Oct 1998 09:10:29 +0100

Since my first proposal for a plan we have had lots of
discussion about how to proceed in the next weeks.
This reflects in an updated version of the original
plan (comments and improvements are very welcome).

But first some words on organisation:

- There is a discussion going on on about the right way
  fvwm should be maintained. I want to stay out of the
  discussin because I have no experience with this and
  in the end the list members must be happy with the
  outcome, not me. As soon as an agreement is reached
  I will happily step down from my current job.

- Before that has happened I am willing to continue
  the work until 2.0.48 (according to the plan below).

- The development is in dire need of some decisions at
  the moment. I find myself writing emails all day and
  writing/debugging not a single line of code, but that
  is probably the more important thing now. Meanwhile
  others have to take the responsibility to do the
  'real' work. Dan cannot do everything alone.

- I will post a to-do list with the most important
  things that have to be done before the next release.
  Additions and comments will be welcome, of course.

Now the plan:

1) [DONE]
   The menu_postition branch has been created and is
   already dead. The new 'main' branch is
   animicons_menupos.

2) [until 11-03-98]
   The animicons_menupos branch will become the new
   2.0.47e. Should this just a label for the branch or
   should it go to the main branch?

3) [until 11-03-98]
   Steve or someone else creates an autoconf branch from
   47d. Can you do that, Steve? Steve told us the merging
   was already done, so a new branch is trivial.

3) [until 11-09-98]
   The autoconf stuff is merged into 47e and after a little
   testing will be labeled 47f. This reflects the high
   interest for autoconf on the list.

4) [until 11-20-98]
   Germans patches are merged into 47f which becomes 47g.
   Germam has requested a delay of one week, so this step
   has moved down the list a little.

5) [after 47g until 11-27-98 (I hope German will be
   ready before 11-20)]
   Merge in the hosts of smaller patches that accumulated
   over time and label the resulting code 47h.
   Note: I had a beta phase for the list only on the first
   draft of the plan, but Dan convinced me this is of little
   use.

6) [21-11-98]
   An oncoming official beta test starting on 28-11 is announced
   to the fvwm list. Should inform/invite major Linux
   distributors of/to the tests?

7) [28-11-98, until 12-16-98]
   The beta test starts on 28-11-98 and continues for about
   three weeks. Me must definitely have a working bug tracking
   system then.

8) [until 12-23-98]
   As soon as possible after the beta test we make the fixed
   47h the new 2.0.47. The new version is announced to the lists
   (and Linux distributrs?).

9) [12-24-98]
   Everyone leaves for their xmas holidays ;-)

I have cancelled my original plan to make 2.0.47 the version
for the beta test and put the fixes into 2.0.48. Although
fvwm2 is announced as being beta since the stoneage ;-)
people are used to the high quality of the 'beta' releases
and might not forgive a buggy version easily.

One final word:

Although everyone is invited to improve/modify this plan
I will try to stick to it as long there are no better
plans/ideas. This is not because I want to stifle
discussions but to go ahead to the new relesa fast.

Bye
   
Dominik

---

From: Dan Espen <[email-masked]>
Date: Thu, 29 Oct 1998 08:31:43 -0500

>   I will happily step down from my current job.

Everyone's opinion is valid, I  see no reason for  you to stay out  of
any discussion.  I hope to show we can work together even when we have
disagreement.  I hope  you haven't taken  something I've advocated  to
mean I object to you trying  to set direction.  As  long as I can make
my contribution, I'm going  to go along with   everyone else making  a
contribution.

>   'real' work. Dan cannot do everything alone.

It might help if you just don't  answer mails while  you are trying to
code.  I always put coding first.

>   Additions and comments will be welcome, of course.
...

Its nice that you have set dates for when you would like to see things
happen, but bear in mind that this  is volunteer work.  Its bad enough
my boss expects me to complete projects by a certain date.

I can only contribute  to this project when I  have the time, I  can't
commit to meeting any deadline.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 29 Oct 1998 15:02:38 +0100

> my contribution, I'm going  to go along with   everyone else making  a

I have taken no offense by anyone and we all need the
discussions and I am grateful for your constant (and
highly qualified) input. Sometimes a decision has to
be made though and discussing a minor detail is not
worth a week.

> code.  I always put coding first.

Until we have everything organised smoothly mailing
will probably come first. There are still the weekends when
I cannot write email ;-)

> commit to meeting any deadline.

Ah, no, the dates are not planned as deadlines. It's ok by
me if we do not meet any of the dates. See it more as a point
of reference for whoever wants to know what is going on.
Myself I won't have 40 hours a week to spend for fvwm
forever.

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Thu, 29 Oct 1998 09:46:21 -0500 (EST)

Hi,

>    was already done, so a new branch is trivial.

I will put autoconf into CVS as soon as I get a password.

I will argue, however, that we should move away from labelling versions
with a letter suffix.  There are already three components to the version
number ("x.y.z") which is more than enough.  Why don't we adopt
conventions similar to the linux kernel, where the parity of "y" denotes
whether the version is "stable" or "beta"?  (The current head of the CVS
tree would be always considered "alpha") 

So, rather than an endless stream of 2.0.47{a,b,c,...}, we label them .48,
.49, etc.  There's no reason to fear large numbers: the linux kernel, for
example, has well over a hundred patchlevels of 2.1.  Once some kind of
consensus is reached on what should be announced to the world as the next
"stable" release, we rename it 2.1.0, release a tar file, and commence
work on 2.2.0.

This was one of the things Brady M. announced he would be doing, although
as I recall, he wanted to mark the next stable release as 2.2.0, to keep
to the linux convention that even "y" is stable, and odd "y" is beta.  I
don't particularly care which parity convention is used.  We can skip to
2.2/2.3 if people so desire.

Now, with that in mind, I will propose that the next stable release be the
current 2.0.47 + autoconf.  The reason is simply that it has been WAY TOO
LONG since a "stable" fvwm has been out.  

In fact, there has NEVER been a non-beta fvwm2.  Consequently, the labels
"alpha", "beta", and "stable" have slipped.  Everyone has been using a
"beta" 2.0.x for years as the "stable" version.  Meanwhile, the patches
("alpha version") floating around this list were never collected and
published by the maintainer as a beta version.  Presumably, this is
because he knew it would be picked up as "the new fvwm2", and it wasn't
ready for release.  Since there WAS NO "stable" version, the ability to
say "this is a beta version" was lost. 

Since 2.0.4x has already long been used as the stable version, let's just
release it as such.  Meanwhile, the basic autoconf support is available,
so let's put that into a released version, too.  

----------------------------//---------------------------------

So the way to use CVS as I understand it:

(1) The CVS sources are always considered "alpha" unless labelled
otherwise.

(2) Someone is elected from the list to maintain the head of the main
trunk.  This person has a specific task in mind: integrate feature X, code
freeze for a major release, etc.  When this goal is achieved, the version
is labelled (i.e. "cvs tag") with a new number, and the maintainer
rotates.

(3) Both "beta" and "stable" releases should be tarred up and left for
download by the masses.

(4) Bugfixes for the current "stable" release will be checked into a
branch of CVS as necessary. 

----------------------------//---------------------------------

In this model, I propose to temporarily maintain the head branch,
integrating autoconf support, with a goal of producing a "stable" release
in a couple of weeks.  After that, I will happily take bug reports about
autoconf and maintain a stable branch for some time.  Meanwhile the real
"beta" work progresses on the main trunk of CVS, with someone else ---
Dominik is the obvious choice --- as maintainer. 

As far as the rest of Dominik's detailed plan, I concur with Dan E's
caution about putting deadlines on volunteer projects.  I really like the
"pumking" model, with the proviso that the "goal" for each pumpkin be
reasonably small.  Something achievable on the scale of 2-4 weeks, say. 
But there's no reason not to have the same "king" many times in a row.  So
Dominik might use all his objectives as the successive "goals" for the
coming series of betas. 

> and might not forgive a buggy version easily.

Indeed.  However, rather than be stifled by this slippage of
"beta" --> "stable", let's take the opportunity now to release a real
"stable" version, and make "beta" really MEAN "beta".  (And CVS means
"alpha" :-))

>From my experience, a slow development cycle bores a lot of developers, so
they go elsewhere and the cycle grinds to a halt.  With CVS, development
can speed up: putting in experimental code is less risky, since it can be
easily rolled back, assuming frequent checkins.

If mashed potatoes were security guards, they wouldn't get much done.

---

From: [email-masked] (Paul D. Smith)
Date: 29 Oct 1998 16:00:14 -0500

A great job with this, Steve!  I found almost no configuration problems
so far on my SunOS and Solaris builds.  I'll try HP-UX and AIX, and
maybe DEC Alpha, next.

A few little nits:

 *) I'm not sure I like the package name being "fvwm2".  I think it
    should continue to be "fvwm".  I think it's a good idea to continue
    to make the executable name "fvwm2", but I see no need to make the
    module directory path contain "fvwm2", for example, if you're going
    to put a version directory below it anyway.

 *) On my system libraries like readline are in "non-standard" places.
    Many autoconf packages these days are including options to add extra
    include directories and/or libraries to the standard search rules.
    I've started a dialogue on the autoconf maintainer's list about
    making this a standard feature but you might consider it before
    that.  Alternatively you might document how to use CPPFLAGS and
    LDFLAGS in the environment to do so:

      $ CPPFLAGS=-I/other/dir/include LDFLAGS=-L/other/dir/lib ./configure ...

 *) I prefer to keep the standard header file name "config.h" rather
    than use "configure.h"--the former is what everyone will expect.

 *) utils/xpm-reduce.c doesn't compile on SunOS, because SunOS doesn't
    define EXIT_FAILURE, etc.  This patch fixed it (I know this is not
    really an autoconf problem, but ... :)

--- utils/xpm-reduce.c-dist     Thu Jan  8 16:56:21 1998
+++ utils/xpm-reduce.c  Wed Oct 28 16:44:41 1998
@@ -49,6 +49,10 @@
 #include <stdlib.h>                     /* for exit */
 #include <X11/xpm.h>                    /* XPM stuff */
 
+#ifndef EXIT_FAILURE
+# define EXIT_FAILURE 1
+#endif
+
 struct rgb_s {
   int r;
   int g;

 *) In the resulting Makefiles, I see:

      FVWM_CONFIGDIR = ${prefix}/etc
      FVWM_MODULEDIR = ${exec_prefix}/libexec/fvwm2/smr-2.0.47.1

    I think this should be:

      FVWM_CONFIGDIR = ${sysconfdir}
      FVWM_MODULEDIR = ${libexecdir}/${PACKAGE}/${VERSION}

    I think the problem is in configure.in you write:

      FVWM_MODULEDIR="${libexecdir}/${PACKAGE}/${VERSION}"
      FVWM_CONFIGDIR="${sysconfdir}"

    but note that double quotes aren't strong enough: they still allow
    shell variables to be expanded in the configure script, rather than
    treating the values verbatim.  You should change to single quotes:

      FVWM_MODULEDIR='${libexecdir}/${PACKAGE}/${VERSION}'
      FVWM_CONFIGDIR='${sysconfdir}'

    That should do it.

PS. I think we should add an item to the TO-DO list, perhaps grouped
    with the current "clean up libfvwm.a and make it more useful" item,
    which is to incorporate libtool and build a shared libfvwm.so.  It
    would be _great_ if fvwm2 and its modules all shared a library and
    could be that much smaller.

---

From: Brady Montz <[email-masked]>
Date: 29 Oct 1998 14:57:11 -0700

> 	http://x.bell-labs.com/user/geoff/ifdefs.ps.Z

Awesome! I happen upon this paper by accident in some journal or other in the
U of AZ library, and since then I've been wishing that I could remember where
it was. I really recommend reading this paper.

---

From: [email-masked] (Paul D. Smith)
Date: 29 Oct 1998 17:01:04 -0500

One issue with the new directory layout: if we change where the modules
live with every release it's going to get a bit ugly, since everyone
will have to remember to change the modulepath in their .fvwm2rc, or
else continue to use the old modules.

I think this is a big problem just waiting to happen.

I think it would be nice if there were a way to reference the builtin
module path from with your .fvwm2rc file; maybe something like:

  ModulePath  /my/module/path:+:/another/module/path

Where "+" stands for the compiled version.  That way people can add new
module directories to the path but still allow upgrades to fvwm2 to pick
the modules for that version.

>From an autoconf perspective, I also think that all the system.fvwm2rc
files in sample.fvwmrc should be replaced with .in versions, and the
configure step should substitute the FVWM_MODULEDIR path for the
ModulePath setting--there may be other things that should be substituted
here, too.

Also, if some way of taking the default in ModulePath as I describe
above isn't implemented, then I think the ModulePath setting in the same
config files should be commented out to discourage people from copying
them into their .fvwm2rc files.

---

From: Steve Robbins <[email-masked]>
Date: Thu, 29 Oct 1998 17:30:04 -0500 (EST)

> so far on my SunOS and Solaris builds.  I'll try HP-UX and AIX, and

Thanks for testing!

I might mention also that after my initial message yesterday, I did run
builds successfully for SunOS 4, and DEC OSF/1.  All the platforms I
tested yesterday had gcc and gmake.  However, I have built the
autoconfigured 2.0.46 with the native compiler on the DEC. 

>     to put a version directory below it anyway.

Ah, good point.  I will change the package name back.
 
>     include directories and/or libraries to the standard search rules.

You mean like '--with-xpm-includes='?  ;-)

./configure --help
  [ ... ]
  --with-xpm-library=PATH   use xpm library (for coloured or shaped icons)
  --with-xpm-includes=DIR  set directory for xpm headers
  --with-rplay-library=PATH   use rplay library (adds audio capability)
  --with-rplay-includes=DIR  set directory for rplay headers
  --with-readline-library=PATH   use readline library
  --with-readline-includes=DIR  set directory for readline headers

>     that. 

Or do you mean a more generic "--with-local-{library,includes}" flags? 
That was my first thought when I started this.  I and another guy argued
for this as a standard autoconf feature last year on the automake list. 
We got voted down, with what seemed to be reasonable objections.  I can't
recall all of them just now, but if you're interested, I think the
automake list has archives. 

>     Alternatively you might document how to use CPPFLAGS and

Yeah, well that is sorta documented, in the standard INSTALL file.  I
could put it more prominently in the INSTALL.fvwm, if that's what you're
suggesting. 
 
>     than use "configure.h"--the former is what everyone will expect.

Sounds reasonable.  

I was initially aiming to make as few changes to the sources as possible. 
However, if it be the will of the list, then "find" and "sed" should take
care of changing "#include <configure.h>" to "#include <config.h>" in all
the sources... 
 
>       FVWM_CONFIGDIR='${sysconfdir}'

OK, thanks.
 
>     could be that much smaller.

I agree.

---

From: Steve Robbins <[email-masked]>
Date: Fri, 30 Oct 1998 09:16:23 -0500 (EST)

> I will put autoconf into CVS as soon as I get a password.

I now have commit privileges for the repository.

I'd like to hear some thoughts about my plan to put autoconf directly on
the main trunk NOW, and label it version 2.0.48.

If there are no objections, I'll do it this weekend.

A man came up to me and said, "I'd like to change your mind,
by hitting it with a rock," he said, "though I am not unkind."

---

From: Steve Robbins <[email-masked]>
Date: Sat, 31 Oct 1998 01:29:34 -0500 (EST)

> +++ utils/xpm-reduce.c  Wed Oct 28 16:44:41 1998

I got email from Dan E about this later.  He claims that xpm-reduce is old
code, made obsolete by a "colour limiting" patch or something.

The suggestion is to ditch xpm-reduce entirely.  Objections?

I was looking back to see
if you were looking back at me
to see me looking back at you.

---

From: Austin Donnelly <[email-masked]>
Date: Sat, 31 Oct 1998 20:14:09 +0000

> The suggestion is to ditch xpm-reduce entirely.  Objections?

The colour limiting patch is one of the more frequent feature requests
I get asked to include in Debian's fvwm2.

Austin

---

From: Dan Espen <[email-masked]>
Date: Sat, 31 Oct 1998 15:44:27 -0500

> I get asked to include in Debian's fvwm2.

xpm_reduce was my first attempt to limit colors.  To use it, you would
have to run every  icon you use thru  xpm_reduce and use the  modified
icons.

The color limiting patch does something similar, but at run time.  You
just tell  fvwm2, I want  to use "nn"  colors in icons, and the pixmap
display logic finds close matches  for the colors  in the pixmaps  vs.
an internal table.

I would say, we should take Austin's response, as  he has no objection
to the removal of xpm_reduce.