vicente.botet wrote:
I don't know if these dependent libraries should be removed. Maybe it is worth to state cleary in the page why the review is not yet scheduled.
I think you're right.
- The library author does not have the time for review. In that case, the library should also be removed from the list, because Boost is not responsible if the author is busy. - The review manager does not have the time for review. In that case, he should not be listed as assigned, and should not block others.
There is a particular case for the Boost.Log, which has a review manager but that links yet to the version that was rejected.
Just to clarify -- you mean Boost.Logging? There's Boost.Log as well, which is accepted (provisionally). It would be nice to sort out Boost.Logging situation, indeed.
Can we set a policy that:
- A library can only be added in the review schedule if the author has time in near future to have a review, where near future is, say, 3 months.
IMO this was already the case. the author can be ready but without review manager.
- A review manager is only assigned if a review date is set at the same time, where the date should be in near future -- say, 3 months again.
I would say that the author and the review manager must set a date in the near future, let say 3 months and that this date must be in the near future, let say 3 months.
IMO, a library that has no review manager before let me say 6 month should be removed from the list as there is no hard interest.
This might be controversial. Maybe, some poking on the mailing list should be done before declaring that no review manager can be found?
I think such a policy might not improve our overall review speed too much, but surely will make the situation a bit clear, and allow to understand the real problems with the review system.
I agree and will add that the best we can do is to know why the review is not scheduled or released, A library in the list could be in one of the following states:
* locking for review manager (up to 6 months -- to force the author to probe the lib is interesting) * locking for a date and making it ready for review (up to 3 months -- needed as the review manager could have some specific requests to the author before the lib is ready for review) * scheduled (up to 3 months -- tomanage with author and review manager specific imperatives) * review ongoing * result pending (up to 1 month -- to force a rapid veredict) * accepted but not yet in trunk (up to 2 months -- the time to setup all the needed infrastructure) * moved to trunk (up to 3 months -- the time to make the library portable) * moved to release branch (up to 3 months -- the time of a release)
This might be a bit too many states for one table. How about having several tables: 1. Scheduled. Libraries that have review manager, were examined by review manager for obvious issues, and have a review date set (within next 3 months). 2. Ready. Libraries that were submitted for review, are considered ready by their authors, and only wait for a review manager. 3. Already reviewed. This set excludes your 'making it ready for review' state. It seems to me that if the library is not ready for review -- for example because it was submitted but somebody found serious problems with it -- should not be tracked by review wizards at all. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40