incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Coleman <>
Subject Re: Plans for migrating to SVN?
Date Thu, 17 Nov 2011 03:13:34 GMT
Switching to subversion would be disruptive.  It is not just a matter
of running a script to convert a repo from git to subversion.
Switching to subversion fundamentally changes the workflow.
Git works very well.  The ability to fork, edit, and contribute
patches painlessly is important.  Git makes it easy to review and try
other people's code.  The best stuff can be merged.  Changes that
aren't accepted can live on outside the system.  Having many forks is
a strength of git.
Hopefully we can find a way to make git work in the ASF system for PhoneGap.
On Wed, Nov 16, 2011 at 9:29 PM, Laurent Hasson <> wrote:
> My $.02: there is a lot of religion, no doubt, but having worked with both SVN and Git,
it is clear to me that Git is much more nimble. I can't give concrete examples why, but that's
what I have observed in the past year since I have been exposed to it (after many years of
> As such (religion plus real/perceived nimbleness), switching to SVN will likely turn
off a number of participants in the current community and slow everything down.
> One thing highlighted below is a security concern but I am not sure I understand. No
matter where things come from, at the end of the day, it all ends up as a pull request which
has to be approved before getting into the main repo. 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 confusion/questions on this
> ___________________________________________
> LDH (Laurent Hasson)
> Technical Director, BlackBerry Web Platform
> Research In Motion
> Email:
> 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 []
> Sent: Wednesday, November 16, 2011 07:35 PM
> To: <>
> 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 <> 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
>> <> wrote:
>>> On Tue, Nov 15, 2011 at 4:15 PM, Jukka Zitting <>
>>>> 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
>>> --
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged
material (including material protected by the solicitor-client 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
immediately reply to the sender and delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended recipients is not authorized
and may be unlawful.

View raw message