>
> On Wed, Feb 15, 2017 at 11:24:37AM -0500, Frediano Ziglio wrote:
> > >
> > >
> > > > On 15 Feb 2017, at 12:45, Frediano Ziglio <fziglio@xxxxxxxxxx> wrote:
> > > >
> > > >> @@ -134,7 +134,7 @@ static void
> > > >> red_qxl_display_migrate(RedChannelClient
> > > >> *rcc)
> > > >> }
> > > >> g_object_get(channel, "channel-type", &type, "id", &id, NULL);
> > > >> dispatcher = (Dispatcher *)g_object_get_data(G_OBJECT(channel),
> > > >> "dispatcher");
> > > >> - spice_printerr("channel type %u id %u", type, id);
> > > >> + spice_debug("channel type %u id %u", type, id);
> > > >> payload.rcc = rcc;
> > > >> dispatcher_send_message(dispatcher,
> > > >> RED_WORKER_MESSAGE_DISPLAY_MIGRATE,
> > > >
> > > > Looks like there's lot of debugging on migration.
> > > > Like we are not really sure the code is working.
> > >
> > > Maybe someone once needed a lot of debug information, and kept it around
> > > in
> > > case things start going south. That probably means we have annotations
> > > that
> > > may end up being annoying for everybody debugging anything else than
> > > migration.
> > >
> >
> > I wrote that consideration thinking about customer reports.
> > spice_printerr goes in the logs while spice_debug not (by default).
> > If we have lot of bugs in migration removing from client logs could
> > became an issue for us. It's hard to ask to the customer to enable all
> > debugging (too invasive) and even if it could be enabled separately
> > it could be too late (as hard to reproduce for the customer) or
> > complicated (think about huge setups).
> >
> > (CCing Jasa)
>
> In my opinion, a library really should not be displaying anything on
> stdout by default, and as little as possible on stderr. "We print this
> debugging code to stderr because we want it to show up in the log by
> default" does not sound very compelling. Why this debugging code and
> not eg qxl display debugging code? Next step is suggesting to always
> output all debugging code to stderr, but then we'd get too much :)
>
> I'd just silence all the debugging code, or remove it, and work on a way
> of making it easy to enable/filter/... if what we have now is not good
> enough.
>
> Christophe
>
Sure, however your comment is going OT.
My comments was specific to migration problems.
Frediano
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel