Re: __attribute__ ((cleanup) patch



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 just double checked; clang handles __attribute__ ((cleanup)) just
 fine)

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.  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.

> 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* screwed up.  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).

> 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.

The other concern is about process, and all I can say there is I
apologize, and it won't happen again.  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.





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