| |||||||||||||
GNU sed 4.2.2 released; maintainer resignsGNU sed 4.2.2 released; maintainer resignsPosted Dec 25, 2012 20:45 UTC (Tue) by mlopezibanez (guest, #66088)In reply to: GNU sed 4.2.2 released; maintainer resigns by Del- Parent article: GNU sed 4.2.2 released; maintainer resigns
I cannot speak for Paolo, but I can speak of my experience as a GCC contributor. In the case of GCC, the FSF would do to the GCC community a great service if the copyright assignment process was streamlined as to make it less obnoxious. The current procedure is either too much a hassle or even simply impossible to fulfill. Read the horror stories of potential contributors chasing down who can sign the CA form in their organizations in the thread "Why not contribute to GCC" in the archives. I have my own horror story in which after two failed attempts and several mornings wasted, *I* proposed to the FSF the modification to my CA form that got accepted to be signed by my university.
The other glaring example is the issue with generating documentation from code. In GCC, there is a lot of stuff that is auto-generated from description files. It would be ideal to generate the documentation of this stuff from the same description files that generate the code. But the incompatibility between GPL (code) and GFDL (docs) means that it cannot be done. GCC devs have proposed many many potential solutions for this issue, but they have been either shot-down or ignored by RMS.
The remark made by Paolo about the coding standards and C++ is not that every GNU software should be re-written in C++, but that since some GNU software is (like GCC), the coding standards should acknowledge this. However, the strategy of RMS is: "I don't like it, so I am not going to do anything about it and hope you get discouraged and switch back to C." This is the same strategy as for the two issues above: "Not a problem for RMS, so RMS won't do anything about it."
Finally, there are the issues with the lack (or direct obstruction) of technical leadership and the lack of communication, misunderstandings, or failures of diplomacy and tact. There are plenty of examples of this given in the email by Paolo.
(Log in to post comments)
GNU sed 4.2.2 released; maintainer resigns Posted Dec 25, 2012 23:35 UTC (Tue) by dd9jn (subscriber, #4459) [Link] I agree with most of your comments. However, to be fair to Mr. Stallman we should notice that he does not enforce the use of a specific programming language. For example on Nov. 9 there was a question on the internal mailing list (g-p-d):Just wondering, is is acceptable for GNU project to use languages, other then C, C++, Scheme? [...]Someone commented: I think GNU's open for any language include .net things(hmm...)on which Stallman only replied: We ask people not to write programs in C# and .Net.".Thus I cannot see any banning of C++ - even if he dislikes it. Right, there are other hackers who expressed their concerns about using C++ for gcc, but this was a pure technical-religious thing and not about free software. BTW, for GnuPG I simply disobey the order to use the FDL.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 22:34 UTC (Wed) by stevenb (guest, #11536) [Link]
In GCC, ignoring the GFDL is hard, because there is so much legacy documentation. Before and just after the switch to GFDL, there was some talk about forking the documentation and keeping it GPL'ed. But the FSF is the copyright holder, and the GCC steering committee seems to be more interested in keeping RMS happy than in confronting him about these problems.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 8:07 UTC (Thu) by dd9jn (subscriber, #4459) [Link]
Well, than it is time to stand up and do the best for gcc and free software by doing whatever is needed to keep gcc an attractive software for new developers (e.g. IT students).
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 8:40 UTC (Wed) by rsidd (subscriber, #2582) [Link] It would be ideal to generate the documentation of this stuff from the same description files that generate the code. But the incompatibility between GPL (code) and GFDL (docs) means that it cannot be done. GFDL is one of RMS's worst ideas. When Debian regards RMS's pet licence as non-free, you know there's trouble. And surely it should have been obvious that it means trouble for auto-generated documentation. However, the strategy of RMS [on C++ coding standards] is: "I don't like it, so I am not going to do anything about it and hope you get discouraged and switch back to C." But GNU's C coding standards are awful! At least the parts on formatting code. The BSD style, as described in FreeBSD's style(9) manpage, is much better. I would think that an insistence on GNU C coding style would encourage developers to use another language and some sensible widely-accepted coding standard.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 28, 2012 1:58 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> I would think that an insistence on GNU C coding style would encourage developers to use another language
If that is the case, then it should be kept the way it is.
GNU sed 4.2.2 released; maintainer resigns Posted Jan 4, 2013 17:10 UTC (Fri) by nix (subscriber, #2304) [Link] But GNU's C coding standards are awful! At least the parts on formatting code. The BSD style, as described in FreeBSD's style(9) manpage, is much better.This is extremely debatable. I happen to prefer the GNU style, for the simple reason that I evolved a personal style very similar to it myself, decades ago, before I ever heard of GNU. I find the BSD style exceedingly cramped and hard to read. Nonetheless, my current job involves 95% BSD indentation and 5% GNU indentation, and, y'know, I adjusted in about half an hour. I don't know of any actual research, let alone replicated, analyzing the effect of indentation style on error rates and the like. I suspect any such effect is marginal, on the grounds that if a large effect was seen, we wouldn't see such a wide variety of styles and such anger over the subject. Without that, such things remain a matter of taste, and there are no real grounds to say that one code style is better than another. Of course this does not change the undisputable fact that my preferred style is better than yours and anyone who disagrees is clearly a traitor and should be fed on by demons for the next thousand years and made to use Microsoft Word atop Windows ME as their text editor.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 26, 2012 14:00 UTC (Wed) by Del- (guest, #72641) [Link]
>In the case of GCC, the FSF would do to the GCC community a great service if the copyright assignment process was streamlined as to make it less obnoxious.
Sounds like a valid complaint. This process should be made as steam-lined as possible. Has any non-controversial changes been suggested?
>The other glaring example is the issue with generating documentation from code.
Indeed, the GFDL seems like poor craftsmanship (I am thinking of the incomatible with GPL part of it here). I would prefer CC-BY-SA, but I do see a value in protecting parts of the documentation from exclusion or alteration. Not sure whether the value justifies the drawbacks though. Do you know the current status here, is there any efforts to improve GFDL? Does FSF allow other licenses on documentation?
>The remark made by Paolo about the coding standards and C++ is not that every GNU software should be re-written in C++, but that since some GNU software is (like GCC), the coding standards should acknowledge this.
This should hardly have anything to do with RMS. AFAIK, he is not a C++ programmer, so others will need to step up if coding standards are to be established. Judging by the attitude towards the existing C standards, I am actually a bit in the dark as to whether coding standards are even wanted. Are you sure you want it? If so, are you sure you want FSF to provide it, or that it should be provided as one standard across all GNU projects at all?
With respect to diplomacy, I am not sure what to think. Linus is not exactly known for diplomacy nor tact, but whatever he does, it works.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 27, 2012 9:14 UTC (Thu) by khim (subscriber, #9252) [Link] Judging by the attitude towards the existing C standards, I am actually a bit in the dark as to whether coding standards are even wanted. Are you sure you want it? It's not the question of "want", it's the question of "need". C++ is built in "no policy" fashion. In a sense it's not a language, but meta-language. You can use many different styles in it (similarly to C, actually, but much, much worse). Thus it needs a style guide. It's funny, really: when people discuss various style guides usually a lot of heat exchanged on the question of where to put braces, but these are minor issues. Things like "do we want to support exceptions" are fundamental: RAII is much less powerful without them, but, on the other hand it's basically impossible to create exception-safe code unless it's created this way from the beginning. And these should be discussed and resolved somewhere. It's possible to use C++ with or without exceptions, but these are almost like two different languages. Similarly with auto/declspec: you can write code which is very Ocaml-like (as in: it almost exclusively derives types from types of other objects or functions) or you can write more C-like code (where only some local objects don't have a fixed declared type). This too, is a large difference (although smaller then exceptions). And, back to braces: yes, these decisions are minor but still there are few different styles for C++-only constructs and it'll be nice to have one "canonical form" for them.
GNU sed 4.2.2 released; maintainer resigns Posted Dec 28, 2012 14:54 UTC (Fri) by Del- (guest, #72641) [Link]
>It's not the question of "want", it's the question of "need".
Yes, but that was not the issue. The issue is whether FSF should provide C++ coding standards across all GNU projects. The alternative is to leave it up to the individual projects to decide. I am not at all sure it is a good idea to have FSF dictate C++ coding standards across GNU projects. I am pretty sure having RMS dictate such standards is a bad idea, so asking for that makes no sense to me.
Generally speaking, the developers of any GNU project can do pretty much as they please with the code if they are able to agree (except if it goes against freedom of course). As such, GNU projects are no different from other open projects. Get the other leading developers on your side, and you will get it your way.
|
|||||||||||||