Brady Montz <bradym_at_cs.arizona.edu> writes:
> "Charles Hines" <chuck_hines_at_VNET.IBM.COM> writes:
>
> > 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.
I'm sorry that I've been harsh to chuck in late '96, when I wanted to speed
up development. He wasn't ready to pass on the torch, then and he still has
not enough time to review all that patches and still do own modifications.
> I've had to think about this a bit since it's quite a time commitment, but I
> think I'm willing to do it. I'd want to look into a way of splitting the
> development between among a small group of people, perhaps with a public CVS
> source tree with all checkins to be approved by me. Does anyone have
> suggestions along this line?
yes: try do a complete split & reindentation of the code as fast as
possible, so that work can begin.
I'd like to have a more methodically split: e.g: menu code was spilled over
several files in 2.0.43-45, don't know of .46
Indentation is pretty bad, since people had to keep the patches small
(diff -w is no good for indentation)
To get rid of the patches-backlog, you should get development up & running
as fast as possible, with a quick brushed up release as a basis for all
those patches. (don't try to first include gazillions of patches that were
for 2.0.43 to .45)
Then you should ask the authors of the most important patches to redo them
for that release. Then you can quickly select / apply those.
I don't think they'll be offended, if they have to redo a patch once and
then have it included.
Many of these patches have been re-done several times, because they didn't
make it into .41, then they didn't make it into .42 and so on.
After this catchup on the patches backlog, most of the "I detected a bug in
2.0.46" -> "Yes it's been there since 2.0.39, use this workaround" traffic
on the lists should cease, leaving more time to fiddle with code.
Then we can focus on the unknown bugs and enhancements.
BTW:
we should still finish the discussion, wether we want
1) a new language / languages ??
2) export fvwm's data & special functionality
3) reinvent the wheel while adding one feature after the other to
the existing language (delay ?).
I already posted an idea to have fvwm-core without any language, but just a
bytecode interpreter (maybe with a callout for unknown opcodes).
The syntax-analyzer / semantic parser would be a standalone program
producing bytecode output, being piped to fvwm.
We could even have different ones.
Modules would also output bytecode -> no redundant syntax & semantic
checking.
The bytecode interpreter (i.e. most of current functions.c & builtins.c)
would be a shared library which can be unloaded (swapped out !), when all
configuration is done and no functions have been defined (minimal user).
We could even split the language into a startup config part (always
unloaded) and a dynamic executing part (functions)
this is all some sort of brainstorm, so don't hesitate to comment, ask for
elaboration, etc ...
I also hope you don't mind the intermixing of we / you. I tried to use "you"
for things only You (as the maintainer) can do, and "we" for things we can
do as patches, that can be included fairly easy, when there's a comon base
for patching. (2.0.46 ?, 2.0.46 autoconf, what versions else do exist now)
Maybe we can re-acquire some spin-offs or borrow / lift some code there ?
--
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
Hi! Darren's answering machine is broken. This is his refrigerator.
Please speak very slowly, and I'll stick your message to myself with
one of these magnets.
-- answering machine message
--
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 Tue May 19 1998 - 06:25:53 BST