On Tue, Oct 01, 2019 at 03:54:02PM +0100, Daniel P. Berrangé wrote:
> On Tue, Oct 01, 2019 at 11:49:25AM -0300, Daniel Henrique Barboza wrote:
> >
> >
> > On 10/1/19 11:25 AM, Ján Tomko wrote:
> > > On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
> > > > On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza
wrote:
> > > > > Signed-off-by: Daniel Henrique Barboza
<danielhb413(a)gmail.com>
> > > > > ---
> > > > Reviewed-by: Erik Skultety <eskultet(a)redhat.com>
> > > >
> > > > and safe for freeze
> > > >
> > >
> > > This is not a bugfix, it can wait.
> > >
> > > Also, there is an ongoing discussion about using g_autofree once we
> > > start depending on gnulib, so I don't see a point in trying to
convert
> > > code to the macro that will soon be obsolete.
> >
> > Huh. Guess I'll stop sending those VIR_AUTO* patches all around then.
I'll
> > wait for the gnulib equivalent, if there will be any.
>
> NB, glib != gnulib :-)
>
> gnulib is the POSIX portability layer we're trying to eliminate.
>
> glib is the higher level library we're trying to adopt.
>
> The new approach will be more or less identical just different
> naming convention.
So, I guess, reviewing the following would also be kinda pointless given the
circumstances, wouldn't it?
https://www.redhat.com/archives/libvir-list/2019-September/msg01452.html
Given that we're in freeze now, we won't commit them for at least a week
now. I'd hope we can get the very first glib patches merged at the start
of the next cycle, which would let us go straight to the glib autofree
macros.
Reviewing those patches is not wasted effort though. VIR_AUTOFREE and
VIR_AUTOPTR are essentially trivial renames to g_autofree / g_autoptr.
The correctness of the cleanup is more important to review and that's
not impacted.
Regards,
Daniel
--
|: