Re: [PROPOSAL][VOTE] Subversion
On Nov 11, 2009, at 5:35 PM, Davanum Srinivas wrote: Dan, It's up to each project to get their releases correct - Yes. But not everyone hangs out on the d...@maven or gene...@incubator. Hence the request to broadcast. I really don't understand the why? - No one is trying to mandate using a specific pom across all PMC(s). Just the fact that there was a problem that was actively worked on and fixed and the proposed solution. Basically telling pmcs take it or leave it. At the very least pay attention that the jars that they release should be build-able using the source zip(s). Yeah, I agree... I short little helpful Email is likely welcome info. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 11:43 PM, Daniel Kulp dk...@apache.org wrote: Actually, the vote was kind of withdrawn to update it to new descriptors. Thus, its not available yet. In anycase, no need to spam all the PMCs, especially those not using Maven. Just keep an eye on the annou...@maven list. When available, it will be announced there. Why not sent it through bo...@? All Chairs are subscribed to that list, several board members have in the past raised concerns about the releases created using maven. This would unequivocally show that maven has delivered a working solution, and notify all PMC chairs of the general Apache parent pom. They are responsible for communicating that with their own community IMO if it is applicable. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Why not sent it through bo...@? All Chairs are subscribed to that list, several board members have in the past raised concerns about the releases created using maven. This would unequivocally show that maven has delivered a working solution, and notify all PMC chairs of the general Apache parent pom. They are responsible for communicating that with their own community IMO if it is applicable. Well, I feel like if I email board@, then I should be talking to _the board_ and not everyone else in the room. The promotion of this release would naturally be noted in the next board report, as where the previous changes when we made them inside the maven project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 4:04 AM, Niclas Hedhman nic...@hedhman.org wrote: On Wed, Nov 11, 2009 at 12:29 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. Not new at all. I know that one of the oldest Java projects here, Cocoon, once only released buildable(!) source code. What is happening in some Java projects, via Maven's release plugin, This is fud. It has nothing to do with maven's release plugin or maven at all. Maven has always been perfectly capable of producing buildable source distros - its just down to how a project sets up maven - as with any build tool. is disturbing since the source release only exist in the subversion repository. The -source.jar is packaged in a non-buildable format optimized for IDE source integration and not to be reproducable. Some ASF projects (I think including some of Maven's own artifacts and subprojects) are now in total opposite of old school source releases This was pointed out to the maven project a few months ago and they changed their practices and are now releasing proper, buildable source packages. Niall and effectively only releases binaries containing re-packaged sources and one has to go to source repository to find the 'real' source code for that release. Cheers -- Niclas Hedhman, Software Developer - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Mark Phippard-3 wrote: I gave counsel to the Eclipse Foundation and explained that they could provide a fully functioning JavaHL library to users with only EPL compatible code. Basically, you just need to build without Neon, BDB and libintl support. Of the three, the only thing an Eclipse client user needs is Neon, and Serf serves as a viable replacement. I do not know why they never chose to release a binary built this way. I can only assume that Igor and Polarion did not want to make these binaries. Mark, it’s not a problem to build JavaHL. But as you said, to make it EPL compatible Eclipse should replace Neon by Serf or remove DAV libraries completely. It’s not a solution. In the first case proper functionality isn’t guaranteed (you and Michael Pilato are sceptic regarding Serf). Nobody would like to use SVN client, which is “different” and migh have problems. In the second case, SVN should work without DAV protocol, which isn’t acceptable by majority of people. -- View this message in context: http://old.nabble.com/-PROPOSAL--VOTE--Subversion-tp26203843p26299895.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Fri, Nov 6, 2009 at 7:30 PM, Greg Stein gst...@gmail.com wrote: On Fri, Nov 6, 2009 at 14:21, Craig L Russell craig.russ...@sun.com wrote: On Nov 6, 2009, at 10:43 AM, Greg Stein wrote: But with all that said, how about we do this: we'll do a 1.6.7 release from the 1.6.x branch after we do the code import. That release will be performed by svncorp (we don't want to touch every file on that branch to relicense it, and to switch file headers). The release process can be followed/tracked by the Incubator PMC. I'll make sure to relay pointers to all relevant threads as the release is performed. I don't think that releasing svn by svncorp without any Apache license proves anything except that they can make a release after moving the repository. So if it makes anyone happy, fine. But it's not an Apache release. I'd be interested in seeing a release after it's been licensed to Apache and has all of the Apache license, notice, and packaging. It already has the Apache License (v2), and it uses a NOTICE file (per the license), and our packaging is tighter/stronger than typical Apache releases (per Justin's note). Are there other items to an Apache release that are needed to demonstrate that the svn project understands the proper release process? The 1.7 release is not on the schedule at all, while we're going to do a 1.6.7 release in a few weeks. We're naturally very reticent to disrupt a prior-release branch with a massive relicense. I found the above a bit misleading. From what I can see the current trunk for subversion (I guess thats going to be 1.7+) had the ALv2 headers applied 4 months ago: http://svn.collab.net/viewvc/svn?view=revisionrevision=38370 But the 1.6.x branch is still using the old license headers: http://svn.collab.net/viewvc/svn/branches/1.6.x/ So I guess(?) the subversion guys don't want to duplicate that effort on the 1.6.x branch. Niall Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 6:38 AM, Igor Burilo igor.bur...@polarion.org wrote: Mark Phippard-3 wrote: I gave counsel to the Eclipse Foundation and explained that they could provide a fully functioning JavaHL library to users with only EPL compatible code. Basically, you just need to build without Neon, BDB and libintl support. Of the three, the only thing an Eclipse client user needs is Neon, and Serf serves as a viable replacement. I do not know why they never chose to release a binary built this way. I can only assume that Igor and Polarion did not want to make these binaries. Mark, it’s not a problem to build JavaHL. But as you said, to make it EPL compatible Eclipse should replace Neon by Serf or remove DAV libraries completely. It’s not a solution. In the first case proper functionality isn’t guaranteed (you and Michael Pilato are sceptic regarding Serf). Nobody would like to use SVN client, which is “different” and migh have problems. In the second case, SVN should work without DAV protocol, which isn’t acceptable by majority of people. It sounds like you should have asked the Subversion community or done some checking. Serf is used by a decent number lot of people and is usable. It would have been a viable option for you to provide a JavaHL binary that only used Serf. Is it possible you would have users run into problems that do not exist with Neon? Yes, of course. But odds are those problems would have all been found and fixed by now in the current 1.6.6 release had you chosen to do that. The main lingering concern is that Serf violates the rules of the Subversion editor API. This is more of a concern for people writing their own code to use the Subversion API then it is for Subversion itself (as is the case with JavaHL). You would not be bitten by this issue. Some of us think this should be addressed before Serf replaces Neon as the default. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Justin Erenkrantz wrote: On Wed, Nov 11, 2009 at 12:38 PM, Igor Burilo igor.bur...@polarion.org wrote: isn’t guaranteed (you and Michael Pilato are sceptic regarding Serf). Nobody Hang on - let's be clear here: ra_serf passes *all* of the Subversion regression tests just fine and has done so for several years now. (An ra_serf slave is part of the standard buildbot runs.) ra_serf doesn't work with certain HTTP/1.0 proxies (because they don't support chunked request bodies) and C-Mike has always been uncomfortable with how ra_serf views editor drives. It's not like ra_serf isn't functional or feature equivalent; in several areas, ra_serf is much much faster than ra_neon. And, I've used ra_serf every day since I initially wrote it. =) -- justin Yeah, the label of skeptic really doesn't fit me on this matter. I am 100% confident that ra_serf is the right place to invest our collective DAV-aimed energy. It is usable for most folks right now (and has been for a long time). It has bugs, but then what doesn't? The only strong sticking point for me is the editor drive item Justin mentions above. That's not so much a user-facing problem, but a develop/API-usage one. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 07:06, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Nov 6, 2009 at 7:30 PM, Greg Stein gst...@gmail.com wrote: ... It already has the Apache License (v2), and it uses a NOTICE file (per the license), and our packaging is tighter/stronger than typical Apache releases (per Justin's note). Are there other items to an Apache release that are needed to demonstrate that the svn project understands the proper release process? The 1.7 release is not on the schedule at all, while we're going to do a 1.6.7 release in a few weeks. We're naturally very reticent to disrupt a prior-release branch with a massive relicense. I found the above a bit misleading. From what I can see the current trunk for subversion (I guess thats going to be 1.7+) had the ALv2 headers applied 4 months ago: http://svn.collab.net/viewvc/svn?view=revisionrevision=38370 But the 1.6.x branch is still using the old license headers: http://svn.collab.net/viewvc/svn/branches/1.6.x/ So I guess(?) the subversion guys don't want to duplicate that effort on the 1.6.x branch. It isn't so much an effort as disruptive. We have very clear versioning guidelines[1]. Changes across patch versions are highly-restricted. A license change itself is disruptive, let alone the effects across the entire source code base. In essence, it is a policy decision derived from our versioning guidelines. Cheers, -g [1] http://apr.apache.org/versioning.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
What is happening in some Java projects, via Maven's release plugin, is disturbing since the source release only exist in the subversion repository This problem has been solved and is no longer valid. Any repetition of the old news is total fud. We have for many months now been providing proper source releases for EVERYTHING in the maven project and just recently promoted the same to the Apache pom making it automatic for any Apache project with the new pom. See links below for more info: http://old.nabble.com/Update-on-ASF-Release-requirements-ts23379350.html#a23379350 http://old.nabble.com/-VOTE--Apache-%28parent-POM%29-version-7-ts26221188.html As far as I understand the requirements, this issue is completely resolved so lets stop saying that Maven produces incorrect releases. It was never an issue with the tool itself, but as a project we've fixed it and are sharing it to all projects at Apache using Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Brian, Do you mind sending an email to pmcs AT apache.org to inform them that they should be using this new version of Apache pom? And any other additional instructions needed to enable this feature to work. thanks, dims On 11/11/2009 03:51 PM, Brian Fox wrote: What is happening in some Java projects, via Maven's release plugin, is disturbing since the source release only exist in the subversion repository This problem has been solved and is no longer valid. Any repetition of the old news is total fud. We have for many months now been providing proper source releases for EVERYTHING in the maven project and just recently promoted the same to the Apache pom making it automatic for any Apache project with the new pom. See links below for more info: http://old.nabble.com/Update-on-ASF-Release-requirements-ts23379350.html#a23379350 http://old.nabble.com/-VOTE--Apache-%28parent-POM%29-version-7-ts26221188.html As far as I understand the requirements, this issue is completely resolved so lets stop saying that Maven produces incorrect releases. It was never an issue with the tool itself, but as a project we've fixed it and are sharing it to all projects at Apache using Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed November 11 2009 4:52:23 pm Davanum Srinivas wrote: Brian, Do you mind sending an email to pmcs AT apache.org to inform them that they should be using this new version of Apache pom? And any other additional instructions needed to enable this feature to work. Why? It's up to each project to get their releases correct. That version of the Apache pom isn't required to get the needed source bundles created. I know for CXF, the current parent poms don't work at all and thus we SHOULDN'T use it. Dan thanks, dims On 11/11/2009 03:51 PM, Brian Fox wrote: What is happening in some Java projects, via Maven's release plugin, is disturbing since the source release only exist in the subversion repository This problem has been solved and is no longer valid. Any repetition of the old news is total fud. We have for many months now been providing proper source releases for EVERYTHING in the maven project and just recently promoted the same to the Apache pom making it automatic for any Apache project with the new pom. See links below for more info: http://old.nabble.com/Update-on-ASF-Release-requirements-ts23379350.html# a23379350 http://old.nabble.com/-VOTE--Apache-%28parent-POM%29-version-7-ts26221188 .html As far as I understand the requirements, this issue is completely resolved so lets stop saying that Maven produces incorrect releases. It was never an issue with the tool itself, but as a project we've fixed it and are sharing it to all projects at Apache using Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Dan, It's up to each project to get their releases correct - Yes. But not everyone hangs out on the d...@maven or gene...@incubator. Hence the request to broadcast. I really don't understand the why? - No one is trying to mandate using a specific pom across all PMC(s). Just the fact that there was a problem that was actively worked on and fixed and the proposed solution. Basically telling pmcs take it or leave it. At the very least pay attention that the jars that they release should be build-able using the source zip(s). -- dims On 11/11/2009 05:22 PM, Daniel Kulp wrote: On Wed November 11 2009 4:52:23 pm Davanum Srinivas wrote: Brian, Do you mind sending an email to pmcs AT apache.org to inform them that they should be using this new version of Apache pom? And any other additional instructions needed to enable this feature to work. Why? It's up to each project to get their releases correct. That version of the Apache pom isn't required to get the needed source bundles created. I know for CXF, the current parent poms don't work at all and thus we SHOULDN'T use it. Dan thanks, dims On 11/11/2009 03:51 PM, Brian Fox wrote: What is happening in some Java projects, via Maven's release plugin, is disturbing since the source release only exist in the subversion repository This problem has been solved and is no longer valid. Any repetition of the old news is total fud. We have for many months now been providing proper source releases for EVERYTHING in the maven project and just recently promoted the same to the Apache pom making it automatic for any Apache project with the new pom. See links below for more info: http://old.nabble.com/Update-on-ASF-Release-requirements-ts23379350.html# a23379350 http://old.nabble.com/-VOTE--Apache-%28parent-POM%29-version-7-ts26221188 .html As far as I understand the requirements, this issue is completely resolved so lets stop saying that Maven produces incorrect releases. It was never an issue with the tool itself, but as a project we've fixed it and are sharing it to all projects at Apache using Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Actually, the vote was kind of withdrawn to update it to new descriptors. Thus, its not available yet. In anycase, no need to spam all the PMCs, especially those not using Maven. Just keep an eye on the annou...@maven list. When available, it will be announced there. Dan On Wed November 11 2009 4:52:23 pm Davanum Srinivas wrote: Brian, Do you mind sending an email to pmcs AT apache.org to inform them that they should be using this new version of Apache pom? And any other additional instructions needed to enable this feature to work. thanks, dims On 11/11/2009 03:51 PM, Brian Fox wrote: What is happening in some Java projects, via Maven's release plugin, is disturbing since the source release only exist in the subversion repository This problem has been solved and is no longer valid. Any repetition of the old news is total fud. We have for many months now been providing proper source releases for EVERYTHING in the maven project and just recently promoted the same to the Apache pom making it automatic for any Apache project with the new pom. See links below for more info: http://old.nabble.com/Update-on-ASF-Release-requirements-ts23379350.html# a23379350 http://old.nabble.com/-VOTE--Apache-%28parent-POM%29-version-7-ts26221188 .html As far as I understand the requirements, this issue is completely resolved so lets stop saying that Maven produces incorrect releases. It was never an issue with the tool itself, but as a project we've fixed it and are sharing it to all projects at Apache using Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
I think this is a pretty important issue worth spamming but whatever -- dims On 11/11/2009 05:43 PM, Daniel Kulp wrote: Actually, the vote was kind of withdrawn to update it to new descriptors. Thus, its not available yet. In anycase, no need to spam all the PMCs, especially those not using Maven. Just keep an eye on the annou...@maven list. When available, it will be announced there. Dan On Wed November 11 2009 4:52:23 pm Davanum Srinivas wrote: Brian, Do you mind sending an email to pmcs AT apache.org to inform them that they should be using this new version of Apache pom? And any other additional instructions needed to enable this feature to work. thanks, dims On 11/11/2009 03:51 PM, Brian Fox wrote: What is happening in some Java projects, via Maven's release plugin, is disturbing since the source release only exist in the subversion repository This problem has been solved and is no longer valid. Any repetition of the old news is total fud. We have for many months now been providing proper source releases for EVERYTHING in the maven project and just recently promoted the same to the Apache pom making it automatic for any Apache project with the new pom. See links below for more info: http://old.nabble.com/Update-on-ASF-Release-requirements-ts23379350.html# a23379350 http://old.nabble.com/-VOTE--Apache-%28parent-POM%29-version-7-ts26221188 .html As far as I understand the requirements, this issue is completely resolved so lets stop saying that Maven produces incorrect releases. It was never an issue with the tool itself, but as a project we've fixed it and are sharing it to all projects at Apache using Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 5:50 PM, Davanum Srinivas dava...@gmail.com wrote: I think this is a pretty important issue worth spamming but whatever I think it's worth noting, I've had several projects asking for it to be available so they can use it and ditch their homebrew solutions. When it's promoted to the repo, I'll send a notice. Dan, perhaps on the maven dev list, I'd like to understand why it won't work for cxf...but fwiw, we made it possible to replace the default descriptor bundle with your own so hopefully even if we can't make the descriptor work for cxf, the rest is still applicable. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Thanks Brian! On 11/11/2009 06:22 PM, Brian Fox wrote: On Wed, Nov 11, 2009 at 5:50 PM, Davanum Srinivasdava...@gmail.com wrote: I think this is a pretty important issue worth spamming but whatever I think it's worth noting, I've had several projects asking for it to be available so they can use it and ditch their homebrew solutions. When it's promoted to the repo, I'll send a notice. Dan, perhaps on the maven dev list, I'd like to understand why it won't work for cxf...but fwiw, we made it possible to replace the default descriptor bundle with your own so hopefully even if we can't make the descriptor work for cxf, the rest is still applicable. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Serf vs Neon (was Re: [PROPOSAL][VOTE] Subversion)
Is this topic really appropriate for incubator general? I'm having trouble following along with all the noise. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Serf vs Neon (was Re: [PROPOSAL][VOTE] Subversion)
On Wed, Nov 11, 2009 at 20:48, Ralph Goers ralph.go...@dslextreme.com wrote: Is this topic really appropriate for incubator general? I'm having trouble following along with all the noise. At the root, it is a discussion about LGPL dependencies in an incoming podling. Neon is LGPL. Serf is ALv2. Both are optional, though you really want to choose one for a broadly-useful svn build. In the past, Neon was the default. For 1.7, serf is going to be the default, although a few people in the community are wary of that choice. HTH, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Serf vs Neon (was Re: [PROPOSAL][VOTE] Subversion)
On Nov 11, 2009, at 7:27 PM, Greg Stein wrote: On Wed, Nov 11, 2009 at 20:48, Ralph Goers ralph.go...@dslextreme.com wrote: Is this topic really appropriate for incubator general? I'm having trouble following along with all the noise. At the root, it is a discussion about LGPL dependencies in an incoming podling. Neon is LGPL. Serf is ALv2. Both are optional, though you really want to choose one for a broadly-useful svn build. In the past, Neon was the default. For 1.7, serf is going to be the default, although a few people in the community are wary of that choice. yes, I got that. But all the discussion about whether serf is an acceptable replacement or whether eclipse will use it doesn't belong here. I got the impression with the first post on the topic that the Subversion community already understood the issue. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Greg Stein wrote: The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. +1 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
C. Michael Pilato wrote: Our goal is to bring our Serf integration up to the quality (in terms of both user experience and proper API adherence) of our Neon one so that Serf can safely become the new default DAV RA implementation, yes. It's mostly there, but still contains a few gotchas. We've switched our trunk (1.7-aimed) code to use Serf as the default if both it and Neon are found, but that change could be reverted (restoring the use of Neon as the default) if we aren't able to iron out the Serf integration shortcomings in a timely fashion. Michael, this is a very good news and it's good that you work on it now, because licensing issues (Neon license incompatibility) are very important for us. Hope that you will manage to do it if for SVN 1.7. Thanks, Igor -- View this message in context: http://old.nabble.com/-PROPOSAL--VOTE--Subversion-tp26203843p26280942.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Igor Burilo wrote: C. Michael Pilato wrote: Our goal is to bring our Serf integration up to the quality (in terms of both user experience and proper API adherence) of our Neon one so that Serf can safely become the new default DAV RA implementation, yes. It's mostly there, but still contains a few gotchas. We've switched our trunk (1.7-aimed) code to use Serf as the default if both it and Neon are found, but that change could be reverted (restoring the use of Neon as the default) if we aren't able to iron out the Serf integration shortcomings in a timely fashion. Michael, this is a very good news and it's good that you work on it now, because licensing issues (Neon license incompatibility) are very important for us. Hope that you will manage to do it if for SVN 1.7. Thanks, Igor I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato cmpil...@collab.net wrote: ... I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? If the Apache software is *non-functional* without the LGPL software, then you are effectively requiring downstream users to link themselves into the LGPL licensing. Since Subversion does not require any LGPL to function, then we should be just fine. I plan to run this past legal-discuss for verification (along with our optional GNOME, KDE, and BDB dependencies). I seem to recall from the legal web pages there is no specific mention of our case, so wanted to double-check and then possible add our use-case to those pages. Regarding serf and Neon, I think that serf will be just fine to have as a default. It has been totally functional for many of us (cmpilato is a serf skeptic :-P) Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein gst...@gmail.com wrote: On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato cmpil...@collab.net wrote: ... I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? If the Apache software is *non-functional* without the LGPL software, then you are effectively requiring downstream users to link themselves into the LGPL licensing. Since Subversion does not require any LGPL to function, then we should be just fine. I plan to run this past legal-discuss for verification (along with our optional GNOME, KDE, and BDB dependencies). I seem to recall from the legal web pages there is no specific mention of our case, so wanted to double-check and then possible add our use-case to those pages. Regarding serf and Neon, I think that serf will be just fine to have as a default. It has been totally functional for many of us (cmpilato is a serf skeptic :-P) He is not the only one :) That said, I think the point is why should the default matter? We can either optionally use Neon or we cannot. Even if Neon is the default, if someone builds with only Serf then it becomes the default. As Mike says, we do not provide binaries so we will not be asking to distribute any of these libraries. We will need to find out if it is OK to still supply our dependencies tarball for convenience. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 10:28 AM, Niclas Hedhman nic...@hedhman.org wrote: The binaries doesn't matter, Apache releases source code, licensed under Apache license v2.0. And we only distribute certain licensed dependencies. As Greg said, we need to provide solutions that does not force downstream users into the (L)GPL world. So, a project that requires these dependencies are a no-no. Optionality is key here. As for the virality of some licenses it is also important to ensure that it doesn't leak into Apache code bases. I don't think this is even close to be the case here. IMHO, this looks like a simple case and legal-discuss@ should be able to provide a definitive answer quickly. IIRC, redistributing the LGPL code would not be allowed. These things all make sense and given that Neon (and the other dependencies) are all optional then I do not think it should be an issue. The question I was asking, is why should it matter what the default is? The default only applies to someone that builds a binary that includes both Neon and Serf. The subversion project ought to be able to decide which library is the appropriate default in this situation. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
The binaries doesn't matter, Apache releases source code, licensed under Apache license v2.0. And we only distribute certain licensed dependencies. As Greg said, we need to provide solutions that does not force downstream users into the (L)GPL world. So, a project that requires these dependencies are a no-no. Optionality is key here. As for the virality of some licenses it is also important to ensure that it doesn't leak into Apache code bases. I don't think this is even close to be the case here. IMHO, this looks like a simple case and legal-discuss@ should be able to provide a definitive answer quickly. IIRC, redistributing the LGPL code would not be allowed. -- Niclas On 10 Nov 2009 23:17, Mark Phippard markp...@gmail.com wrote: On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein gst...@gmail.com wrote: On Tue, Nov 10, 2009 at 09:... He is not the only one :) That said, I think the point is why should the default matter? We can either optionally use Neon or we cannot. Even if Neon is the default, if someone builds with only Serf then it becomes the default. As Mike says, we do not provide binaries so we will not be asking to distribute any of these libraries. We will need to find out if it is OK to still supply our dependencies tarball for convenience. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: gener...
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 7:10 AM, Greg Stein wrote: On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato cmpil...@collab.net wrote: ... I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? If the Apache software is *non-functional* without the LGPL software, then you are effectively requiring downstream users to link themselves into the LGPL licensing. Since Subversion does not require any LGPL to function, then we should be just fine. I plan to run this past legal-discuss for verification (along with our optional GNOME, KDE, and BDB dependencies). I seem to recall from the legal web pages there is no specific mention of our case, so wanted to double-check and then possible add our use-case to those pages. Regarding serf and Neon, I think that serf will be just fine to have as a default. It has been totally functional for many of us (cmpilato is a serf skeptic :-P) Not yet though. It still fails in places that neon works. Blair - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
C. Michael Pilato wrote: I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? Michael, sure Neon and Serf are optional and it’s absolutely correct from the legal point of view. But in this case SVN should work without DAV support, which is important for end-users. When we talk about licensing issues we mean problem with entire SVN acceptance and distribution. In particular, it’s a big problem for Eclipse community and companies that stay behind this community. To accept SVN they require a legally clean pre-built solution. It means that at least JavaHL client should be EPL (Apache 2.0) compatible. Now it doesn’t because of Neon. Sure, someone can tell – build distribution yourself with Serf, but we understand that result isn’t guaranteed at the current moment, so this solution will not be accepted. Another approach to allow users build library by themselves will not work, because require knowledge and experience from end-users. At the current moment SVN client can’t pass legal review on Eclipse and it means that SVN loosing its huge potential there. It’s a perfect example when nice technology is blocked by legal tricks. So the perfect solution will be to replace Neon by Serf, because it will resolve a lot of issues described above with SVN acceptance. -- View this message in context: http://old.nabble.com/-PROPOSAL--VOTE--Subversion-tp26203843p26286015.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 9:16 AM, Mark Phippard wrote: On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein gst...@gmail.com wrote: On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato cmpil...@collab.net wrote: ... I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? If the Apache software is *non-functional* without the LGPL software, then you are effectively requiring downstream users to link themselves into the LGPL licensing. Since Subversion does not require any LGPL to function, then we should be just fine. I plan to run this past legal-discuss for verification (along with our optional GNOME, KDE, and BDB dependencies). I seem to recall from the legal web pages there is no specific mention of our case, so wanted to double-check and then possible add our use-case to those pages. Regarding serf and Neon, I think that serf will be just fine to have as a default. It has been totally functional for many of us (cmpilato is a serf skeptic :-P) He is not the only one :) That said, I think the point is why should the default matter? We can either optionally use Neon or we cannot. Even if Neon is the default, if someone builds with only Serf then it becomes the default. As Mike says, we do not provide binaries so we will not be asking to distribute any of these libraries. We will need to find out if it is OK to still supply our dependencies tarball for convenience. And if we can't ship the deps tarballs, you won't find me (the current release manager) shedding any tears. I don't have any statistics to back it up, but I tend to thinks the deps tarball is pretty underutilized. I don't think it would have a negative impact on our users or release process. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Just recently, we had a very active discussion regarding Maven where the emphasis was laid very heavily on the distributable archives (binary and source) as the endorsed result of the release/vote process. Jochen -- Germanys national anthem is the most boring in the world - how telling! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:16, Blair Zajac bl...@orcaware.com wrote: On Nov 10, 2009, at 7:10 AM, Greg Stein wrote: On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato cmpil...@collab.net wrote: ... I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? If the Apache software is *non-functional* without the LGPL software, then you are effectively requiring downstream users to link themselves into the LGPL licensing. Since Subversion does not require any LGPL to function, then we should be just fine. I plan to run this past legal-discuss for verification (along with our optional GNOME, KDE, and BDB dependencies). I seem to recall from the legal web pages there is no specific mention of our case, so wanted to double-check and then possible add our use-case to those pages. Regarding serf and Neon, I think that serf will be just fine to have as a default. It has been totally functional for many of us (cmpilato is a serf skeptic :-P) Not yet though. It still fails in places that neon works. Anything besides 1.0 proxies? Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 10:29 AM, Jochen Wiedmann wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Just recently, we had a very active discussion regarding Maven where the emphasis was laid very heavily on the distributable archives (binary and source) as the endorsed result of the release/vote process. The reason we (Subversion) do not ship binaries is simple: we don't have the resources to meet the request, and most of our users use Subversion as part of a third-party tool, which most often *does* ship as a binary. We've supported community efforts to create binaries, even going so far as to host selected variants on our downloads page, but they are still not considered official artifacts of the project. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:29, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Just recently, we had a very active discussion regarding Maven where the emphasis was laid very heavily on the distributable archives (binary and source) as the endorsed result of the release/vote process. In httpd, we release tarballs and zips. Then some committers volunteer prebuilts. wrowe always built Windows releases, but I don't think that was ever mandated. The svn release process also produces tarballs and zips (in case that wasn't clear). We just don't do prebuilts. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Mark Phippard wrote: I gave counsel to the Eclipse Foundation and explained that they could provide a fully functioning JavaHL library to users with only EPL compatible code. Basically, you just need to build without Neon, BDB and libintl support. Of the three, the only thing an Eclipse client user needs is Neon, and Serf serves as a viable replacement. I do not know why they never chose to release a binary built this way. I can only assume that Igor and Polarion did not want to make these binaries. I suspect IBM's ICU lib could be substituted for libintl, and as there is some traction on the idea of dumping apr-iconv, this would be a sensible thing (since ICU is the heir apparent for non-iconv based platforms). I keep reading The project doesn't release binaries. Who will, Tigris? Collab? Yo momma? One of the greatest advantages is that committers who wish to package binaries can do so under the ASF umbrella, something that in this litigious society I would never consider doing now. So is the project doesn't release binaries mantra a statement about the past practices, a tacit or explicit contract in bringing this to the ASF, or just the posters' personal preference? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
William A. Rowe Jr. wrote: Mark Phippard wrote: I gave counsel to the Eclipse Foundation and explained that they could provide a fully functioning JavaHL library to users with only EPL compatible code. Basically, you just need to build without Neon, BDB and libintl support. Of the three, the only thing an Eclipse client user needs is Neon, and Serf serves as a viable replacement. I do not know why they never chose to release a binary built this way. I can only assume that Igor and Polarion did not want to make these binaries. I suspect IBM's ICU lib could be substituted for libintl, and as there is some traction on the idea of dumping apr-iconv, this would be a sensible thing (since ICU is the heir apparent for non-iconv based platforms). I keep reading The project doesn't release binaries. Who will, Tigris? Collab? Yo momma? One of the greatest advantages is that committers who wish to package binaries can do so under the ASF umbrella, something that in this litigious society I would never consider doing now. So is the project doesn't release binaries mantra a statement about the past practices, a tacit or explicit contract in bringing this to the ASF, or just the posters' personal preference? Wait a minute. Are you implying that the project *should* release binaries? Wouldn't such a requirement apply to, say, APR, to keep this close to home? Certainly any volunteer with proper karma can build binaries from the release tarballs, and if those binaries happen to pass muster wrt ASF-mandated legalities, then from my understanding it should be OK to host such binaries on ASF's infrastructure. But that's not the same as the project releasing those binaries -- lack of digital sigs on them is a dead giveaway. How many APR and/or httpd commiters sign your Windows binary packages? -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 12:52 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Mark Phippard wrote: I gave counsel to the Eclipse Foundation and explained that they could provide a fully functioning JavaHL library to users with only EPL compatible code. Basically, you just need to build without Neon, BDB and libintl support. Of the three, the only thing an Eclipse client user needs is Neon, and Serf serves as a viable replacement. I do not know why they never chose to release a binary built this way. I can only assume that Igor and Polarion did not want to make these binaries. I suspect IBM's ICU lib could be substituted for libintl, and as there is some traction on the idea of dumping apr-iconv, this would be a sensible thing (since ICU is the heir apparent for non-iconv based platforms). We use this for translating error messages etc. I do not recall ICU having a feature like that. Not to mention how big it is. We have talked about using ICU in the past to improve Unicode support and deal with normalization issues. I keep reading The project doesn't release binaries. Who will, Tigris? Tigris is just a hosting service not an entity. Collab? Yo momma? One of the greatest advantages is that committers who wish to package binaries can do so under the ASF umbrella, something that in this litigious society I would never consider doing now. There are lots of people that provide binaries. See here: http://subversion.tigris.org/getting.html#binary-packages For Windows, there are several sources (all free) and all with their own differences based on what it is that you want. So is the project doesn't release binaries mantra a statement about the past practices, a tacit or explicit contract in bringing this to the ASF, or just the posters' personal preference? I do not believe the project wants to be in the business of providing binaries and we have an existing ecosystem of people that are providing them successfully. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Branko Čibej wrote: Wait a minute. Are you implying that the project *should* release binaries? Wouldn't such a requirement apply to, say, APR, to keep this close to home? s/should/may/ Greg pointed out I make win32 binaries and these are not mandated, I do so only because I trusted that typical win32 users wouldn't know a compiler if it bit them on the toe, and the httpd project/ASF lets me do this -for the project-. Yes, the release is a bunch of source code. The resulting binaries (or .jar file or whatever) is simply an artifact but is provided by the ASF, not I personally. My point is that we categorically do not host outside party binaries here (if you want, invite them to become committers). We need them bound by a CLA before an artifact they roll is posted on ASF infrastructure. Certainly any volunteer with proper karma can build binaries from the release tarballs, and if those binaries happen to pass muster wrt ASF-mandated legalities, then from my understanding it should be OK to host such binaries on ASF's infrastructure. But that's not the same as the project releasing those binaries -- lack of digital sigs on them is a dead giveaway. Howso? How many APR and/or httpd commiters sign your Windows binary packages? Only one; my own gpg key, look at that chain of trust and you'll find at least 2 more httpd (apr) committers who have signed that key. I have never released any artifacts - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Mark Phippard wrote: I do not believe the project wants to be in the business of providing binaries and we have an existing ecosystem of people that are providing them successfully. As long as non-committer artifacts aren't hosted here, that is no trouble. If nobody on SVN wants to create them for shipping from the ASF dist pages then that is what will happen, none will ship :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:29 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Umm, how is it a completely new philosophy for an Apache project? There are a number of Apache projects that ship source without official binaries. APR and the Apache HTTPD server are two prime examples. Don't assume that the way the projects you're familiar with are run is the only way to run ASF projects. -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 14:23, Garrett Rooney roo...@electricjellyfish.net wrote: On Tue, Nov 10, 2009 at 11:29 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Umm, how is it a completely new philosophy for an Apache project? There are a number of Apache projects that ship source without official binaries. APR and the Apache HTTPD server are two prime examples. Don't assume that the way the projects you're familiar with are run is the only way to run ASF projects. Maybe it is the difference between shipping .jar files and (say) Windows executables? I can easily see a misunderstanding there (why ship just .java files? why not a .jar?) Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 8:29 AM, Jochen Wiedmann wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Apache's distributions are source distributions as a requirement. Binary distributions are just a convenience for users. If subversion doesn't see any benefit for the project or for users to release binaries, it is not a requirement. Especially as third parties are providing binaries. Just the licensing/trademark issue of what the third parties call their releases. Which question is best left to our licensing/trademark team. Craig Jochen To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 12:29 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. Not new at all. I know that one of the oldest Java projects here, Cocoon, once only released buildable(!) source code. What is happening in some Java projects, via Maven's release plugin, is disturbing since the source release only exist in the subversion repository. The -source.jar is packaged in a non-buildable format optimized for IDE source integration and not to be reproducable. Some ASF projects (I think including some of Maven's own artifacts and subprojects) are now in total opposite of old school source releases and effectively only releases binaries containing re-packaged sources and one has to go to source repository to find the 'real' source code for that release. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Mon, Nov 9, 2009 at 2:26 AM, Niclas Hedhman nic...@hedhman.org wrote: On Mon, Nov 9, 2009 at 7:39 AM, Leo Simons m...@leosimons.com wrote: PS: +1 to start incubation obviously. The record is 2 weeks set for MerlinDeveloper back in 2003...you have 9 days left to try and beat it Hey, you snipped the smiley! I'm going to stubbornly add it back in: :) Smileys matter :) Now, I intended to convey perhaps a few things: * I wouldn't mind at all seeing svn graduate a few weeks after it starts incubation * there is even reasonable precedent for that kind of speed * this is not really a very important topic, its a P.S. at most Obviously I have to work on my communication skills, since it seems like you read this as something completely different. snip rant/ I am ashamed of us... I have no idea what might be going on in your head, but from where I sit, it seems like you might be overreacting just a _bit_ to a tongue-in-cheek e-mail post script. Have some green tea. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Leo Simons wrote: I have no idea what might be going on in your head, but from where I sit, it seems like you might be overreacting just a _bit_ to a tongue-in-cheek e-mail post script. Have some green tea. There were also some suggestions about us making a release for the sake of making a release, never mind that it would be broken and useless. But Greg already ranted about that, and he rants a lot better than I do when he puts his mind to it. span mode=do-not-delete:)/span All in all, I think we know how to make releases, and moreover we know hot to *not* make releases. Right, Leo? :) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) Neon is currently Subversion's default RA DAV layer. But Neon's license (LGPL) isn't compatible with Apache License and as Neon is optional, will Serf library become a default one? From the other side, Serf library is considered as experimental, though it appears to work in the common cases quite well. Thanks, Igor -- View this message in context: http://old.nabble.com/-PROPOSAL--VOTE--Subversion-tp26203843p26269837.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Igor Burilo wrote: We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) Neon is currently Subversion's default RA DAV layer. But Neon's license (LGPL) isn't compatible with Apache License and as Neon is optional, will Serf library become a default one? From the other side, Serf library is considered as experimental, though it appears to work in the common cases quite well. Our goal is to bring our Serf integration up to the quality (in terms of both user experience and proper API adherence) of our Neon one so that Serf can safely become the new default DAV RA implementation, yes. It's mostly there, but still contains a few gotchas. We've switched our trunk (1.7-aimed) code to use Serf as the default if both it and Neon are found, but that change could be reverted (restoring the use of Neon as the default) if we aren't able to iron out the Serf integration shortcomings in a timely fashion. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL][VOTE] Subversion
On Mon, Nov 9, 2009 at 9:56 PM, Leo Simons m...@leosimons.com wrote: I have no idea what might be going on in your head, but from where I sit, it seems like you might be overreacting just a _bit_ to a tongue-in-cheek e-mail post script. Have some green tea. What is/was going on in my head is expressed gracefully by Greg in separate thread. alert type=smiley ;-) /alert Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Fri, Nov 6, 2009 at 7:46 PM, Greg Stein gst...@gmail.com wrote: On Fri, Nov 6, 2009 at 14:44, Greg Stein gst...@gmail.com wrote: All of the existing tags/branches of svn use a tweaked Apache Software License, v1.1, and generally have a file header claims a copyright by CollabNet. trunk is licensed under Apache License, v2, and has a file header as defined by the Apache Legal Affairs Committee, though with SVNCorp rather than ASF as the rights-holder to the distribution. After we import the codebase, we intend to tweak all of the file headers on trunk with s/SVNCorp/ASF/. To clarify this further: I believe that a release from *trunk* matches a standard Apache release. Well, at the moment, probably not quite. In particular, the incubator PMC is (in)famous for being very nitpicky (err, careful) about licensing stuff, it's an enlightening experience to go through I would say. You might want to have some fun with RAT: http://incubator.apache.org/rat/ It finds things like this: * No license header (some examples): ./subversion/bindings/swig/ruby/svn/core.rb ./tools/bdb/svnfs.py ./tools/client-side/server-version.py * GPL license header (I understand why, but, ugh): ./build/config.guess (and some 600 other complaints most of which are readily ignorable). The various tools and scripts that say stuff like released under the same license as subversion could probably do with a little attention as well. AIUI it from reading dist.sh those files would go into the released tarball (I didn't attempt to actually run dist.sh, that'd take me too much time to try and do properly). Oh and according to what I read the other day on legal-disc...@a.o the reference to the license details about the python bindings probably ought to belong in the LICENSE file not in the NOTICE file. On Sat, Nov 7, 2009 at 12:07 AM, Greg Stein gst...@gmail.com wrote: We're not ready for an alpha, but we could do an internal experimental release. I seem to recall seeing that in the docs. How about that? Sure :) ciao, Leo PS: +1 to start incubation obviously. The record is 2 weeks set for MerlinDeveloper back in 2003...you have 9 days left to try and beat it :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Mon, Nov 9, 2009 at 7:39 AM, Leo Simons m...@leosimons.com wrote: PS: +1 to start incubation obviously. The record is 2 weeks set for MerlinDeveloper back in 2003...you have 9 days left to try and beat it That is kind of incorrect. MerlinDeveloper went through Incubation, in what we today call IP Clearance, i.e. 'code import with a single developer', so the comparison is not accurate. Either way, I am very happy to see Greg being as patient as he is. Kudos! Having a release process that is more stringent than ASF's norm, managing a high rate of releases, having all the experience of ~15 years in Apache releases, and then getting lectured by Incubator Process Riders can't feel very constructive. Some people seem to forget that ASF releases are not flawless (since it is software it is almost by definition, it seems), neither code-wise nor legally. The real value of ASF is that we try out best, and will take corrective action in case we find a problem. But so does many other communities. And IMHO, when we are dealing with a community that has a user base, equal to or greater than the largest of our own projects (my guess is that only Httpd and indirectly therefor APR) has more users than Subversion, then we need to adjust our behavior to accommodate the special needs that exists; frequent releases, in fact a cornerstone in our amibitions; Release Early, Release Often. Subversion has made (if I count correctly, skipping 1.0.x) made 32 releases in a bit more than 4 years, shall we say 4-6 weeks per release, or possibly about the same time it takes us to approve a release... :-( If anything, I think we (the Incubator) have something to learn from these projects, more than the other way around. So, get off your high horses and start thinking again... I am ashamed of us... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 Thanks, Senaka. On Thu, Nov 5, 2009 at 1:42 AM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot
Re: [PROPOSAL][VOTE] Subversion
FYI: Daniel's CLA was recorded last evening. Craig On Nov 5, 2009, at 7:34 AM, Greg Stein wrote: Daniel Shahaf has already sent his signed CLA to the ASF Secretary, so we'll soon be asking for ana account for him. Cheers, -g Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [PROPOSAL][VOTE] Subversion
+1 for incubation. On Nov 5, 2009, at 8:20 AM, Greg Stein wrote: I do not expect Subversion to make a release while in Incubation. Our next big release is 1.7, and is expected in (hopefully?) Q1 next year. There is a chance that we'd like to release 1.6.7 while we're incubating. That can be a bridge to cross later. I do not expect to vote Subversion out of incubation until they make a release. That's the proof that the team knows how to do an Apache release. I don't really care how many releases they have made on their own. Regards, Craig Cheers, -g Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: [PROPOSAL][VOTE] Subversion
+1 to begin Incubation --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Greg Stein wrote: David Crossley wrote: [snip] ... I think there is going to be some concern that we're forcing/rushing the process, but I believe the speed is simply a function of the awesome match in ideals. Agreed. Perhaps this Vote phase should run for a while. (I am thinking about setting precedents for other incubation proposals.) I was planning a standard 72-hour vote, concluding Saturday. Do you feel that it should be extended further? If it was any other group, then i would be more concerned. Because Subversion has such a synergy with ASF, then okay. By the way, it would probably be good to list your initial committers in the proposal, as we suggest for other proponents. That adds it to these mail list archives. The proposal included the list by reference (http://svn.collab.net/repos/svn/trunk/COMMITTERS). Do you think it best to be explicit, and list them in this thread? In general i do think it best to be explicit. We ask others to. Because you refer to a file in yesterday's SVN with explicit line numbers, then i am happier. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 :-) On Wed, Nov 4, 2009 at 9:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at
Re: [PROPOSAL][VOTE] Subversion
+1 from me. On 11/04/2009 03:36 PM, Matthias Wessendorf wrote: +1 :-) On Wed, Nov 4, 2009 at 9:12 PM, Greg Steingst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or=GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. +1, good luck on the incubation :-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 Regards Felix Greg Stein schrieb: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot
Re: [PROPOSAL][VOTE] Subversion
+1 - richard On 11/4/09 15:50, Felix Meschberger wrote: +1 Regards Felix Greg Stein schrieb: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or=GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our
Re: [PROPOSAL][VOTE] Subversion
+1 Ate Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at
Re: [PROPOSAL][VOTE] Subversion
On Nov 4, 2009, at 3:12 PM, Greg Stein wrote: The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Nah -1... Bazinga! :) *snicker* *snicker* Of course, a big +1 ! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 4, 2009 at 3:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. +1 -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 -- Martin Cooper On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot
Re: [PROPOSAL][VOTE] Subversion
On Wed 04 Nov 2009 12:12, Greg Stein gst...@gmail.com wrote: Initial Committers The list of initial committers is at http://svn.collab.net/repos/svn/trunk/COMMITTERS. The initial PMC members are those listed as full committers in that file (lines 1-74). Sponsors * Champion: Greg Stein * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel Rall * Sponsor: Quite a collection of shady characters, but... +1 :-) -- J. Aaron Farr 馮傑仁 www.cubiclemuses.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Big +1 :) On Wed, Nov 4, 2009 at 11:06 PM, J Aaron Farr fa...@apache.org wrote: On Wed 04 Nov 2009 12:12, Greg Stein gst...@gmail.com wrote: Initial Committers The list of initial committers is at http://svn.collab.net/repos/svn/trunk/COMMITTERS. The initial PMC members are those listed as full committers in that file (lines 1-74). Sponsors * Champion: Greg Stein * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel Rall * Sponsor: Quite a collection of shady characters, but... +1 :-) -- J. Aaron Farr 馮傑仁 www.cubiclemuses.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour - LinkedIn: http://www.linkedin.com/in/mnour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 2009/11/4 Greg Stein gst...@gmail.com: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at
Re: [PROPOSAL][VOTE] Subversion
On 11/04/2009 09:12 PM, Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. +1 Cheers Jean-Frederic - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 Bill Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at http://buildbot.subversion.org/buildbot/ Note that we request these resources to be at their final
Re: [PROPOSAL][VOTE] Subversion
+1 -jean Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at http://buildbot.subversion.org/buildbot/ Note that we request these resources to be at their
Re: [PROPOSAL][VOTE] Subversion
+1 Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at http://buildbot.subversion.org/buildbot/ Note that we request these resources to be at their final
Re: [PROPOSAL][VOTE] Subversion
+1 On 04/11/2009, at 12:12 PM, Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at http://buildbot.subversion.org/buildbot/ Note that we request these resources to be at their
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein gst...@gmail.com wrote: The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Sponsors * Champion: Greg Stein * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel Rall +1 for acceptance. w...0...0...t. =) -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Justin Erenkrantz wrote: On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein gst...@gmail.com wrote: The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. +1 -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Sr. System Admin, Ridecharge Inc. Consultant, P6M7G8 Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 4, 2009 at 3:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own +1. Yoav - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 Ralph On Nov 4, 2009, at 12:12 PM, Greg Stein wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at http://buildbot.subversion.org/buildbot/ Note that we request these resources to be at
Re: [PROPOSAL][VOTE] Subversion
As expected overwhelming support. +1 Interesting incubation, as failure is not an option no matter what... Welcome! Niclas On 5 Nov 2009 07:29, Ralph Goers ralph.go...@dslextreme.com wrote: +1 Ralph On Nov 4, 2009, at 12:12 PM, Greg Stein wrote: Subversion is a version control system. You pro...
Re: [PROPOSAL][VOTE] Subversion
+1 On Wed, Nov 4, 2009 at 12:12, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot master is at
Re: [PROPOSAL][VOTE] Subversion
+1! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Hi, +1 Great stuff, welcome! BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein gst...@gmail.com wrote: ... The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation +1 and w00t! -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
I have a couple of questions: Could you be more specific about the problems faced by the Subversion Corporation in its three years of existence and the reasons for merging with the ASF? Do you anticipate whether any of these will cause issues/problems at the ASF? This *feels* like a much bigger project than the usual incubating project - do you have any idea what the impact on ASF infrastructure and resources is going to be in both the short and long term? Besides code and community are there any other assets or resources that the Subversion Corporation intends to transfer to the ASF? Presumably the Subversion Corporation will be wound up if/when it successfully graduates from incubation? Niall On Wed, Nov 4, 2009 at 8:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at
