[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Error message for Tidy too

Hash: SHA256


Le 06/05/2011 12:28, victory a écrit :
> On Fri, 06 May 2011 10:26:36 -0400
> David Prévot wrote:
>>   Please note that in order to make those files really empty, I ruled
>> out the “nested q elements” warnings. If you relied on this feature,
>> I'll push these warnings back, and will only rule them out before mailing.
> or back up the old log temporarily and let it mail only if the log changed :-)
> ie.: rename/copy target log file -> tidy -> evaluate the diff between old and new
>      -> do mail if it's not empty -> remove old file 

Thanks for your feedback, and sorry in advance for my long answer…

The first problem is the message is only sent daily, so we would have to
copy and keep a daily copy (why not), while Tidy is run after each
rebuild of the website, every four hours. I like the current approach
since it allows one, while trying to fix a tiny issue, to check that he
didn't mess on a larger scale after the next rebuild, and if so, to fix
his big mess (eventually twice), without sending a validation error
message to every translator, so almost no one noticed (e.g. the WNPP
mess yesterday to provide a concrete example ;-).

The second problem, is that we would receive the mail only once: if we
consider that we really want to fix these errors and warnings (which is
the reason why we have fixed all of them recently), and want to do it in
a timely manner and via the safest approach (let translators take care
of their own language), we'd better not assume that if the error was
already there yesterday, it's not important anymore today. In other
word, if yesterday's mail has been lost, it would be a shame not to be
aware today of an error introduced two days ago.

Furthermore, the “nested q elements, possible typo.” warnings are
usually safe like on the testing page [0]: <q>How could installing a
package into <q>testing</q> possibly break other packages?</q>. Ruling
them out by default doesn't seems to me like a big deal, and since it's
now on CVS, one can always run locally cron/parts/999Xtidy with the
appropriate option (“--nested-q” or “-q” in short, maybe not the best
short option name I could have chosen by the way).

If the “nested q elements, possible typo.” warnings are indeed useful
for some of us, the simplest approach I could think of would be to turn
the “-q” option the other way around: make the default output display
all these warnings by default, and make a special daily quiet run ruling
out those warnings just before sending the “Tidy failed” mail.

  0: http://www.debian.org/devel/testing



Version: GnuPG v1.4.11 (GNU/Linux)


Reply to: