| |||||||||||||
GNU sed 4.2.2 released; maintainer resignsGNU sed 4.2.2 released; maintainer resignsPosted Dec 26, 2012 14:00 UTC (Wed) by Del- (guest, #72641)In reply to: GNU sed 4.2.2 released; maintainer resigns by mlopezibanez Parent article: GNU sed 4.2.2 released; maintainer resigns
>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.
(Log in to post comments)
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.
|
|||||||||||||