Re: Subversion vs other source control systems
Use case: work on apache project while on plane --- * export list of jiras of your favorite ASF project into spreadsheet * sync project repo to your laptop * get on a plane for 14 hours * slave away at the bug list, fixing a bunch * create one patch per bug, with a good commit message, referring to the bug report, and commit locally * get off the plane * get online * sync project repo to your laptop * resolve any conflicts * for each bug report * submit and commit the fix * close the bug report This is easy to do with git. It's a small nightmare with SVN, especially if your project is a million lines of code. Sorry for butting in this discussion, but I would like to point out that this is only a problem for the standard Subversion client. As an SVK user (another Subversion client) I regularly make use of off-line commits, local mirroring and smart merges. -- Noah Slater http://bytesexual.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] RE: [VOTE] as to Thrift Proposal
Okay, although I didn't start this vote, as one of the proposed mentors, I'd like to close it. So, we had 17 binding +1 votes, and no 0 or -1 votes, and one non binding vote. Therefore, I declare this vote a success. Welcome, Thrift, to the Apache Incubator. We can now start setting up infrastructure (mailing lists, SVN, jira, eventually web space), and start the process of gathering ICLAs. I'll try to get the lists set up today or tomorrow (and I'll do CouchDB at the same time). Regards, Upayavira On Tue, 2008-02-12 at 23:49 -0800, Mark Slee wrote: It looks like 72 hours have passed since this vote thread started and all responses seem to be positive, which needless to say is great to see. Any last objections? Shall we consider this VOTE thread concluded? If so, let us know how we should proceed with next steps, and we'll start reaching out to patch contributors regarding CLAs, etc. Cheers, Mark -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 4:20 AM To: general@incubator.apache.org Subject: Re: [VOTE] as to Thrift Proposal On Feb 8, 2008 12:27 AM, Ted Husted [EMAIL PROTECTED] wrote: Here's my binding +1 on the Thrift proposal. On Jan 23, 2008 9:07 PM, Mark Slee [EMAIL PROTECTED] wrote: Hi all, We've just posted the Apache Incubator proposal for Thrift onto the Wiki: http://wiki.apache.org/incubator/ThriftProposal +1 Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Seems like people weren't interested in SVK but solely in Git. Otherwise this thread would have come to an end pretty soon without the need of all the FUD cause I suggested/asked to use SVK some days ago already. It doesn't figure why infrastructure stuff needs to be discussed in such a intensity on the incubator list anyway. Just my two cents ... Noah Slater wrote: Sorry for butting in this discussion, but I would like to point out that this is only a problem for the standard Subversion client. As an SVK user (another Subversion client) I regularly make use of off-line commits, local mirroring and smart merges. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release NMaven 0.15-incubating
On the NMaven dev list, we have passed a vote for our first release. We request approval of the release by the IPMC. The 0.15-incubating version supports: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms Staging repo: http://people.apache.org/~sisbell/staging_repo/ Vote Thread: http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html 4 +1 binding (PPMC), 1 +1 non-binding 0 0/-1 Tag: http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/ Thanks, Shane
February 2008 Incubator Board Report
One issue that came up during the past month is regarding the use of org.apache.* package spaces when someone takes ASF code and forks it downstream, releasing a non-ASF codebase using org.apache.* as the namespace. I suggested that the appropriate venue for the discussion was with the Legal Committee, and that no one in the Incubator was authorized by the ASF to provide legal advice, neither on behalf of the ASF nor users of our code. The topic has not been raised on the legal mailing lists as yet. In the specific case of the package(s) in mind, we may end up resurrecting a stalled project. We will see how it goes. A number of projects have been informally or formally proposed for Incubation. Those that we have voted on to accept are: Thrift - http://wiki.apache.org/incubator/ThriftProposal CouchDB - http://wiki.apache.org/incubator/CouchDBProposal PDFBox - http://wiki.apache.org/incubator/PDFBoxProposal CXF and Tuscany did incubation releases. A number of projects are properly recording their IP forms within the Incubator structure. There has been a discussion of source control systems, with some people vocally expressing interest in using another SCM. We have tried to make it clear that projects are not free to choose and/or run alternate critical infrastructure, especially source control, and that the Incubator is not the correct venue to discuss the adoption of a new source control system for the ASF. We've also tried to explain ASF practices regarding collaborative development, independent of technology choice. - February 2008 Board reports for Incubator Projects: === Abdera === Abdera is an implementation of the Atom Syndication Format and Atom Publishing Protocol standards. The Abdera project is preparing release 0.4.0 which includes many new features and improvements including a new StreamWriter interface and a complete refactoring of the Atompub server APIs. The community has continued to grow with patches for bugs and improvements being actively submitted by members of the user community. Once the 0.4.0 release it out the door, the Abdera PMC will likely begin working towards graduation. === Lokahi === Lokahi is a configuration and management console for Apache httpd, tomcat and other web server infrastructure. Incubating since: 2006-01-07 Testing on the MySQL port is continuing. A Fast Feather presentation on Lokahi was given at Apachecon in Atlanta. Recently talk (and some code) has begun around templating of configuration files, specifically for Apache Httpd at this time. And the need to extend Lokahi to manage Geronimo has been mentioned. Obstacles to graduation: * community - now includes authors outside of the original dev community, but additional committers are sought. * licensing - oracle-only back end is now 95% of the way to an alternate MySQL backend, and soon to be enhanced with license agnostic interfaces === NMaven === NMaven develops plugins and integration for Maven to make building and using .NET languages a first-class citizen in Maven. Incubating since: 2006-11-17 Items to resolve before graduation * More active committer involvement. We have two active committers from different organizations but need at least one more. Status: * We are currently voting on our first release. * We have brought NMaven fully in line with Maven architecture. This took a major rewrite of the code. * Steady increase of mailing list subscribers over this period (from 35 to 43). Plans: * We lost a lot of features when we rewrote the code so the plan is to start reimplementing these features. * Proceed with frequent release cycle === PDFBox === PDFBox is an open source Java PDF library for working with PDF documents. PDFBox entered incubation on February 7th, 2008. The PDFBox project has just entered incubation, and we're currently setting up the project infrastructure. A question about the licensing of the JAI dependency was voiced on the mailing list. === RAT === RAT is auditing and comprehension for source code and binary releases. RAT entered incubation in October 2007 but only in the last few weeks started to setup the required infrastructure. Most of this is now in place and the IP clearance for the code import is being worked upon now. === Sling === Sling is a framework to develop content centric web applications based on the idea of modularizing the rendering of HTTP resources. Sling entered incubation on September 5th, 2007. Community * The Sling PPMC voted and passed the Community Roles and Processes document. * Paddy Hannon added as Committer and member of the PPMC Software * The Sling API has been finalized and the project migrated to the new API. * Creation of the Sling Launchpad, based on the former microsling module, provides a ready to run configuration of Sling. * General stabilization of the API and implementation, should lead to a first release
RE: Subversion vs other source control systems
El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió: Santiago Gala wrote: I think git-svn abuses the server a lot, as the subversion server is not designed for copying of the whole history. AFAICS, that's an issue for the Infrastructure Team to address, not the Incubator. Dw wrote: I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? - faster commits, branch switching, pulls and pushs - merges, good and persistent merges - offline work, offline history diffs - rebasing is not such a feature, but it can be useful sometimes - publishing lots of repositories helps surfacing patches that are currently hidden until ready for sending/committing The last one is almost antithetical to how we want people to work. The first few are something that you could raise with the Subversion folks on [EMAIL PROTECTED] Can you elaborate on how is publishing what currently is hidden antithetical to how we want people to work? I think that getting a clear idea on this is important, as I always thought the ASF was about transparency and not keeping information hidden. And I think it is in scope, as the incubator is an important place for people to learn our ways. The inability of subversion to remember merged results makes working in a branch unpractical. Been there, done that, very tricky. Raise any technical issues with the Subversion folks. huh? why? Turning your key poing upside down: We should not try to impose our practices using a technological tool, specially when doing so impairs development. If there is a better SCM *for our way of working* raise that on infra@, too. people *against* changes in SCM is blaming a hypothetical introduction of git of breaking the ASF practices No. This is the wrong forum. What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator. I already tried to move the discussion to [EMAIL PROTECTED], where I think it belongs, but people insists on answering here. Making requests to a closed team in a private list does not accord with *our way of working*, I think. And I don't think there is any need to use a private, unarchived list for discussions on infrastructure improvements. Regards Santiago --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
El dom, 17-02-2008 a las 17:24 -0800, Justin Erenkrantz escribió: On Feb 17, 2008 3:34 PM, Santiago Gala [EMAIL PROTECTED] wrote: Also: you keep a long term branch for doing some refactoring, and you fix small bugs both in HEAD and in a release branch, merging and backporting/forwardporting as you go. Again, something like git makes the work simpler and keeps the disk requirements under control. In an attempt to stop some of the outright FUD in this thread before it goes on to yet another mailing list... outright FUD? Sorry but I don't think there is Fear, Uncertainty or Doubt in this thread. There are several testimonies of good experiences with git, and the only downplay of subversion has been the problems with merging, which I think are real. I would only call FUD if there had been mentions, say, to subversion corrupting repositories or similar, and I think those times are far in the past. I've found that svnmerge.py (distributed with SVN) handles pretty much all of the branch/merge tracking capabilities that I personally care about. (The drawback is that it isn't as efficient as we'd like, but Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a different 1.4.3 Mandriva rpm). I guess they don't ship contrib stuff. Linus Torvalds discusses extensively work flow processes in http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is mostly right in the fact that distribution is the way to go, and not just because of disconnected operation. In one of the projects I track and patch, I don't commit myself, but I have contributed a number of components and patches and I keep ongoing patches. I would never be able to use svnmerge.py without the ability to create branches or commit. it's good enough. The 1.5 stuff is *way* faster.) From your statements, you probably haven't bothered to try svnmerge.py (usable with 1.4.x) or any of the new reintegrate merge stuff in 1.5. It makes it pretty brain-dead simple to handle most branch-oriented merging cases. There are a few pathological cases that don't work well, but that's 'reflective' merging which isn't the 95% use case - so it got punted to post-1.5. (svnmerge.py is probably the 80% use case, with 1.5 merge tracking being 90%, and reflective merging being that last gap...) FWIW, for svn.apache.org, I have a feeling we'll probably be a tad aggressive on rolling out 1.5. (Besides merge tracking, there are a number of excellent features in 1.5: changelist support, interactive conflict resolution, read/write transparent proxies, integrated 'diff -x -p' support, substantial svnsync speed improvements, partial svnsync ability, etc.) Note that nothing is stopping you from using svnmerge.py today. If folks are going to complain about switching to another SCM because of a lack of decent merging, then they owe it to themselves to check out what Subversion can actually do rather than what they think it can do... -- justin Well, I tried svk, git, mercurial and bzr. I am even using darcs because of some openID code I track. I prefer git, even when forced to use git-svn, to svk. Still, I will try to look into svnmerge.py, I found it here http://www.orcaware.com/svn/wiki/Svnmerge.py Regards Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Monday 18 February 2008, Paul Querna wrote: in a private list does not accord with *our way of working*, I think. And I don't think there is any need to use a private, unarchived list for discussions on infrastructure improvements. infrastructure is open to all committers. infrastructure-dev is open to all committers. infrastructure-private is open to all members. All of them are archived. None of them are available to see at: http://mail-archives.apache.org/mod_mbox/ Thus, they look pretty private to me. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release NMaven 0.15-incubating
On 18/02/2008, Shane Isbell [EMAIL PROTECTED] wrote: On the NMaven dev list, we have passed a vote for our first release. We request approval of the release by the IPMC. The 0.15-incubating version supports: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms Staging repo: http://people.apache.org/~sisbell/staging_repo/ The NOTICE files in the jars don't agree with NOTICE.txt in SVN, in that the Copyright says 2002-2008, whereas NOTICE.txt says just 2007. Did the project really start in 2002? Also, the NOTICE file is only supposed to include details of code that is included in the distribution - not any external dependencies. The proper heading is: This product includes software developed by 'etc' There is no need to itemise the individual projects within ASF. See http://www.apache.org/legal/src-headers.html#notice for details. The individual jars seem to have individual NOTICE file headings, e.g. in maven-archetype-windows-application-0.15-incubating-sources.jar the heading reads: maven-archetype-dotnet-windows-application Copyright 2002-2008 The Apache Software Foundation Surely the official name of the project is Apache NMaven ? Unless there is some non-ASF code included in the distribution, then the NOTICE.txt file currently at the root of SVN is all that is needed for the NOTICE in the jar files. == The Manifest.mf files in binary jars should ideally contain the Java compiler source and target versions. There's no need for the .asc.mdf and .asc.sha1 files - an .asc file is only needed to verify the file sig, and if the .asc file is mangled it won't agree with the file it is protecting. Vote Thread: http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html 4 +1 binding (PPMC), 1 +1 non-binding 0 0/-1 Tag: http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/ NOTICE.txt says: Copyright 2007 The Apache Software Foundation That should be Copyright 2007-2008 The Apache Software Foundation - assuming that the project started in 2007. There should ideally be a LICENSE file alongside the NOTICE file. Some of the source files are missing the standard ASF header. Thanks, Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Daniel Kulp wrote: On Monday 18 February 2008, Paul Querna wrote: in a private list does not accord with *our way of working*, I think. And I don't think there is any need to use a private, unarchived list for discussions on infrastructure improvements. infrastructure is open to all committers. infrastructure-dev is open to all committers. infrastructure-private is open to all members. All of them are archived. None of them are available to see at: http://mail-archives.apache.org/mod_mbox/ Thus, they look pretty private to me. They are not available on the public web interface, the archives are available to all committers on people.apache.org. private is an interesting choice of words, but I personally don't consider them very private with 1600++ committers having access. Should some or all of them be available on the web interface? I'm not sure, but bring it up on the infrastructure lists. -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
Daniel Kulp wrote: On Monday 18 February 2008, Paul Querna wrote: in a private list does not accord with *our way of working*, I think. And I don't think there is any need to use a private, unarchived list for discussions on infrastructure improvements. infrastructure is open to all committers. infrastructure-dev is open to all committers. infrastructure-private is open to all members. All of them are archived. None of them are available to see at: http://mail-archives.apache.org/mod_mbox/ The EZMLM archives are available to every subscriber. Send a mail to listname-help to get instructions. There's probably also a way to access raw archives, I'm sure the folks on infra can tell you how to get there. The free-for-everyone archives on mail-archives.a.o are obviously only for list where everyone is allowed to see the messages, not for committers-only lists. There is no archive of [EMAIL PROTECTED] there either. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
On Feb 18, 2008 2:08 PM, Daniel S. Haischt [EMAIL PROTECTED] wrote: Seems like people weren't interested in SVK but solely in Git. Otherwise this thread would have come to an end pretty soon without the need of all the FUD cause I suggested/asked to use SVK some days ago already. the last time i tried SVK, changes would be needed to SVK before it could work with a repository as big as apache - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release NMaven 0.15-incubating
Hi Sebb, Thanks for checking over the staging release. The only missing license headers that I could find are in the unit test and integration test source files. Do test class files also need the license header? Thanks, Shane On Feb 18, 2008 10:59 AM, sebb [EMAIL PROTECTED] wrote: On 18/02/2008, Shane Isbell [EMAIL PROTECTED] wrote: On the NMaven dev list, we have passed a vote for our first release. We request approval of the release by the IPMC. The 0.15-incubating version supports: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms Staging repo: http://people.apache.org/~sisbell/staging_repo/ The NOTICE files in the jars don't agree with NOTICE.txt in SVN, in that the Copyright says 2002-2008, whereas NOTICE.txt says just 2007. Did the project really start in 2002? Also, the NOTICE file is only supposed to include details of code that is included in the distribution - not any external dependencies. The proper heading is: This product includes software developed by 'etc' There is no need to itemise the individual projects within ASF. See http://www.apache.org/legal/src-headers.html#notice for details. The individual jars seem to have individual NOTICE file headings, e.g. in maven-archetype-windows-application-0.15-incubating-sources.jar the heading reads: maven-archetype-dotnet-windows-application Copyright 2002-2008 The Apache Software Foundation Surely the official name of the project is Apache NMaven ? Unless there is some non-ASF code included in the distribution, then the NOTICE.txt file currently at the root of SVN is all that is needed for the NOTICE in the jar files. == The Manifest.mf files in binary jars should ideally contain the Java compiler source and target versions. There's no need for the .asc.mdf and .asc.sha1 files - an .asc file is only needed to verify the file sig, and if the .asc file is mangled it won't agree with the file it is protecting. Vote Thread: http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html 4 +1 binding (PPMC), 1 +1 non-binding 0 0/-1 Tag: http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/ NOTICE.txt says: Copyright 2007 The Apache Software Foundation That should be Copyright 2007-2008 The Apache Software Foundation - assuming that the project started in 2007. There should ideally be a LICENSE file alongside the NOTICE file. Some of the source files are missing the standard ASF header. Thanks, Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release NMaven 0.15-incubating
On 18/02/2008, Shane Isbell [EMAIL PROTECTED] wrote: Hi Sebb, Thanks for checking over the staging release. The only missing license headers that I could find are in the unit test and integration test source files. Do test class files also need the license header? Yes, in general all files need headers. The header can be omitted from certain files: http://www.apache.org/legal/src-headers.html#faq-exceptions Thanks, Shane On Feb 18, 2008 10:59 AM, sebb [EMAIL PROTECTED] wrote: On 18/02/2008, Shane Isbell [EMAIL PROTECTED] wrote: On the NMaven dev list, we have passed a vote for our first release. We request approval of the release by the IPMC. The 0.15-incubating version supports: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms Staging repo: http://people.apache.org/~sisbell/staging_repo/ The NOTICE files in the jars don't agree with NOTICE.txt in SVN, in that the Copyright says 2002-2008, whereas NOTICE.txt says just 2007. Did the project really start in 2002? Also, the NOTICE file is only supposed to include details of code that is included in the distribution - not any external dependencies. The proper heading is: This product includes software developed by 'etc' There is no need to itemise the individual projects within ASF. See http://www.apache.org/legal/src-headers.html#notice for details. The individual jars seem to have individual NOTICE file headings, e.g. in maven-archetype-windows-application-0.15-incubating-sources.jar the heading reads: maven-archetype-dotnet-windows-application Copyright 2002-2008 The Apache Software Foundation Surely the official name of the project is Apache NMaven ? Unless there is some non-ASF code included in the distribution, then the NOTICE.txt file currently at the root of SVN is all that is needed for the NOTICE in the jar files. == The Manifest.mf files in binary jars should ideally contain the Java compiler source and target versions. There's no need for the .asc.mdf and .asc.sha1 files - an .asc file is only needed to verify the file sig, and if the .asc file is mangled it won't agree with the file it is protecting. Vote Thread: http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html 4 +1 binding (PPMC), 1 +1 non-binding 0 0/-1 Tag: http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/ NOTICE.txt says: Copyright 2007 The Apache Software Foundation That should be Copyright 2007-2008 The Apache Software Foundation - assuming that the project started in 2007. There should ideally be a LICENSE file alongside the NOTICE file. Some of the source files are missing the standard ASF header. Thanks, Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release NMaven 0.15-incubating
Simple answer is yes. Here is what the Release Management Guide [1] says. All source capable of copyright should contain license header. Easiest way to comply is to ensure that every human readable file has the header. Note that source includes not just the source code compiled into the final product but also all other resources such as style sheets, test code and resources, build files and documentation source. When in doubt, add a header. [1] http://incubator.apache.org/guides/releasemanagement.html#notes-license-headers On Feb 18, 2008 2:12 PM, Shane Isbell [EMAIL PROTECTED] wrote: Hi Sebb, Thanks for checking over the staging release. The only missing license headers that I could find are in the unit test and integration test source files. Do test class files also need the license header? Thanks, Shane On Feb 18, 2008 10:59 AM, sebb [EMAIL PROTECTED] wrote: On 18/02/2008, Shane Isbell [EMAIL PROTECTED] wrote: On the NMaven dev list, we have passed a vote for our first release. We request approval of the release by the IPMC. The 0.15-incubating version supports: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms Staging repo: http://people.apache.org/~sisbell/staging_repo/ The NOTICE files in the jars don't agree with NOTICE.txt in SVN, in that the Copyright says 2002-2008, whereas NOTICE.txt says just 2007. Did the project really start in 2002? Also, the NOTICE file is only supposed to include details of code that is included in the distribution - not any external dependencies. The proper heading is: This product includes software developed by 'etc' There is no need to itemise the individual projects within ASF. See http://www.apache.org/legal/src-headers.html#notice for details. The individual jars seem to have individual NOTICE file headings, e.g. in maven-archetype-windows-application-0.15-incubating-sources.jar the heading reads: maven-archetype-dotnet-windows-application Copyright 2002-2008 The Apache Software Foundation Surely the official name of the project is Apache NMaven ? Unless there is some non-ASF code included in the distribution, then the NOTICE.txt file currently at the root of SVN is all that is needed for the NOTICE in the jar files. == The Manifest.mf files in binary jars should ideally contain the Java compiler source and target versions. There's no need for the .asc.mdf and .asc.sha1 files - an .asc file is only needed to verify the file sig, and if the .asc file is mangled it won't agree with the file it is protecting. Vote Thread: http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html 4 +1 binding (PPMC), 1 +1 non-binding 0 0/-1 Tag: http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/ NOTICE.txt says: Copyright 2007 The Apache Software Foundation That should be Copyright 2007-2008 The Apache Software Foundation - assuming that the project started in 2007. There should ideally be a LICENSE file alongside the NOTICE file. Some of the source files are missing the standard ASF header. Thanks, Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
Paul Fremantle wrote: Actually I'm wrong The correct wording (I think) is: ..establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the SCA and SDO standards defined by the OASIS OpenCSA member section. Same question applies. Yes, SDO is currently in the scope of Tuscany. As you have pointed out, the Tuscany PPMC has adjusted the wording of this sentence a few times, and it could be adjusted again before the next graduation proposal. For example, it could say something like SCA and associated technologies which would still allow Tuscany to do things related to the use of SDO in the context of SCA. I don't think there's any problem with the current arrangement of having Tuscany's scope include implementations of both SCA and SDO. Neither do I think there would be any problem with a slightly different scope in which Tuscany SCA provides databinding support for an SDO implementation (or implementations) that are developed in other open source projects. Tuscany SCA currently does this for JAXB, JSON, Saxon, XMLBeans, etc. The overriding consideration should be what's the best option for creating and sustaining a healthy and diverse SDO community. This proposal would increase the diversity of the Apache SDO community, and put new SDO technical assets into open source that aren't there today. These are good reasons in favour of accepting it. Conversely, it is important for Tuscany to ensure that its current SDO community isn't impacted by any change in Tuscany's scope, and this discussion is currently under way on the tuscany-user list (see [1]). One topic from the tuscany-user discussion that's worth exposing here is whether the NNY project would be a pure RI with no extensions beyond the spec, or a vehicle for innovation to extend the specs, as both Tuscany SCA and SDO have been. My view is that it will need to be at least some of the latter in order to build a sustainable community of developers and users. This will create some challenges given that one of the goals of the NNY project is to deliver the official JCP RI. Simon [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL PROTECTED] Paul On Thu, Feb 14, 2008 at 9:24 PM, Paul Fremantle [EMAIL PROTECTED] wrote: Cesar The Tuscany project is aiming to have the following charter: charged with the creation and maintenance of open-source software that simplifies the development and deployment of service oriented applications and provides a managed service-oriented runtime based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. Are you saying that SDO falls out of that scope? Paul On Thu, Feb 14, 2008 at 8:31 PM, Cezar Andrei [EMAIL PROTECTED] wrote: In my opinion SCA and SDO are two completely different technologies, even if they can be used together, they address different problems and as specifications they are developed separately. I think there are a lot of people looking only at SDO for their projects, and I'm sure there are others looking at SCA without SDO. I think having each community focus on their goals would help getting better organized, develop and independently graduate. Other than the technology/community point of view, the SDO code is not dependent on SCA code and as Ant Elder pointed out on Tuscany-user list (http://www.mail-archive.com/[EMAIL PROTECTED]/msg02505.html ) the new infrastructure would seem a better fit. Cezar -Original Message- From: Paul Fremantle [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:50 AM To: general@incubator.apache.org Subject: Re: [Proposal] NoNameYet : Link Error - please use this link Cezar I don't think anyone has suggested this code is a fork from Tuscany, but thank you for making this completely clear. Is there any reason you aren't willing to do this work under the existing scope of the Tuscany Incubator project? Paul Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Subversion vs other source control systems
On Feb 18, 2008 1:01 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: the last time i tried SVK, changes would be needed to SVK before it could work with a repository as big as apache FWIW, the partial svnsync changes that SVK would need are present in 1.5. I don't know if the SVK community has picked up on that yet, but SVN 1.5 clients/servers will support it. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CouchDB Mailing lists are now available
The CouchDB mailing lists are now available. You can subscribe by sending messages to: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ted On Feb 17, 2008, at 10:16 PM, Ted Leung wrote: Hi Jan, All new committers for CouchDB should read this: http:// incubator.apache.org/guides/committer.html and if you have not submitted a Contributor License agreement, you should do so as quickly as possible so that we can get your accounts created http://www.apache.org/dev/new-committers-guide.html#cla. I've just submitted a request for the appropriate mailing lists. You can track via: https://issues.apache.org/jira/browse/INFRA-1526 Cheers, Ted On Feb 16, 2008, at 11:04 AM, Jan Lehnardt wrote: Hi, I'm Jan Lehnardt, one of the contributers of the CouchDB project. On Feb 12, 2008, at 20:36, Sam Ruby wrote: On Feb 9, 2008 11:09 AM, Sam Ruby [EMAIL PROTECTED] wrote: [...] 72 hours, two dozen votes, all positive, many binding. This vote clearly passes. First: Thank you for accepting the incubation proposal! We would like to start making CouchDB a new home at the ASF. We understand that discussing the details of the move should happen on the to-be-created CouchDB mailing lists and would like to ask when we can start signing up? Cheers Jan -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
