Guys, don't want to spread to much confusion now.... but just heard of this in another mail:
[1] - http://mail-archives.apache.org/mod_mbox/couchdb-dev/201109.mbox/%[email protected]%3E [2] - https://twitter.com/#!/davisp/status/117446331714383872 Seems like GIT is allowed - but have no proof for it Mercurial is not GIT - but very GITish. Maybe this is an option for you? If yes, you should ask at infra if that works or not. Cheers Christian On Mon, Sep 19, 2011 at 4:20 PM, Michael MacFadden <[email protected]> wrote: > Yuri, > > I wanted to coordinate with you on this. Is there a date/time that works > well for you. I have a least one code review I owe you. Would you prefer to > get the couple outstanding code reviews completed so you can get that code > checked in before the move. > > Basically, we need to establish a mini code freeze. > > ~Michael > > On Sep 18, 2011, at 11:43 PM, Yuri Z wrote: > >> We postponed the move until 28-th Sep as by Michael's request. The Wiki for >> PMC was updated accordingly on 13-th Sep. >> BTW, @Michael, when are you planning to complete the move? >> >> On Mon, Sep 19, 2011 at 8:25 AM, Doug <[email protected]> wrote: >> arc:~ douglasl$ svn ls https://svn.apache.org/repos/asf/incubator/wave/ >> branches/ >> site/ >> tags/ >> trunk/ >> arc:~ douglasl$ svn ls https://svn.apache.org/repos/asf/incubator/wave/trunk >> arc:~ douglasl$ >> >> ...? >> >> ~ >> Doug. >> >> On Tue, Sep 13, 2011 at 11:22 PM, Christian Grobmeier >> <[email protected]>wrote: >> >> > +1 good to see some progress here! >> > I am really looking forward to a first release :-) >> > >> > On Tue, Sep 13, 2011 at 4:13 PM, Michael MacFadden >> > <[email protected]> wrote: >> > > I think we have reached a consensus on the clean check in approach. We >> > should be able to mention that we have decided on the approach in the >> > report. Should we also set a target date for doing the migration? I am >> > more than happy to do the migration. I think we should give ourselves 2 >> > weeks to actually move the code over, just to be safe. This way we can >> > discuss any organization or structural issues that may come up. >> > > >> > > If we have a method and a date, then I think we have a good plan to put >> > in the board report. >> > > >> > > ~Michael >> > > >> > > >> > > On Sep 12, 2011, at 2:58 PM, Upayavira wrote: >> > > >> > >> >> > >> >> > >> On Monday, September 12, 2011 1:12 PM, "Jasper Horn" >> > >> <[email protected]> wrote: >> > >>> Upayavira wrote: >> > >>>> Right, the source code is the project's most valuable possession. The >> > >>>> ASF as a charitable organisation exists to produce software, therefore >> > >>>> it must be in control of its main asset, the asset it exists to >> > create! >> > >>> >> > >>> Talk about "control", "possessions" and "assets" doesn't sound much >> > >>> like Open Source to me... >> > >> >> > >> All software is owned (with the exception of public domain). Open source >> > >> software makes strong use of copyright law, which is all about >> > >> 'ownership'. Open source isn't about ownership, it is about licensing. >> > >> Apache 'owns' the code (actually, owns the copyright on the collection, >> > >> that is made up of individual parts which are owned by the respective >> > >> authors), but then, in keeping with its non-profit mission, it makes >> > >> that code available with a very liberal license to anyone who wants to >> > >> use it. >> > >> >> > >> As a part of that, people have come to trust Apache software, and that >> > >> needs some protecting - making sure that we keep to an approach that is >> > >> worthy of that trust. So yes, Apache does protect its code. Apache does >> > >> protect its trademarks. It is all Apache exists for. It protects its >> > >> code and the methods used to create it so that it *can* make it >> > >> available to the public, for no charge. >> > >> >> > >>>> There's scope to host code on git on Apache infrastructure, but that >> > >>>> requires volunteers to assist with a deployment. >> > >>> >> > >>> What would need to be done? >> > >> >> > >> You can join the [email protected] mailing list and ask there. I'm >> > >> not so sure about all the details. But bear in mind that the kind of >> > >> install that Apache needs is more substantial than most. It needs a >> > >> workflow that effectively tracks code's origins (SVN does this well, >> > >> with git, as I understand it, there are ways to work around this). But, >> > >> to be honest, I'm not sure what the current road blocks are other than >> > >> volunteer time. >> > >> >> > >> Upayavira >> > > >> > > >> > >> > >> > >> > -- >> > http://www.grobmeier.de >> > >> > > -- http://www.grobmeier.de
