> From: "Colin Walters" <walt...@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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list