>>>>> "GJGG" == German Jose Gomez Garcia <mat006_at_pinon.ccu.uniovi.es> writes:
GJGG> On Mon, 18 May 1998, Steve Robbins wrote:
>> On Mon, 18 May 1998, German Jose Gomez Garcia wrote:
>>
>> > Well, after a long long time without having seen any improvements
>> > in the great fvwm2 I have decide to take up the task, but it will have
>> > a cost, I have reindented the full source (using indent -kr -bli0 -bl), so
>> > patches are not a good way to distribute it (last was greater than the code
>> > itself :).
>> > My question is simple, is anybody working on fvwm2 now?
>>
>> Yes: Charles Hines.
>>
>> > if yes what are his goals?.
>>
>> My advice: check the archives of this list for his posts.
>>
>> > If nobody answer, I will start a new series in the fvwm2
>> > development (maybe something like 2.0.46.x :), and start to put patched
>> > versions at Adam Kopatz site, I would include most of the patches most
>> > commonly used (as FvwmPager Ballons, fvwmpython interface, etc...), so
>> > I asked the authors of this patches to contact me (I'm not going to repeat
>> > already done code :)
>>
>> Well, Charles Hines is actively maintaining fvwm2.
An admittedly lethargic active development though...
>> I'm sure your intentions are good; however, a post like yours might
>> seem like an attempt at a "hostile takeover" to some people. I
>> wonder if a more cooperative approach would work better.
Yes, that original post aggrivated me quite a bit at first, but then I
realized that I was really more upset with myself for not having
enough time to do the work on fvwm that I really wanted to. So I've
come to a decision, which I'll outline below...
>> That said, I've been wishing for a long time that the speed of development
>> be increased. I've considered proposing a "linux style" dual tree: one
>> stable branch and in parallel, a rapid development branch. Charles Hines'
>> develops in the "cathedral" style, well-suited to maintaining a stable
>> branch. The only reason I haven't proposed a dual-tree development to the
>> list is that it would need someone with a lot of time to manage the
>> development branch, and I don't have this amount of time.
I've had many people write me (both on the mailing list and directly)
citing that same cathedral/bazaar paper:
http://earthspace.net/~esr/writings/cathedral-bazaar/cathedral-bazaar.html
It's not that I was deliberately choosing the "cathedral" method of
development, but I just didn't have enough time to truly do a more
frequent development cycle. I really wanted to (eventually) get a
good 2.1.0 version out, and then start dual stable & development
paths. As you can see, I haven't quite made it there yet.
>> Whatever you do, please please *please* use the autoconfigured version of
>> fvwm 2.0.46, which you can find at:
>>
>> http://www.cs.mcgill.ca/~stever/software/fvwm/
GJGG> Sorry if it seems so, but I only want to cooperate with you in
GJGG> the development of such a nice wm, but I wasn't subscribed to
GJGG> fvwm-workers list, so don't now anything about active
GJGG> development, I by no means want to seem a "hostile-taker",
I was hoping that was the case.
GJGG> on the contrary, but as the WEB Page doesn't get updated for a long
GJGG> time,
Several months between updates has been the norm for me for the past
couple of years, unfortunately, so I'm not sure that I would consider
5 months to be a "long" time considering that...
GJGG> I just think fvwm2 developer team has switched over to scwm, I
GJGG> know now that things are not so bad, many people are still
GJGG> working on it!, I would apply the changes to your version (the
GJGG> one with autoconf), and submit it to Adam Kopaz to be include in
GJGG> his page.
Please hold off on putting another fvwm pseudo-distribution out
there. It really confuses things...
GJGG> Any more info appreciated (mainly more patches I must include)
Ok, more info (and the decision I mentioned above):
As of today I'm giving up being fvwm's maintainer. Unfortunately I've
finially decided to face facts and accept that I don't currently have
anywhere near the amount of time to devote to fvwm that it should
probably have. It was a painful decision, but probably for the best
(besides, I guess I can still submit ideas and patches periodically).
I wish to thank everyone that has helped out, submitted patches &
ideas, or just plain used fvwm over the years that I've been involved
with it, especially the folks on the mailing lists.
In the not so distant past I spoke offline with Brady Montz, and I
asked if he might like to take over maintainership from me when I was
ready to give it up, as I felt that he was one of a few good
candidates from the mailing lists and that he might have more time to
devote that I do. At the time he said he was interested. After I
made my decision this morning, I wrote him again to ask if he was
still interested, but unforutunately haven't heard back from him yet.
I really wanted to hear back from Brady first before I wrote anything
to the mailing lists, but decided that I should speak up before too
many messages flew back and forth without my input (hope you don't
mind, Brady). In the event that Brady has changed his mind and
doesn't want to (or can't) take over, I'm sure we'll be able to find
someone else. I'll be sure and announce when this is all decided.
So, what's next? Well, I'll hand over my current development snapshot
to the next maintainer after that's settled and they can start with
that or just toss it out and start with 2.0.46, whichever works out
better for them. Then we'll see where they drive it...
My parting thoughts on the future of fvwm:
- Please try and keep the base code lightweight, standalone
(ie - minimal external code usage beyond Xpm), and as
generic as possible. Granted, it still needs more cleanup.
- The configuration language definitely needs some more
improvement, but I don't think I quite agree with adding an
extension language like Guile, Tcl, Python, etc as I think
they are all overkill. Just my 2 cents on the subject since
I was out of town and unable to respond when this thread
came up again recently.
- The current module interface needs more work as well, and
should probably be encapsulated in another little lib to be
shared amongst the modules as much as possible.
- Dynamically loaded modules that use hooks into existing fvwm
routines to make for tighter integration is probably worth
looking into. That'd probably help with modules being able
to muck with decorations, multiple language interpreters,
etc.
I could probably put down more, but I guess the TO-DO list and the
notes I keep in my local development ChangeLog already cover all this
and more...
That's enough rambling for now I guess. Please be kind and
understanding to the next maintainer. It's been fun.
Thanks,
Chuck
--
*******************************************************************************
Charles K. Hines <chuck_hines_at_vnet.ibm.com>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis and Balintawak Escrima]
"Go back to sleep, Chuck. You're just havin' a nightmare
-- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon May 18 1998 - 15:28:12 BST