|
Boost : |
From: Rob Stewart (stewart_at_[hidden])
Date: 2004-10-26 13:29:22
From: "Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]>
> Jody Hagins wrote:
> > I believe I could have contributed in a non trivial manner to several
> > reviews. However, by the time I see the announcement, download the
> > materials, go through them, and try to keep up with the current
> > comments, the review is over. I am so busy with work, family,
> > coaching (American) football, and other activities, that the review
> > periods
> > usually seem too short (for me, at least).
>
> This is also true for me. However, I think the review periods do not
> necessarily have to be extended. What has to be extended is the
> timeframe in which there will be no significant changes (interface &
> docs) to a candidate library. Libraries sometimes go through extensive
> changes right before the reviews start, which is probably the reason why
> people don't have a look beforehand. Maybe the review process should
> mandate a no-interface-and-docs-changes period of one month before the
> actual formal review starts, with announcements when this period begins?
Time is always a problem, and we most definitely need time to
evaluate new libraries. The question is, when should the time
be invested?
I first notice new libraries when their formal review is
announced. I may well have been part of design discussions along
the way, but I won't have stopped to read through the
documentation or code before the formal review. Thus, one or two
weeks to do that and be part of an ongoing, often raging,
discussion about the new library is demanding.
To require N favorable reviews of a library before it can be
submitted for list-wide review is questionable only because so
much time will have elapsed between those reviews (due to the
current backlog). Granted, you want to know that more than just
the author think the library is good before putting it before
the list, so such reviews seem obligatory.
Perhaps the answer is that N reviews must be garnered for a
library to be reviewed, and the formal review period can begin
almost immediately thereafter -- subject to throttling. Then,
there could be a review period of, say, a month, following which,
the review manager can summarize the activity and determine
subsequent actions.
Yes, reviews can be really long that way and, as has been said,
the code and documentation must not change during that period
(though the author can, of course, maintain a separate
development version as the review progresses). However, it would
enable more people to review the libraries and would enable
deeper reviews when warranted.
The obvious problem is the number of simultaneous reviews that
could be ongoing at a given point. I think that will only prove
to be a problem initially as there are many libraries queued to
be reviewed. Once the backlog is gone, there won't be so many
new libraries to come on the scene as to make the review task
onerous.
Having more simultaneous reviews might be easier for some, too,
as they might have a particular day available to conduct reviews,
so several could be hammered out that day. With the current
state, one can only conduct a single review on such an occasion.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk