Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Laurent Hasson <lhasson@rim.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Subject: Re: Plans for migrating to SVN?
Thread-Topic: Plans for migrating to SVN?
Thread-Index: 
 AQHMo5zVF0UWMJsC30ao37/CmgXxKJWuXAOAgAAFroCAAA5lAIAAAPmAgAAmtgCAAhf4AP//qnlf
Date: Thu, 17 Nov 2011 02:29:24 +0000
Message-ID: <C1F58DEFE8474E49817F13AFE9C798DF0277F7@XMB104ADS.rim.net>
In-Reply-To: 
 <CAKQbXgBCy0NcvevQ9YKnGdct12vnCqKQ4+cqDg+_QT+OZxn_Tw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0

My $.02: there is a lot of religion, no doubt, but having worked with both S=
VN and Git, it is clear to me that Git is much more nimble. I can't give con=
crete examples why, but that's what I have observed in the past year since I=
 have been exposed to it (after many years of SVN).

As such (religion plus real/perceived nimbleness), switching to SVN will lik=
ely turn off a number of participants in the current community and slow ever=
ything down.

One thing highlighted below is a security concern but I am not sure I unders=
tand. No matter where things come from, at the end of the day, it all ends u=
p as a pull request which has to be approved before getting into the main re=
po. I am missing how this is different from current practices.

I believe many in the PhoneGap community are/were under the impression that=
 Git would remain the project's repo even as we move to Apache, thus the con=
fusion/questions on this thread.


___________________________________________
LDH (Laurent Hasson)
Technical Director, BlackBerry Web Platform
Research In Motion
Email: lhasson@rim.com
Mobile: 646-460-7066
-----------------------------------------------------------------
"That's who you remind me of: an evil Mr. Rogers!" - Simon Phoenix
-----------------------------------------------------------------
Sent from my BlackBerry Torch!

----- Original Message -----
From: Ross Gardler [mailto:rgardler@opendirective.com]
Sent: Wednesday, November 16, 2011 07:35 PM=0A=
To: callback-dev@incubator.apache.org <callback-dev@incubator.apache.org>
Subject: Re: Plans for migrating to SVN?

I wrote the response below some days ago in the hope that other
mentors would leap to the projects defence. However, that has not been
the case, so here goes, maybe this will provoke a reaction...

On 15 November 2011 17:37, Brian LeRoux <b@brian.io> wrote:
> Hey guys, from the Nitobi (now Adobe) side of things we have to
> apologize for our ignorance of the current reasoning at ASF with
> respect to revision control.

No need to apologise. It is your champion and then your mentors job to
ensure that things are clear.

> Git revision control
> is remarkably well suited to a project like PhoneGap, with many
> differing codebases, and an extremely distributed community across
> continents and companies.

I think you'll find quite a few projects with "extremely distributed
community across continents and companies" here at the ASF. So the
latter argument is not relevant. What makes Callback different from
all these other projects? How does Callback currently operate that is
not possible under SVN with a Git mirror?

Apache projects, incubating or otherwise, have very few limitations on
the way they operate. Hosting on SVN is one of them.

> Technical benefits aside, security and ASF compliance are paramount of
> importance to not only Adobe but IBM, Microsoft and RIM. It is in our
> collective benefit to see the PhoneGap project to continue to succeed
> under the stewardship of the ASF. Everything we can do to address
> concerns we will do and we are very certain the solution is not bulk
> importing our code into SVN.

The ASF does not, and will not, allow software bearing its trademarks
to be hosted on any servers other than those under its direct control.
This is, in no small part, to ensure the integrity of the software we
release. This is not negotiable for Top Level Projects and, as far as
I am aware not negotiable for Incubating projects too. There may be
scope for a delay in migration, but not an indefinite one.

> Moving into ASF infrastructure is
> something we want to dedicate resources to so this shouldn't be an
> issue. Security with concern to IP should not be any more of an
> exception under Git than it is under SVN to the best of my technical
> understanding but this sounds more like something of a process
> concern.

It is not a process concern.

With SVN there is a single point of authentication. That point is
under the direct control of the ASF infrastructure team. WIth GitHub
there is at least one, and possibly many, points of authentication.
None of them under the ASFs control. Even when Git is hosted
read/write here at the ASF there are potentially authentication points
that are no in our control.

> Lets look to setting an example that looks forward.

I'm afraid this is the wrong way around. It is the ASF that sets the
example. That is why people are willing to trust the Apache Brand.

> Know too we really
> appreciate the guidance here.

The ASF is actively working on solving the technical issues relating
to Git. Once they are resolved there are community issues to be
addressed. Personally I am not concerned about the community issues,
they are a matter of process (but many in the ASF are concerned about
this).

It is quite likely that Callbacks experience with Git will help us
resolve these policy issues in the future, however, we can't start
solving the community issues until the technical concerns are
resolved. Therefore, ASF guidance is to use the infrastructure
provided by the ASF.

> Ross/Jukka/Christian how should we best
> proceed to make sure this is resolved in the ASF process? (But
> quickly! We want to get back to business cutting code and not be
> stumbling around on things like rcs!!!)

Until VP Infrastructure informs the board that we are able to safely
host Git (and the board accepts this assuramce) I'm afraid the only
possible way forward for you is to take your proposal to the IPMC. If
you are not satisfied with the outcome then you can escalate to the
board if you so desire.

However, I am not personally willing to spend my time on this. I do
not believe the IPMC will approve. If they do I doubt infra will
approve. If they do I doubt the board will. However, this is the ASF,
anyone, mentor or otherwise, is free to take this proposal to the IPMC
in an attempt to prove me wrong.

Ross

>
>
> On Tue, Nov 15, 2011 at 4:18 PM, Christian Grobmeier
> <grobmeier@gmail.com> wrote:
>> On Tue, Nov 15, 2011 at 4:15 PM, Jukka Zitting <jukka.zitting@gmail.com>=
 wrote:
>>> IMHO it's better to wait and see for now and revise the plan as the
>>> outcome of the CouchDB experiment becomes clearer. There's no need to
>>> rush things. For example Apache Wave worked with their original Git
>>> repositories for over a year after entering the Incubator, so it's not
>>> like this is a unique situation.
>>
>> Until I asked them to do something about that.
>>
>> There was discussion already about longtime podlings and I feel that
>> there is some movement between ipmc people to clean up.
>>
>> Honestly I think that Wave has lost lots steam with not bringing their
>> source code into the ASF servers directly.
>>
>> Cheers,
>> Christian
>>
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>>
>


-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.