Re: New committers?
As I see it, these 2/3 people were added before I was assigned as chair. I also don't see that, at least according to ldap, that they have commit privs. Nor, as stated, were they added to committee-info.txt. And in March 2012's report (http://apache.org/foundation/records/minutes/2012/board_minutes_2012_03_21.txt) we see: Last month, stdcxx added three committers/PMC members. One sent in his CLA and and an account for him was created. The other two are in the process of getting their CLAs signed by their employers. So how are/were they committers?? On Aug 30, 2012, at 12:04 PM, Martin Sebor mse...@gmail.com wrote: On 08/30/2012 09:17 AM, Stefan Teleman wrote: On Thu, Aug 30, 2012 at 9:43 AM, Liviu Nicoaranikko...@hates.ms wrote: I see in the February report (http://stdcxx.apache.org/status/2012-02.txt) that three new committers have been added to the project. Congratulations! Could one of you please update the stdcxx list of committers? I don't mean to punt but I think Jim Jagielski maintains a separate link with the correct list of committers: QUOTE An up-to-date list of all Apache committers (or committers-to-be) is being maintained by Jim Jagielski on this page. /QUOTE which links to: http://people.apache.org/committer-index.html But out of that comprehensive list of all the ASF Committers, I don't know who the other two stdcxx Committers are. Christopher Bergström, and Wojciech Meyer. Which also begs the question: why was this stdcxx Committers list update done this way, by linking to a separate page, when the change could have very well be made directly to the stdcxx's Committers list. I would usually update the Committers table when I chaired the project. But any committer can update the STDCXX site. It doesn't have to be the chair. It would be useful to have instructions for how to do it somewhere. Let me see if I can find some time to write them up and post them. FWIW, the link to Jim's page is there simply as a reference to the (at one point and maybe still) authoritative list of all committers and committers-to-be. I thought it would be handy when we forgot to update the table. Martin --Stefan
Re: New chair and/or attic
On Aug 30, 2012, at 6:48 AM, C. Bergström cbergst...@pathscale.com wrote: I'm sincerely sorry to ask this and I have my own answers, but why continue STDCXX when such negativity from Apache is apparent.. What negativity are you seeing? I'm not seeing any, certainly nothing that is apparent? Will Apache consider passing along some/all of it's CLA granted rights/additional permissions to another foundation that hosts open source projects? or Why not move to libc++? (Yes I realize the amount of effort involved here) That implies that activity would be higher if hosted elsewhere. Is this an opinion or something actually known?
Re: New chair and/or attic
On Aug 30, 2012, at 11:36 AM, Martin Sebor mse...@gmail.com wrote: There's always good traffic when this topic comes up. Thanks to Jim who's made it his mission to pull the plug on STDCXX. I think this must be his third or fourth proposal to vote the project into the attic. No, it's not my mission. If it was I would have never volunteered to be chair and stdcxx would have been moved to the attic already. And what is strange is that it seems like its only when I bring up the proposal do people actually stir from their inactivity and come back to live and we see *SOME* activity on the list.
Re: New chair and/or attic
On Aug 30, 2012, at 5:45 PM, C. Bergström cbergst...@pathscale.com wrote: --- The facts as I know it 1) Our fork is maintained (continuous bug fixes - which we won't submit to Apache now) Why? 2) Stefan is putting in some work (one man army) Hardly a healthy community if just 1 person is putting in some work 3) Wojciech Meyer had put in some work 4) NetBSD has a small amount of patches they could probably push upstream (If Jörg has the time) 5) Martin is/was great for feedback in all areas of STL/C++/occasional code review - I'm really not sure if to you this would make the project dead or in a koma. The problem as I have said before is there needs to be some compelling reason to use STDCXX vs libc++. Instead of just trying to sweep it under the rug - why not find it a new home, put a one line call for help on a blog/homepage or etc. Apache leaders have a huge readership, but this koma issue isn't on the general radar. STDCXX isn't some stupid ass java framework or widget - It's a *critical* part of a C++ stack and the cost of leaving it out of the attic is negligible - What's the benefit of bringing up these attic discussions? It's a critical part in which people either lack the time, motivation or desire to push or submit patches to the canonical source? Or is the desire to force Apache's hand in the matter such that someone else's fork or branch becomes the de-facto source of this critical part??? If stdcxx is as important as you say, and you are fighting to keep it active, then put your money where your mouth is and start working on bumping up the activity. Submit your bug fixes.
Re: New chair and/or attic
On Aug 30, 2012, at 8:00 PM, C. Bergström cbergst...@pathscale.com wrote: While STDCXX is at Apache it will never be BSD licensed. Solution - move it away from Apache foundation and have them transfer some of the additional rights they received to allow recipient foundation to relicense. I thought this would be a win for the project and everyone, but for some reason instead of opening a discussion to transfer - it's just death grip and pushing to the attic. What is wrong with ALv2?
STDCXX forks
Please correct me if I am wrong. I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and the other to Stefan Teleman. The first one contains a number of genuine code changes outside the Apache repository, but without canonical and meaningful commit comments, and without accompanying test cases. Some carry what seem to be bug id's from a private bug database. Some of the changes, e.g., 84d01405124b8c08bb43fdc3755ada2592449727, fa9a45fb36e45b71ba6b4ae93b50bd6679549420, seem odd. Are you guys dropping support for any platforms? Stefan's seem like a complete git-ification of the whole Apache repository but with no changes I could detect. Thanks. L
Re: New chair and/or attic
On 08/31/12 07:20 PM, Jim Jagielski wrote: On Aug 30, 2012, at 8:00 PM, C. Bergströmcbergst...@pathscale.com wrote: While STDCXX is at Apache it will never be BSD licensed. Solution - move it away from Apache foundation and have them transfer some of the additional rights they received to allow recipient foundation to relicense. I thought this would be a win for the project and everyone, but for some reason instead of opening a discussion to transfer - it's just death grip and pushing to the attic. What is wrong with ALv2? Armchair lawyer discussion on this will never end and I'll try to keep this brief.. Apache lawyer views, our lawyer views, your views.. etc (not the problem here) FSF views which probably have some weight across the open source community is summed up with this.. Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html That view seems to have been accepted by the FBSD community - The effect is that the large amount of GPLv2 code in ports/elsewhere can't take advantage of STDCXX due to it's license. Please note I'm not arguing if this is correct, but just the feedback I've gotten. I'm not interested to fight that. Open source works like this in my experience : people use it, they love it and they contribute back. To get users we need to solve problems for larger communities - Make sense? Can you help clear this roadblock, yes or no?
Re-focus [was: Re: New chair and/or attic]
On 08/31/12 08:18, Jim Jagielski wrote: On Aug 30, 2012, at 5:45 PM, C. Bergströmcbergst...@pathscale.com wrote: [...] STDCXX isn't some stupid ass java framework or widget - It's a *critical* part of a C++ stack and the cost of leaving it out of the attic is negligible - What's the benefit of bringing up these attic discussions? It's a critical part in which people either lack the time, motivation or desire to push or submit patches to the canonical source? Or is the desire to force Apache's hand in the matter such that someone else's fork or branch becomes the de-facto source of this critical part??? If stdcxx is as important as you say, and you are fighting to keep it active, then put your money where your mouth is and start working on bumping up the activity. Submit your bug fixes. This discussion is going nowhere and is not becoming of a professional community. By now it must be clear where everybody's interests lie; all who can read took note of that. Since this is largely a dispute between Apache and Pathscale as an alleged representative of a free software community I suggest you take the licensing related discussions in private. L
Re: STDCXX forks
On 08/31/12 07:40 PM, Liviu Nicoara wrote: Please correct me if I am wrong. I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and the other to Stefan Teleman. The first one contains a number of genuine code changes outside the Apache repository, but without canonical and meaningful commit comments, and without accompanying test cases. We can help clean this up if it makes a real difference Some carry what seem to be bug id's from a private bug database. Some of the changes, e.g., 84d01405124b8c08bb43fdc3755ada2592449727 iirc we renamed the files because of some problem with cmake - it was trying to compile those files instead of treating them like headers. , fa9a45fb36e45b71ba6b4ae93b50bd6679549420, seem odd. I forget why we did this tbh - I'll try to get an answer in case it comes up again as a question Are you guys dropping support for any platforms? Not intentionally - We are using/testing this on Solaris, FBSD and Linux - We may add OSX/Win to that list soon, but I can't promise at this point. For targets we only are able to test x86 and x86_64 NetBSD also has a fork I believe, but not sure if it's public/status Stefan's seem like a complete git-ification of the whole Apache repository but with no changes I could detect. He has quite a number of patches and forget where those are kept. I'm guessing a lot of his fixes target KDE/Qt apps and the Perennial C++VS testsuite. http://www.peren.com/pages/cppvs_set.htm
Re: STDCXX forks
On 08/31/12 08:58, C. Bergström wrote: On 08/31/12 07:40 PM, Liviu Nicoara wrote: Please correct me if I am wrong. I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and the other to Stefan Teleman. The first one contains a number of genuine code changes outside the Apache repository, but without canonical and meaningful commit comments, and without accompanying test cases. We can help clean this up if it makes a real difference That is appreciated. It would make a huge difference to anybody coming anew to the project or just catching up, like me. Some carry what seem to be bug id's from a private bug database. Some of the changes, e.g., 84d01405124b8c08bb43fdc3755ada2592449727 iirc we renamed the files because of some problem with cmake - it was trying to compile those files instead of treating them like headers. , fa9a45fb36e45b71ba6b4ae93b50bd6679549420, seem odd. I forget why we did this tbh - I'll try to get an answer in case it comes up again as a question My point exactly, a good comment explains the why's. Are you guys dropping support for any platforms? Not intentionally - We are using/testing this on Solaris, FBSD and Linux - We may add OSX/Win to that list soon, but I can't promise at this point. For targets we only are able to test x86 and x86_64 The reason I am asking is that changes to the template implementation files have most likely broken the support for compilers that do implicit inclusion of template implementations (a.k.a. link-time instantiation of templates). I am not incriminating anyone mind you, I am just trying to point out there mightbe a gap in your testing of your changes. NetBSD also has a fork I believe, but not sure if it's public/status Do you know where that is? Stefan's seem like a complete git-ification of the whole Apache repository but with no changes I could detect. He has quite a number of patches and forget where those are kept. I'm guessing a lot of his fixes target KDE/Qt apps and the Perennial C++VS testsuite. http://www.peren.com/pages/cppvs_set.htm I briefly looked over some patches, there's quite a few of them. I plan to go in more detail over the week-end. Cheers. L
Re: STDCXX forks
On 08/31/12 08:10 PM, Liviu Nicoara wrote: NetBSD also has a fork I believe, but not sure if it's public/status Do you know where that is? He just posted his bulk patch http://www.netbsd.org/~joerg/stdcxx.diff There's a small amount of CVS noise and we already have one part on our github. I don't have more information
Re: New committers?
Jim Jagielski j...@jagunet.com writes: So how are/were they committers?? Hi! Chime in - I think we need to clarify what kind of problems we have with stdcxx being hosted as an Apache project. The two significant ones (as far as I can understand): - as I heard from Christopher Bergström that it's hard to push the stdcxx to FreeBSD ports repository (I can understand it and that sounds pretty bad, if that's the case then the board should consider re-licensing as advised; I agree in general it's a hard decision for the board, but imagine the project would benefit, IANAL tho) - I'm also reading through that methodology we use might not fit the distributed model which could basically improve the pace of development stream (and again github is nice at these things; but there are other considerations) Could somebody just prepare a list of impediments, and possible solutions, we can all workout a single solution that everybody will at least accept - I really don't want to lose faith in stdcxx - especially in such conditions. I still want to contribute, as Christopher said is a critical part of the C++ stack. We got a commit access, and the list seems to be more lively these days, so why not really try to do something useful with this! AFAIK there are 3 sides of this discussion: * Jim who wants to put the project into attic, but what he really cares is how to resurrect stdcxx, as it's an exceptional project for Apache. * Christopher who also thinks the project is exceptional, and should change the way we handle certain things. * and the rest who actually want to commit something and actually start developing, right? I can understand that putting stdcxx into attic might have a negative impact on the development, but doesn't inhibit forking. I'd vote not for putting attic still, as perhaps in case of stdcxx and current state of tools it might be that the project will not survive it, surely that's not Christopher, board and the rest of the developers want. So we agree on one thing, don't want to lose stdcxx and have freedom of the C++ standard library with frequent updates, and speed of development that is concurrent to gcc's libc++ and Clang libraries with a liberal license. So what we need to submit from everybody (not trying to be bossy this time :-)) 1) list of *real* impediments, concrete examples: so we can workout the plan. Bullet points would be great, similar to facts table Christopher has submitted. 2) list of our commitments vs. stdcxx: who is going to do what in the meantime. #1: Nothing comes to my mind right now, apart from not putting into attic for time being please, but I understand other people might have a lot of to say. #2: I plan to commit my patches to armcc port of stdcxx in the short time, and perhaps help with the Clang port as somebody already have mentioned, this certainly needs to be discussed! Cheers, Wojciech
Re: STDCXX forks
On Fri, Aug 31, 2012 at 8:40 AM, Liviu Nicoara nikko...@hates.ms wrote: Stefan's seem like a complete git-ification of the whole Apache repository but with no changes I could detect. Not quite. :-) You are - most likely referring to the svn repo at CVSDude here: http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/ Yes I maintain that fork. All the patches are in this directory: http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/Solaris/diffs/ and they apply with the apply_patches.sh script from here: http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/Solaris/apply_patches.sh The official Oracle port for Solaris 10 and 11, which I maintain, is here: http://src.opensolaris.org/source/xref/userland/gate/components/stdcxx/ This is the source code which is used to build stdcxx on Solaris 10 and 11. The patches for stdcxx on Solaris are here: http://src.opensolaris.org/source/xref/userland/gate/components/stdcxx/patches/ The official Solaris 11 stdcxx package can be installed on Solaris 11 from here: http://pkg.oracle.com/solaris/release/en/search.shtml?token=stdcxxaction=Search For Solaris 10, you need to install SUNWlibstdcxx4 - which contains the stdcxx library and its header files - and SUNWlibstdcxx4S which contains the source code plus all the patches, and which installs in /usr/share/src/. It installs on Solaris 10 Update 10 and later. I maintain the repo at cvsdude on an ad-hoc basis. That means now and then. :-) The source code repo at Oracle is constantly maintained at Oracle, and we publish source code drops every two weeks there (I think). --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: New chair and/or attic
On Fri, Aug 31, 2012 at 8:43 AM, C. Bergström cbergst...@pathscale.com wrote: On 08/31/12 07:20 PM, Jim Jagielski wrote: On Aug 30, 2012, at 8:00 PM, C. Bergströmcbergst...@pathscale.com wrote: While STDCXX is at Apache it will never be BSD licensed. Solution - move it away from Apache foundation and have them transfer some of the additional rights they received to allow recipient foundation to relicense. I thought this would be a win for the project and everyone, but for some reason instead of opening a discussion to transfer - it's just death grip and pushing to the attic. What is wrong with ALv2? Armchair lawyer discussion on this will never end and I'll try to keep this brief.. Apache lawyer views, our lawyer views, your views.. etc (not the problem here) FSF views which probably have some weight across the open source community is summed up with this.. Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html That view seems to have been accepted by the FBSD community - The effect is that the large amount of GPLv2 code in ports/elsewhere can't take advantage of STDCXX due to it's license. Please note I'm not arguing if this is correct, but just the feedback I've gotten. I'm not interested to fight that. Open source works like this in my experience : people use it, they love it and they contribute back. To get users we need to solve problems for larger communities - Make sense? Can you help clear this roadblock, yes or no? My 0.02 of observations about FOSS licenses in general, based on my direct experience: For any FOSS component M, licensed under an Open Source License N, there will always exist a person P, or a group of persons G[P] who will declare that the current license N is inappropriate/invalid/incompatible/etc, and will advocate a change to another Open Source License Q. --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: New chair and/or attic
2012/8/31 Stefan Teleman stefan.tele...@gmail.com: On Thu, Aug 30, 2012 at 4:10 PM, Pavel Heimlich, a.k.a. hajma tropikha...@gmail.com wrote: well, it's half year since revival of the project was announced and has there been any progress/improvements? The state of this is a koma at best. This type of comment, coming from someone who has never contributed a single line of code or bug fixes to stdcxx is tenuous at best. I offered help to the project a year and half ago. At that time the reply was that the maintainers have no time to even add more people to the project and IMO, the only way to keep stdcxx alive is to fork it and move development somewhere else, where the process isn't as rigid as here. I'm not going to further participate in the discussion (unless Stefan insults me again) P. --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: stdcxx issue 1058
On 08/31/12 13:14, Stefan Teleman wrote: In June this year I committed r1353821 to trunk which fixes stdcxx-1058. I have the patches for 1058 ready to commit to branches (4.2.x and 4.3.x). OK to go? The patch looks ok to me. What seems to be the problem? +1 L
Branching policy, 4.3.x, 5.0.0, etc.
The branching policy [1] in effect looks very much like the Rogue Wave release process: branch at the beginning of each release cycle, work on the release branch, merge changes back into the trunk at release time (and in between as needed). Did I get that right? From what I gather 4.2.x has last released 4.2.1, there is a 4.3.x with no releases, and a prospective 5.0.0 which should come out of the trunk (I saw changes mentioning 5.0.0). What are the stated goals for the 4.3.x and 5.x? Thanks. L [1]http://wiki.apache.org/stdcxx/Branching
Re: STDCXX forks
On Aug 31, 2012, at 8:40 AM, Liviu Nicoara nikko...@hates.ms wrote: Stefan's seem like a complete git-ification of the whole Apache repository but with no changes I could detect. FWIW, The ASF supports git so if people think it would help, all we'd need to do is ask #infra to move stdcxx to git.
Re: Branching policy, 4.3.x, 5.0.0, etc.
On Fri, Aug 31, 2012 at 1:56 PM, Liviu Nicoara nikko...@hates.ms wrote: The branching policy [1] in effect looks very much like the Rogue Wave release process: branch at the beginning of each release cycle, work on the release branch, merge changes back into the trunk at release time (and in between as needed). Did I get that right? From what I gather 4.2.x has last released 4.2.1, there is a 4.3.x with no releases, and a prospective 5.0.0 which should come out of the trunk (I saw changes mentioning 5.0.0). What are the stated goals for the 4.3.x and 5.x? My understanding is that 4.2.x and 4.3.x are bugfix/rfe releases while 5.x would become C++2011. Please correct me if i'm wrong --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: New chair and/or attic
The idea that ALv2 projects can't be added to FreeBSD ports is complete and total hogwash. Pure FUD. On Aug 31, 2012, at 8:43 AM, C. Bergström cbergst...@pathscale.com wrote: On 08/31/12 07:20 PM, Jim Jagielski wrote: On Aug 30, 2012, at 8:00 PM, C. Bergströmcbergst...@pathscale.com wrote: While STDCXX is at Apache it will never be BSD licensed. Solution - move it away from Apache foundation and have them transfer some of the additional rights they received to allow recipient foundation to relicense. I thought this would be a win for the project and everyone, but for some reason instead of opening a discussion to transfer - it's just death grip and pushing to the attic. What is wrong with ALv2? Armchair lawyer discussion on this will never end and I'll try to keep this brief.. Apache lawyer views, our lawyer views, your views.. etc (not the problem here) FSF views which probably have some weight across the open source community is summed up with this.. Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html That view seems to have been accepted by the FBSD community - The effect is that the large amount of GPLv2 code in ports/elsewhere can't take advantage of STDCXX due to it's license. Please note I'm not arguing if this is correct, but just the feedback I've gotten. I'm not interested to fight that. Open source works like this in my experience : people use it, they love it and they contribute back. To get users we need to solve problems for larger communities - Make sense? Can you help clear this roadblock, yes or no?
Re: New committers?
On 09/ 1/12 01:13 AM, Jim Jagielski wrote: On Aug 31, 2012, at 9:42 AM, Wojciech Meyerwojciech.me...@arm.com wrote: Jim Jagielskij...@jagunet.com writes: So how are/were they committers?? Hi! Chime in - I think we need to clarify what kind of problems we have with stdcxx being hosted as an Apache project. The two significant ones (as far as I can understand): - as I heard from Christopher Bergström that it's hard to push the stdcxx to FreeBSD ports repository (I can understand it and that sounds pretty bad, if that's the case then the board should consider re-licensing as advised; I agree in general it's a hard decision for the board, but imagine the project would benefit, IANAL tho) Not exactly sure why, or how, since there are other ASF projects in the FreeBSD ports directory... LOTS of others. Do they come bundled with the compiler and link against every c++ application by default? I suspect that their risk assessment may be higher with something that's equivalent to libc on the system. (btw - anecdotal evidence and flippant comments don't help resolve this. Did you even read my previous email explaining this?)
Re: New chair and/or attic
On 09/ 1/12 01:17 AM, Jim Jagielski wrote: The idea that ALv2 projects can't be added to FreeBSD ports is complete and total hogwash. Pure FUD. Thanks for the top post and your view... Can you actually address the issue and question? On Aug 31, 2012, at 8:43 AM, C. Bergströmcbergst...@pathscale.com wrote: On 08/31/12 07:20 PM, Jim Jagielski wrote: On Aug 30, 2012, at 8:00 PM, C. Bergströmcbergst...@pathscale.com wrote: While STDCXX is at Apache it will never be BSD licensed. Solution - move it away from Apache foundation and have them transfer some of the additional rights they received to allow recipient foundation to relicense. I thought this would be a win for the project and everyone, but for some reason instead of opening a discussion to transfer - it's just death grip and pushing to the attic. What is wrong with ALv2? Armchair lawyer discussion on this will never end and I'll try to keep this brief.. Apache lawyer views, our lawyer views, your views.. etc (not the problem here) FSF views which probably have some weight across the open source community is summed up with this.. Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html That view seems to have been accepted by the FBSD community - The effect is that the large amount of GPLv2 code in ports/elsewhere can't take advantage of STDCXX due to it's license. Please note I'm not arguing if this is correct, but just the feedback I've gotten. I'm not interested to fight that. Open source works like this in my experience : people use it, they love it and they contribute back. To get users we need to solve problems for larger communities - Make sense? Can you help clear this roadblock, yes or no?
Re: New committers?
Are you suggesting that FreeBSD does not allow the inclusion of ANY ALv2 library under its ports directory? On Aug 31, 2012, at 2:19 PM, C. Bergström cbergst...@pathscale.com wrote: Do they come bundled with the compiler and link against every c++ application by default? I suspect that their risk assessment may be higher with something that's equivalent to libc on the system. (btw - anecdotal evidence and flippant comments don't help resolve this. Did you even read my previous email explaining this?)
Re: stdcxx issue 1058
On Fri, Aug 31, 2012 at 1:29 PM, Liviu Nicoara nikko...@hates.ms wrote: On 08/31/12 13:14, Stefan Teleman wrote: In June this year I committed r1353821 to trunk which fixes stdcxx-1058. I have the patches for 1058 ready to commit to branches (4.2.x and 4.3.x). OK to go? The patch looks ok to me. What seems to be the problem? +1 Done. trunk revision 1353821 branches/4.2.x revision 1379523 branches/4.3.x revision 1379520 --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: New committers?
On 09/ 1/12 01:35 AM, Stefan Teleman wrote: On Fri, Aug 31, 2012 at 2:27 PM, C. Bergström cbergst...@pathscale.com wrote: stdcxx ends up linking against *EVERY* C++ application if it's used in the default compiler setup. (Which is what I was trying to achieve) That includes ***GPLv2 software in ports. Get it? How exactly is APLv2 different from 2-clause BSD or 3-clause BSD in this respect? The BSD licenses are just as incompatible with GPLv2 as APLv2 is. Our views may be the same, but others are not from the apache website Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html
Re: New chair and/or attic
On 09/ 1/12 01:28 AM, Jim Jagielski wrote: Your suggestion is that, somehow, one cannot push stdcxx as part of the FreeBSD ports collection. And that is because it is licensed under ALv2. My response is that that suggestion is total hogwash. That's not an authoritative response - To help resolve this maybe we could 1) Have Apache lawyers say the same thing via a letter to FBSD foundation or 2) Please have this link updated and provide a reference to where FSF has stated their revised compatibility views about APLv2 + GPLv2 http://www.apache.org/licenses/GPL-compatibility.html Can you help with either of those?
Re: New committers?
On Aug 31, 2012, at 2:38 PM, C. Bergström cbergst...@pathscale.com wrote: On 09/ 1/12 01:35 AM, Stefan Teleman wrote: On Fri, Aug 31, 2012 at 2:27 PM, C. Bergström cbergst...@pathscale.com wrote: stdcxx ends up linking against *EVERY* C++ application if it's used in the default compiler setup. (Which is what I was trying to achieve) That includes ***GPLv2 software in ports. Get it? How exactly is APLv2 different from 2-clause BSD or 3-clause BSD in this respect? The BSD licenses are just as incompatible with GPLv2 as APLv2 is. Our views may be the same, but others are not from the apache website Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html FWIW, however, the ASF does not agree with that. That is pretty common knowledge. So your view agrees with that of the ASF.
Re: New chair and/or attic
On Aug 31, 2012, at 2:41 PM, C. Bergström cbergst...@pathscale.com wrote: On 09/ 1/12 01:28 AM, Jim Jagielski wrote: Your suggestion is that, somehow, one cannot push stdcxx as part of the FreeBSD ports collection. And that is because it is licensed under ALv2. My response is that that suggestion is total hogwash. That's not an authoritative response - To help resolve this maybe we could 1) Have Apache lawyers say the same thing via a letter to FBSD foundation or 2) Please have this link updated and provide a reference to where FSF has stated their revised compatibility views about APLv2 + GPLv2 http://www.apache.org/licenses/GPL-compatibility.html Ummm... system library These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Re: STDCXX forks
On Fri, Aug 31, 2012 at 8:58 AM, C. Bergström cbergst...@pathscale.com wrote: He has quite a number of patches and forget where those are kept. I'm guessing a lot of his fixes target KDE/Qt apps and the Perennial C++VS testsuite. http://www.peren.com/pages/cppvs_set.htm Correction: my patches aren't related to Qt/KDE at all at this point - they are related to Solaris. Apache stdcxx is part of Solaris Core. So the authoritative patchset for Solaris/stdcxx is the one publisehd by Oracle, since it is kept up-to-date and it represents an officially released and supported version of stdcxx. --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: New chair and/or attic
On 09/ 1/12 02:01 AM, Jim Jagielski wrote: On Aug 31, 2012, at 2:41 PM, C. Bergströmcbergst...@pathscale.com wrote: On 09/ 1/12 01:28 AM, Jim Jagielski wrote: Your suggestion is that, somehow, one cannot push stdcxx as part of the FreeBSD ports collection. And that is because it is licensed under ALv2. My response is that that suggestion is total hogwash. That's not an authoritative response - To help resolve this maybe we could 1) Have Apache lawyers say the same thing via a letter to FBSD foundation or 2) Please have this link updated and provide a reference to where FSF has stated their revised compatibility views about APLv2 + GPLv2 http://www.apache.org/licenses/GPL-compatibility.html Ummm... system library These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. armchair lawyer response not acceptable - Unless you're an Apache lawyer?
Re: New committers?
My input below. On 08/31/12 09:42, Wojciech Meyer wrote: The two significant ones (as far as I can understand): - as I heard from Christopher Bergström that it's hard to push the stdcxx to FreeBSD ports repository (I can understand it and that sounds pretty bad, if that's the case then the board should consider re-licensing as advised; I agree in general it's a hard decision for the board, but imagine the project would benefit, IANAL tho) Christopher's wishes and goals may be different from others'. I do not believe he has ulterior motives that would be detrimental to the rest of us but AFAICT he has not made a compelling argument. Even with one, it stretches the imagination what could possibly convince Apache to give up on STDCXX ownership. - I'm also reading through that methodology we use might not fit the distributed model which could basically improve the pace of development stream (and again github is nice at these things; but there are other considerations) The process put in place by Apache closely mirrors the rigors of the Rogue Wave environment where the project originates. The development proceeds at the best speed possible while at the same time proving the consistency and correctness of the code base through passing unit tests. The process is tightly controlled by rules which are observed by everyone (such as creating test cases before fixing bugs, thoroughly documenting changes, following coding and code structuring conventions, etc.). The process has an ultimate authority in the person of the tech lead, Martin. The end result of the _pedantic_ application of these rules is the product you and I, all of us, enjoy. As mentioned before it is of an excellent quality, not often seen in the software world. It also is a very sophisticated product both with an intricate code structure, and extreme use of the language which pushes the compilers to their limits. Any change, however small, must be carefully considered and weighed, and careless changes will almost always break it in subtle ways. As a rule of thumb, if there is something that looks wrong in the source code, chances are you're not getting it right. In case my point did not get across by now, I am strongly for the continuation of a tightly controlled development process. Thanks. Liviu
