From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-03 12:17:43
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> David Abrahams wrote:
> > In order to be responsible to the three groups just
> > mentioned, we need a development plan with targets that we stand a
> > chance of meeting, and we need to make consistent, steady progress
> > towards our goals. We must do this, or fold up the project and leave
> > these people to find their own solutions.
> This is pretty strong statement,
I realize that, but the situation is getting to be critical, IMO.
> but since nobody is really going to "fold
> up" anything I won't comment on it.
...and you almost managed not to ;-)
> I don't think that development plan is the problem, at least m1 is
> clear for me. I think the problem is that we develop too slow. I don't
> why, precisely.
We're all volunteers on this project, so that's got to be part of it.
> But maybe:
> 1. We should all be fluent with all the codebase. I'm not sure that
all of us
> understand all the code. At least the core modules must be
I'm certain I don't understand everything, still. I'm still struggling
with project.jam, for example. Part of the problem is stylistic, I
guess. Some of the stuff I'm having trouble with:
Wouldn't $(project-id).location be just as good? The extra reading makes
What is the relationship of this variable to the earlier one? Is there
really any reason to have both?
I've already mentioned this several times, but redundancy in long names
can be a real problem for comprehensibility (mine, of course).
would be a small improvement.
> 2. We should have todo list with well understood items and
> somebody should be assigned to each item.
Agreed, except that I think it's only neccessary for any person to have
one assignment at a time. If m1 is clear to you, I suggest that you
compose the initial todo list and enter tracker items at SourceForge;
you can also clear out the old tracker items. I can try to knock of a
single item per day.
> Yes. Actually, I always try to run tests before comitting and look
> "cvs diff" output. Would it be reasonable that anybody finding
> obscure/untested code just post a notice about that?
Yes, although I don't think each of us should have to be vigilant about
reviewing everyone's checkins to vett them for clarity. One thing I know
slows us down is the cycle of requests for clarification (I realize that
some of this is unavoidable as I am, I think, the only native English
speaker among us). It's always more efficient for an author to invest
effort in concision and clarity up-front. I think that establishing some
common coding conventions and idioms will help this quite a bit.
> > It seems clear to me that the user should have a clean module scope
> > which to write Jamfile and project-root definitions, and that an
> > associated class instance should be used for all of the
> > build-system-specific definitions (print, etc.). The associations
> > be stored, for example, in globals of the project-root module:
> > $($(project-root-path).target-object)
> > [or something]. I thought that was already decided, though:
> > http://groups.yahoo.com/group/jamboost/message/734
> This was discussed, but never decided. We can change it later, when we
> implement associating project targets with project modules and
Until something is done to clarify what's going on in these modules, I
am probably not going to be fluent with them, though.
> > Again, this may not be a root cause of anything, but it's something
> > can put my finger on. My sense of the situation is that we need to
> > to react more quickly to feedback about the code we check in, so
> > the CVS is always relatively healthy: tests should pass, code should
> > easily understandible, there should be little or no duplication of
> > functionality, and no code implementing functionality which isn't
> > somewhere in the system.
> Yes. Do you suggest reviwing other's commits. That could be a good
> we'd need some automatic notification. (cvs watch happenned to be just
> terrible in practice, maybe commit emails will turn out to be better).
I guess that might be neccessary, but I want to quickly get to a stage
where we can avoid it most of the time.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk