You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2009/08/19 10:21:49 UTC
ESME at GitHub (was: Turtles all the way down (or how I learned to
love math in computing)
Hi,
On Mon, Aug 17, 2009 at 6:12 PM, David
Pollak<fe...@gmail.com> wrote:
> ...What I've done so far is to create a project at GitHub (
> http://github.com/dpp/esme_g2/tree/master ) I find Git's branching much
> easier to allow for playing and exploring... which will be very important in
> the early days. I will add all the ESME committers to the GitHub project.
> Once the codebase stabilizes, we can move it into the Apache repo. (If the
> Apache powers that be have an issue with this, let's all talk through it
> now.)...
Here's some info about the use of github (or any external SCM for that
matter) in Apache projects.
Curt Arnold's message at http://markmail.org/message/pz4mjekrtcqzvncc
summarizes the potential issues.
http://git.apache.org/ supplies read-only Git mirrors of Apache
codebases, ESME can be added there if needed.
http://wiki.apache.org/general/GitAtApache suggest sa workflow that
combines git with our SVN.
-Bertrand
Re: ESME at GitHub (was: Turtles all the way down (or how I learned to love math in computing)
Posted by J Aaron Farr <fa...@apache.org>.
On Wed 19 Aug 2009 23:51, David Pollak <fe...@gmail.com> wrote:
>> On Mon, Aug 17, 2009 at 6:12 PM, David
>> Pollak<fe...@gmail.com> wrote:
>> > ...What I've done so far is to create a project at GitHub (
>> > http://github.com/dpp/esme_g2/tree/master ) I find Git's branching
>> > much easier to allow for playing and exploring... which will be
>> > very importan in the early days. I will add all the ESME
>> > committers to the GitHub project. Once the codebase stabilizes, we
>> > can move it into the Apache repo. (If the Apache powers that be
>> > have an issue with this, let's all talk through it now.)...
If the code is developed outside of the ASF infrastructure, then we
might need a code grant to move it back into the ASF subversion
repository. As great as git is, I don't recommend this approach. As
Bertrand pointed out, we have mirrors of the subversion repository that
all you to use git locally while still making sure it ends up back in
the official repo.
> My policy with Lift is that we do not accept patches, period. Only
> committers can write code that winds up in the repo. I am a lawyer by
> training and my wife is one of the most awesome IP lawyers in the
> world. Being anal about the provenance of code is my default setting.
> My expectation for ESME G2 on GitHub is that only folks with commit
> rights to the Apache ESME project would have commit rights to the
> GitHub repo. Period. No exceptions. No code from JIRA tickets go
> into the G2 codebase. Nothing. Nada.
Because you'd be running it on git or because you don't want to deal
with patches while doing the early experimental work?
Shutting out all non-committers is not a ideal way to encourage more
uptake of the project. Even if it is only temporary.
--
J. Aaron Farr
馮傑仁
www.cubiclemuses.com
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by Richard Hirsch <hi...@gmail.com>.
I've talked to Anne and we agree that we want to choose the path of
highest development efficiency that stays within the legal bounds of
Apache rules / regulations. We want the best of both worlds. If just
Apache committers for ESME work on the G2 branch, I'm hoping that
wouldn't be problem.
What we wouldn't want to see is further development efforts for ESME
being moved away from the Apache SVN. G2 is something different,
because it is changing ESME's core and once the foundation is there in
git I expect that the source moves back to the Apache SVN and we
continue.
Thoughts?
D.
On Wed, Aug 19, 2009 at 5:51 PM, David
Pollak<fe...@gmail.com> wrote:
> On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <bdelacretaz@apache.org
>> wrote:
>
>> Hi,
>>
>> On Mon, Aug 17, 2009 at 6:12 PM, David
>> Pollak<fe...@gmail.com> wrote:
>> > ...What I've done so far is to create a project at GitHub (
>> > http://github.com/dpp/esme_g2/tree/master ) I find Git's branching much
>> > easier to allow for playing and exploring... which will be very important
>> in
>> > the early days. I will add all the ESME committers to the GitHub
>> project.
>> > Once the codebase stabilizes, we can move it into the Apache repo. (If
>> the
>> > Apache powers that be have an issue with this, let's all talk through it
>> > now.)...
>>
>> Here's some info about the use of github (or any external SCM for that
>> matter) in Apache projects.
>>
>> Curt Arnold's message at http://markmail.org/message/pz4mjekrtcqzvncc
>> summarizes the potential issues.
>
>
> My policy with Lift is that we do not accept patches, period. Only
> committers can write code that winds up in the repo. I am a lawyer by
> training and my wife is one of the most awesome IP lawyers in the world.
> Being anal about the provenance of code is my default setting. My
> expectation for ESME G2 on GitHub is that only folks with commit rights to
> the Apache ESME project would have commit rights to the GitHub repo.
> Period. No exceptions. No code from JIRA tickets go into the G2 codebase.
> Nothing. Nada.
>
> I agree with the visibility concerns and don't have an easy way to address
> them.
>
> My expectation would be that the G2 repo would be rolled into the Apache SVN
> repo when the experimentation phase was over and the need to have 10 or 20
> simultaneous branches was over.
>
>
>>
>>
>> http://git.apache.org/ supplies read-only Git mirrors of Apache
>> codebases, ESME can be added there if needed.
>>
>> http://wiki.apache.org/general/GitAtApache suggest sa workflow that
>> combines git with our SVN.
>
>
> I am aware of these. I use git-svn for all my svn based projects. I also
> (oddly) don't want to start a flame-war, but there's a material difference
> between that SVN offers and what Git offers in open source development. The
> ability to branch for free and play on the branches changes the face of
> development. Lift went from a 1 or 2 branch project to one with 10+
> branches going at any one time... when things get "right" the branch is
> merged into master (trunk). It's led to an unbelievable amount of
> exploration and in my experience, a ton of collaborative creativity.
>
> At the end of the day, if Dick and Anne ask that we keep stuff in the Apache
> SVN repo, that's what I'll do and I'll figure out a way to explore within
> the confines of SVN.
>
> Thanks,
>
> David
>
>
>>
>>
>> -Bertrand
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Aug 21, 2009 at 12:11 PM, Richard Hirsch<hi...@gmail.com> wrote:
> ...What I don't quite understand is the problem - "git vs apache svn" or
> "github vs apache svn"?...
Where the problem lies from the ASF point of view (omitting community
issues such as "stuff happening outside of the ASF world" for a
while), is in having a defined link from each line of committed code
to its author.
The idea is that code should only be committed to svn by its original
author, or from a JIRA contribution where the author has explicitely
granted permission.
Depending on how git or github are used (or any source code control
system outside of the ASF for that matter), code might be pulled in
from unknown people, and later committed to our svn without the
committer being the author of said code, and without the explicit
permission granted when attaching a patch to JIRA.
That's the core problem, and AFAIK (though I'd love to be proven
wrong, as distributed SCM and branching-like-mad is very cool),
there's no cryptographically safe way with git to verify the identity
of the original committer.
Restricting git pulls to ESME committers, as David suggests, would be
better by making sure no code from non-ASF committers is included.
Still, the final svn commits might contain code written by other
committers than whoever's committing to SVN, which is also a bit
problematic.
>
> I also don't know why we can't use the git instructions described at
> http://wiki.apache.org/general/GitAtApache.
That would be perfectly fine from the ASF's point of view, but AFAIK
that doesn't provide the full flexibility of git such as fast and easy
branching and merging.
-Bertrand
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by David Pollak <fe...@gmail.com>.
On Fri, Aug 21, 2009 at 8:00 AM, David Pollak <feeder.of.the.bears@gmail.com
> wrote:
>
>
> On Fri, Aug 21, 2009 at 3:11 AM, Richard Hirsch <hi...@gmail.com>wrote:
>
>> Yes. This concerns ESME unot Lift.
>>
>> What I don't quite understand is the problem - "git vs apache svn" or
>> "github vs apache svn"?
>>
>> I also don't know why we can't use the git instructions described at
>> http://wiki.apache.org/general/GitAtApache.
>>
>> Maybe someone can enlighten me.
>
>
> Dick,
>
> I'll put this information together in a longer post that addresses the
> multiple issues raised by this thread...
>
As I've been composing a more complete answer that addresses the various
concerns address in this thread (Why is Git different from SVN? What are
the IP ramifications? What are the community ramifications? How can we work
to optimize collaboration on open source (or why is social messaging
different from email)?), I've come to the conclusion that (1) it's a bad
thing to try to propose new concepts/practices/process to the ASF and (2)
the ASF's IP policies do not afford the kind of protection that I need in a
core project that I would build a business off. I will be glad to share my
reasoning about these conclusions off-list... I don't want this to turn into
another flamewar.
I think the best course of action is to ignore my turtles proposal... I'll
focus efforts on the existing ESME code and we can take steps forward (as
opposed to a giant leap) based on what we have now.
Thanks and sorry for the digression.
David
> but...
>
> The document that you linked to discusses how to use Git as a front end to
> SVN. But, the limitations of SVN remain and there are none of the
> collaborative benefits of Git with this mechanism.
>
> So... what are the collaborative benefits of Git? Git allows for very fast
> branching (this is different than repository forking and pulling from other
> forks... I am not advocating that and do not pull from other repositories...
> but that's a digression.) What does fast branching give a development team?
>
> Fast branching (and amazingly simple and flexible merging) lets developers
> explore. A developer (or two) can create a branch to explore a new feature
> or a new implementation. The cost of branching is zero (it happens
> instantly). The cost of switching branches is very low (switching branches
> in Lift takes < 5 seconds). Keeping branches up to date with the place they
> were branched from is very simple (rebasing is just like doing an SVN
> update).
>
> Over the history of Lift, there have been more than 30 branches checked
> into origin (the GitHub shared repository). Personally, I've created a
> dozen local branches in my local repository to explore an idea. Sometimes I
> "cherry pick" my changes (only take a subset of the changes) back into
> master.
>
> The kind of exploration and resulting creativity that this mode of
> development was incomprehensible to me before I started using Git. But, as
> a matter of development, especially of new stuff, having 10, 20, more
> branches and switching between them as one switches between thoughts is like
> the difference between faxing and email. It's hard to describe the
> difference, but once you experience both, you wonder how people ever did it
> "the old way."
>
> We've had one branch in all of ESME. That is a shame.
>
> So, if we use SVN as our central repository, no matter the front end (Git,
> svn, TortoiseSVN, etc.) we're still limited by SVN's weak and costly
> branching/merging and tagging.
>
> Thanks,
>
> David
>
>
>>
>>
>> D.
>>
>> On Fri, Aug 21, 2009 at 10:54 AM, Bertrand
>> Delacretaz<bd...@apache.org> wrote:
>> > On Fri, Aug 21, 2009 at 10:15 AM, Gianugo
>> > Rabellino<g....@sourcesense.com> wrote:
>> >> On Wed, Aug 19, 2009 at 5:51 PM, David
>> >> Pollak<fe...@gmail.com> wrote:
>> >>> On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <
>> bdelacretaz@apache.org
>> >>>> wrote:
>> >>> My policy with Lift is that we do not accept patches, period. ...
>> >
>> >> Whoa. "My policy". "Period". "No exceptions"....
>> >
>> > As I read it, David says "my policy *with Lift* " - I understood this
>> > as a suggestion as to how ESME could use github.
>> >
>> > -Bertrand
>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by David Pollak <fe...@gmail.com>.
On Fri, Aug 21, 2009 at 3:11 AM, Richard Hirsch <hi...@gmail.com>wrote:
> Yes. This concerns ESME unot Lift.
>
> What I don't quite understand is the problem - "git vs apache svn" or
> "github vs apache svn"?
>
> I also don't know why we can't use the git instructions described at
> http://wiki.apache.org/general/GitAtApache.
>
> Maybe someone can enlighten me.
Dick,
I'll put this information together in a longer post that addresses the
multiple issues raised by this thread... but...
The document that you linked to discusses how to use Git as a front end to
SVN. But, the limitations of SVN remain and there are none of the
collaborative benefits of Git with this mechanism.
So... what are the collaborative benefits of Git? Git allows for very fast
branching (this is different than repository forking and pulling from other
forks... I am not advocating that and do not pull from other repositories...
but that's a digression.) What does fast branching give a development team?
Fast branching (and amazingly simple and flexible merging) lets developers
explore. A developer (or two) can create a branch to explore a new feature
or a new implementation. The cost of branching is zero (it happens
instantly). The cost of switching branches is very low (switching branches
in Lift takes < 5 seconds). Keeping branches up to date with the place they
were branched from is very simple (rebasing is just like doing an SVN
update).
Over the history of Lift, there have been more than 30 branches checked into
origin (the GitHub shared repository). Personally, I've created a dozen
local branches in my local repository to explore an idea. Sometimes I
"cherry pick" my changes (only take a subset of the changes) back into
master.
The kind of exploration and resulting creativity that this mode of
development was incomprehensible to me before I started using Git. But, as
a matter of development, especially of new stuff, having 10, 20, more
branches and switching between them as one switches between thoughts is like
the difference between faxing and email. It's hard to describe the
difference, but once you experience both, you wonder how people ever did it
"the old way."
We've had one branch in all of ESME. That is a shame.
So, if we use SVN as our central repository, no matter the front end (Git,
svn, TortoiseSVN, etc.) we're still limited by SVN's weak and costly
branching/merging and tagging.
Thanks,
David
>
>
> D.
>
> On Fri, Aug 21, 2009 at 10:54 AM, Bertrand
> Delacretaz<bd...@apache.org> wrote:
> > On Fri, Aug 21, 2009 at 10:15 AM, Gianugo
> > Rabellino<g....@sourcesense.com> wrote:
> >> On Wed, Aug 19, 2009 at 5:51 PM, David
> >> Pollak<fe...@gmail.com> wrote:
> >>> On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> >>>> wrote:
> >>> My policy with Lift is that we do not accept patches, period. ...
> >
> >> Whoa. "My policy". "Period". "No exceptions"....
> >
> > As I read it, David says "my policy *with Lift* " - I understood this
> > as a suggestion as to how ESME could use github.
> >
> > -Bertrand
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by Richard Hirsch <hi...@gmail.com>.
Yes. This concerns ESME unot Lift.
What I don't quite understand is the problem - "git vs apache svn" or
"github vs apache svn"?
I also don't know why we can't use the git instructions described at
http://wiki.apache.org/general/GitAtApache.
Maybe someone can enlighten me.
D.
On Fri, Aug 21, 2009 at 10:54 AM, Bertrand
Delacretaz<bd...@apache.org> wrote:
> On Fri, Aug 21, 2009 at 10:15 AM, Gianugo
> Rabellino<g....@sourcesense.com> wrote:
>> On Wed, Aug 19, 2009 at 5:51 PM, David
>> Pollak<fe...@gmail.com> wrote:
>>> On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <bdelacretaz@apache.org
>>>> wrote:
>>> My policy with Lift is that we do not accept patches, period. ...
>
>> Whoa. "My policy". "Period". "No exceptions"....
>
> As I read it, David says "my policy *with Lift* " - I understood this
> as a suggestion as to how ESME could use github.
>
> -Bertrand
>
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Aug 21, 2009 at 10:15 AM, Gianugo
Rabellino<g....@sourcesense.com> wrote:
> On Wed, Aug 19, 2009 at 5:51 PM, David
> Pollak<fe...@gmail.com> wrote:
>> On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <bdelacretaz@apache.org
>>> wrote:
>> My policy with Lift is that we do not accept patches, period. ...
> Whoa. "My policy". "Period". "No exceptions"....
As I read it, David says "my policy *with Lift* " - I understood this
as a suggestion as to how ESME could use github.
-Bertrand
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by Gianugo Rabellino <g....@sourcesense.com>.
On Wed, Aug 19, 2009 at 5:51 PM, David
Pollak<fe...@gmail.com> wrote:
> On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <bdelacretaz@apache.org
>> wrote:
> My policy with Lift is that we do not accept patches, period. Only
> committers can write code that winds up in the repo. I am a lawyer by
> training and my wife is one of the most awesome IP lawyers in the world.
> Being anal about the provenance of code is my default setting. My
> expectation for ESME G2 on GitHub is that only folks with commit rights to
> the Apache ESME project would have commit rights to the GitHub repo.
> Period. No exceptions. No code from JIRA tickets go into the G2 codebase.
> Nothing. Nada.
Whoa. "My policy". "Period". "No exceptions".
Are you sure all this fits with the way we work @ Apache? At a very
least, and never mind how much it could be argued whether branching a
candidate Apache codebase on GitHub is a good thing, you might want to
let the community have a say?
Ciao,
--
Gianugo Rabellino
M: +44 779 5364 932 / +39 389 44 26 846
Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: ESME at GitHub (was: Turtles all the way down (or how I learned
to love math in computing)
Posted by David Pollak <fe...@gmail.com>.
On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Mon, Aug 17, 2009 at 6:12 PM, David
> Pollak<fe...@gmail.com> wrote:
> > ...What I've done so far is to create a project at GitHub (
> > http://github.com/dpp/esme_g2/tree/master ) I find Git's branching much
> > easier to allow for playing and exploring... which will be very important
> in
> > the early days. I will add all the ESME committers to the GitHub
> project.
> > Once the codebase stabilizes, we can move it into the Apache repo. (If
> the
> > Apache powers that be have an issue with this, let's all talk through it
> > now.)...
>
> Here's some info about the use of github (or any external SCM for that
> matter) in Apache projects.
>
> Curt Arnold's message at http://markmail.org/message/pz4mjekrtcqzvncc
> summarizes the potential issues.
My policy with Lift is that we do not accept patches, period. Only
committers can write code that winds up in the repo. I am a lawyer by
training and my wife is one of the most awesome IP lawyers in the world.
Being anal about the provenance of code is my default setting. My
expectation for ESME G2 on GitHub is that only folks with commit rights to
the Apache ESME project would have commit rights to the GitHub repo.
Period. No exceptions. No code from JIRA tickets go into the G2 codebase.
Nothing. Nada.
I agree with the visibility concerns and don't have an easy way to address
them.
My expectation would be that the G2 repo would be rolled into the Apache SVN
repo when the experimentation phase was over and the need to have 10 or 20
simultaneous branches was over.
>
>
> http://git.apache.org/ supplies read-only Git mirrors of Apache
> codebases, ESME can be added there if needed.
>
> http://wiki.apache.org/general/GitAtApache suggest sa workflow that
> combines git with our SVN.
I am aware of these. I use git-svn for all my svn based projects. I also
(oddly) don't want to start a flame-war, but there's a material difference
between that SVN offers and what Git offers in open source development. The
ability to branch for free and play on the branches changes the face of
development. Lift went from a 1 or 2 branch project to one with 10+
branches going at any one time... when things get "right" the branch is
merged into master (trunk). It's led to an unbelievable amount of
exploration and in my experience, a ton of collaborative creativity.
At the end of the day, if Dick and Anne ask that we keep stuff in the Apache
SVN repo, that's what I'll do and I'll figure out a way to explore within
the confines of SVN.
Thanks,
David
>
>
> -Bertrand
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp