Re: __attribute__ ((cleanup) patch

[Pavel Simerda <psimerda redhat com>]

> From: "Colin Walters" <walters verbum org>
> On Fri, 2012-10-19 at 08:47 -0400, Pavel Simerda wrote:
> 
> > 1) Do we consider the Linux non-GCC community if *they* want to use
> > NetworkManager?
> 
> So concretely, the major ones are LLVM and ICC; both of these I know
> both implement a lot of the GCC extensions, and they're also C++
> compilers, which means implementing this feature should be trivial.

I, personally, was considering using some faster compiler for development.
Pavel Tišnovský wrote an article about tcc and it might save me a lot of
time waiting for compilation.

> (I just double checked; clang handles __attribute__ ((cleanup)) just
>  fine)

That's a good news.

> The other ones like PCC - yeah, just ignore it.  Basically if you
> look
> at how much __attribute__ ((cleanup)) improves the code in one hand,
> and
> what PCC brings (basically nothing over GCC/LLVM) in the other
> hand...
> 
> > I think that regardless the actual technical aspects, by doing what
> > we do here, we say:
> > “We are NetworkManager. We are Linux. We are GCC. Otherwise, fuck
> > off.”
> 
> I don't agree the change says that.

By a large scale change in the master code base that may affect users and
developers for a decade or more, without any communication, this is exactly
what *we* do.

This has *nothing* to do with your particular change, but rather it is
related to the way changes like this are propagated.

> A lot of the useful bits of GNU C have become a de facto C language
> subset that are implemented by the
> important C compilers (with the major exception of MSVC).  So again,
> this isn't restricted to just GCC.

The lack of information about various compiler projects that might be
used to compile NetworkManager during the nearest decade, is a problem
in itself. You may have enough information, but many other developers,
packagers and advanced users don't.

> > On the other hand, reverting, and starting again in a
> > community-positive way, we would
> > be saying: “Yes, you are welcome to work with us and we are ready
> > to listen to your
> > concerns and *then* decide.”
> >
> > I'll be meeting with SUSE networking developers during the weekend.
> > What should I tell
> > them? That it's not worth trying to work with us unless they are
> > ready to see big changes
> > going under their hands?
> >
> > I believe that this is a matter of attitude. Either we prove to be
> > assholes
> > who don't care, or we maintain a healthy open source project. It's
> > not possible to do both.
> 
> The technical debates about compilers though do pale beside this
> issue, and again, let me apologize.

I value your cooperation.

> *I* screwed up.

I say *we* because I feel we are trying to work together. You might
have gone through the mailing list. Dan might have asked you to do
so. I might have explicitly expressed my ideas about using another
compiler earlier and anyone else might have done this as well.

And *we all* failed in setting up some common understanding of what
changes should be discussed and how much. My opinion on many things
is different from other opinions.

> You are absolutely right that this should have gone through the
> mailing list.  (It was public in Bugzilla, but I didn't really
> elaborate on it much there).

Actually, it might even help us to handle similar future cases
better. And that's what I'm trying to achieve.

> > I guess to show that we know we screwed up is not good enough.
> > Talking
> > about a change that has been merge is ranting.
> 
> I think your concerns are reasonable, and it's not ranting.
>  Post-commit
> debate happens in larger projects too; look at linux-kernel.  And
> some
> of that has definitely resulted in commits being reverted.  Other
> times,
> the author of the commit follows up and addresses the concerns.
> 
> > I'm not going to pretend a discussion over something that has been
> > already
> > decided.
> 
> Ultimately I guess as project maintainer it's dcbw's call, but that I
> still think this discussion is valuable.  But what I need is a list
> of problems to address, and feedback about how I'm addressing them.
> Documentation is one, and if you got a chance to review that patch,
> it'd be appreciated.

Ok. That said... I would like to know which compilers will be out
of play and which are currently supported. Mostly from others, I would
like to know which of those compilers might be a problem for
people wanted to port NetworkManager to another Linux or non-Linux
system. Keeping in mind both desktop and embedded usecases.

While systemd folks explicitly discourage other platforms, as far as I
know, we have not done that yet.

> The other concern is about process, and all I can say there is I
> apologize, and it won't happen again.

And I would be happy if you're not the only person to agree, because
this may happen to anyone working on an improvement in good faith.

> I'm off to hopefully get some
> more projects like gdm to use this, and I'll make sure all the
> maintainers and consumers are in the loop.

It might be nice to have some common discussion and to document
who refuses to implement this in a compiler and why. And the same
for applications.

Cheers,

Pavel