This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Revamp WWW review process?


Joseph S. Myers <joseph@codesourcery.com> wrote:

>> (notice: I use the Wiki because otherwise I'll have to wait weeks for the
>> approval, and I don't have the time nor the willing of pushing a patch
for
>> weeks just for this. I believe we should either be more liberal with the
>> contents of our website, or get more reviewers. For instance, we could
think
>> of a policy where a www patch can be applied after 48hrs if nobody says
>> otherwise).
>
> You may not have noticed that Gerald is away until 13 March.  Otherwise
> website patches do get reviewed quickly.


I think they are not reviewed quickly enough anyway. I do not have evidence
(statistics) to bring forward, so feel free to ignore my opinion. I know for
sure that some of my www patches had to be pinged, or went unreviewed for
weeks. I'm not trying to accuse Gerald, I just believe that we should just
find a faster path to get www patches in. I find it funny that Dorit has to
ping two times a patch that describes changes to the vectorizer, for
instance.

A problem is that a technical www patch is often deferred to a maintainer of
the specific area of the compiler. For instance, if I want to write
something on the site which speaks about C++, I need a buy-in from both
Gerald and a C++ maintainer. This much often than not requires pings and
long waits. Getting a patch which basically explains a known change in
Bugzilla into changes.html can easily take a week, between Gerald's and
Mark/Jason/Nathan. With such an overhead, I'm unimpressed that changes.html
is always incomplete, and develepors often update it only after explicit
prompts from the Bugmasters.

My personal feeling I think the success of the Wiki is that it does not
require review, rather than the fact that the Wiki syntax is partially
lighter than HTML. The 48-hrs rule I propose seems sensible to me. The worst
thing that can happen is that something incorrect goes live on the site, and
it'll eventually get fixed when someone reads the patch a few days later.
-- 
Giovanni Bajo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]