Joseph S. Myers <[EMAIL PROTECTED]> 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
