Re: [jamboost] Feedback from Boost Meeting

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
quite
> clear for me. I think the problem is that we develop too slow. I don't
know
> 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
well-understood by
> all.

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:

$(project-id).jamfile-location

Wouldn't $(project-id).location be just as good? The extra reading makes
things difficult.

__jamfile-location__

What is the relationship of this variable to the earlier one? Is there
really any reason to have both?

targets.create-abstract-project-target

I've already mentioned this several times, but redundancy in long names
can be a real problem for comprehensibility (mine, of course).

targets.create-abstract-project

would be a small improvement.

> 2. We should have todo list with well understood items and
preferrable,
> 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
throught
> "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
in
> > 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
could
> > 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
declaring main
> targets.

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
I
> > can put my finger on. My sense of the situation is that we need to
try
> > to react more quickly to feedback about the code we check in, so
that
> > the CVS is always relatively healthy: tests should pass, code should
be
> > easily understandible, there should be little or no duplication of
> > functionality, and no code implementing functionality which isn't
used
> > somewhere in the system.
>
> Yes. Do you suggest reviwing other's commits. That could be a good
idea, but
> 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.

-Dave