These are just some ideas that've been bouncing 'round my head lately:
1) I have now been working as a software developer for over a month
now, and can code C++ well.
2) At work, we use CVS. Now, CVS can handle a "main development
trunk" as well as branches.
This completely cures all of the old concerns about having two
parallel development trees for LyX. We maintain a single branch
--- the equivalent of the old developers' releases --- and, when
things stabilize, merge onto the main trunk. At that point, we'd
do a new public version/release.
At the same time, bugfixes and minor changes could take place on
the main trunk. These chagnes could be periodically merged into
the development branch.
I assume this is what y'all are currently doing for LyX.
At some future time, we may want separate development branches for
the GUI, the kernel, etc...
3) Modularity.
If we want GUI independence, we need to make LyX far more modular
than it has been. This has been discussed before, and leads me
to the idea of....
4) Design Specifications
Guys, we *need* to come up with this.
To quote a coworker, "There's always time to fix it over and over
but never time to do it right once." With all of the plans we
have for LyX, we need to do it right the first time. It becomes a
lot easier to code and to bring new people on board if we sit down
and put together a plan for what LyX should look like. No, I mean
a *real* plan, one that's practical, well-formulated, detailed, and
--- most importantly --- *realistic*.
If we write the design spec. well, we won't need to make major,
earth-shattering decisions all at once. Example: we want GUI
independence from the kernel. Question is: how should the two
communicate with one another. This is a *detail*. If we had a
better idea of the overall design of both GUI and kernel, we could
use *anything* *at* *first*. The design spec. --- if well made
--- would permit us to easily switch to, say, RPC between
separately running GUI and kernel processes.
This is why you write design specifications: NOT to figure out
what code needs writing, features need implementing, etc., BUT to
figure out, at a high level, what the thing needs to look like.
This is something we could go back to again and again, and that
new devvies could go to for info.
Now, I've been meaning to put together a proto-design-spec for a
while now, but I have 3 hrs of driving I do each day in addition
to my 9+ hr. work day. I will see what I can do in the next few
weeks. If someone could point me to pre-existing info, that'd be
great.
--
John Weiss
