Thank you for the comment.
On 2022/04/24 6:25, Gabriele Svelto wrote:
On 4/23/22 01:54, ISHIKAWA,chiaki wrote:
Yes, MOZ_LOG is a nice way to capture information from already
well-thought out processing.
However, can we use that on tryserver?
Yes, you can do things like:
./mach try fuzzy --env MOZ_LOG="ObserverService:5"
Then pick the tasks you want to run and you'll get the same log messages
as you'd get locally.
This is very nice to hear.
Except:
Has anyone been able to use the above syntax to submit a C-C TB
build/test job to tryserver?
Many years ago, it did not work well and thus, since others reported
similar issues, I have been using the following for submitting a job to
tryserver. Maybe it does work now?
hg push -f ssh://hg.mozilla.org/try-comm-central
Now, I have read the local script to create a tryserver job and realized
that maybe that was because MQ extension of HG was recommended and I
used it back then (not sure. I am not an expert of tyserver mechanism.)
Actually, I am still using it locally although it is NOT recommended
anymore. Switching fundamental tool usage pattern
is a burden for an occasional patch submitter. :-(
That being said I think that the default amount of logspam that Gecko
spits out is excessive and I'd be very happy if more of it was put
behind MOZ_LOG so that it could only be enabled when it matters.
That would be great.
However, I am afraid that it does not happen overnight.
The sheer amount of NS_WARNING, etc. for debugging purposes during
development is
very large, and clutter up the debug log.
To think about the organization of data used by MOZ_LOG() takes a bit of
time obviously.
I surmise that use of other macros to print warnings and strange
conditions during initial development phase is much, much easier.
(We may even not know exactly the final neat output should be during
early development.)
So, from this angle, I still push the creation of the development
macros for INFORMATIONAL message.
After the development of a feature, etc. settles down, the developers
might want to convert them to MOZ_LOG if they wish.
I wonder how many developers want to do that, though.
Also, MOZ_LOG usage may not sit well for the desire to detect very
strange situations (should not happen case, etc. But I may be wrong here.)
My original post is to mark INFORMATIONAL output as such and reduce what
is not essential.
To my delight, already some patches have been created to reduce clutter.
Obviously some messages are no longer thought to be useful after the
initial development process and the code has matured.
Gabriele
Thank you for the information again.
Chiaki
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/a15ed8e7-19fa-b96e-da6b-49b3222f5bb4%40yk.rim.or.jp.
