You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2014/09/09 15:10:41 UTC
[discuss] Vote to git it?
Should we vote to move Commons to git one component at a time (as Math just
has), or just vote to move them all at once and be done with it and the
inevitable?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [discuss] Vote to git it?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 09/09/2014 16:35, Gary Gregory a écrit :
> I started this thread to get a feel for it. Some folks have a lot of
> experience with git, some have none. Most of us here know Subversion 'by
> default'. Understanding that and the comfort of folks of do not know git
> and their willingness to get into a new VCS is what I am trying to
> understand. I do not want to call a [vote] with out talking first.
The last time we voted there were 4 people opposed. I tried to summarize
the objections (please correct if I'm wrong):
Mark Thomas: not needed, not fully thought out, trial with one component
Thomas Vandahl: doesn't see any advantage
Damjan Jovanovic: trial with one component first
Gilles Sadowski: doesn't solve any problem, not used to the tool
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Sep 9, 2014 at 9:17 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 09/09/2014 15:10, Gary Gregory a écrit :
> > Should we vote to move Commons to git one component at a time (as Math
> just
> > has), or just vote to move them all at once and be done with it and the
> > inevitable?
>
> I'm fine with both solutions. Do we have a consensus to migrate the
> components now?
>
I started this thread to get a feel for it. Some folks have a lot of
experience with git, some have none. Most of us here know Subversion 'by
default'. Understanding that and the comfort of folks of do not know git
and their willingness to get into a new VCS is what I am trying to
understand. I do not want to call a [vote] with out talking first.
Gary
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [discuss] Vote to git it?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 09/09/2014 15:10, Gary Gregory a écrit :
> Should we vote to move Commons to git one component at a time (as Math just
> has), or just vote to move them all at once and be done with it and the
> inevitable?
I'm fine with both solutions. Do we have a consensus to migrate the
components now?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Benedikt Ritter <br...@apache.org>.
I'm fine with git. I was thinking about starting a discussion about
migrating [lang] to git, anyway :-)
2014-09-09 15:10 GMT+02:00 Gary Gregory <ga...@gmail.com>:
> Should we vote to move Commons to git one component at a time (as Math just
> has), or just vote to move them all at once and be done with it and the
> inevitable?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [discuss] Vote to git it?
Posted by sebb <se...@gmail.com>.
On 9 September 2014 16:05, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 09/09/2014 16:49, sebb a écrit :
>
>> But AFAIK, there is not yet any Commons documentation on how to do
>> things in Git.
>> Nor what conventions we should use where there are different ways to do things.
>
> The development workflow is another topic, but I don't think we should
> change our habits. That is, development occurs on the master branch,
> branches are created when needed (experimental work, maintenance
> branches, etc).
I meant git-specific things like when to rebase etc.
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 09/09/2014 16:49, sebb a écrit :
> But AFAIK, there is not yet any Commons documentation on how to do
> things in Git.
> Nor what conventions we should use where there are different ways to do things.
The development workflow is another topic, but I don't think we should
change our habits. That is, development occurs on the master branch,
branches are created when needed (experimental work, maintenance
branches, etc).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Mark Fortner <ph...@gmail.com>.
Gary,
<snip>
One thing that is a PITA is when getting pull requests from GitHub. The GH
patches are not usable as it.
</snip>
Atlassian's Stash makes that easier to deal with. This video describes a
fork-based workflow using Stash, and shows you how code reviews work. It
also means that people can contribute to projects without having commit
access to the project. They just submit a pull request to the project.
http://youtu.be/JYC9yDJ0dZo
Cheers,
Mark
Re: [discuss] Vote to git it?
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Sep 9, 2014 at 11:27 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 09/09/2014 16:52, Paul Benedict a écrit :
> > Is there an itch to scratch (need) by moving to git as opposed to just
> > continue using svn?
>
> I guess the "itch" is simply an increasing preference for Git among the
> people involved here. I don't think the migration will fix any important
> problem.
>
One thing that is a PITA is when getting pull requests from GitHub. The GH
patches are not usable as it.
Gary
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [discuss] Vote to git it?
Posted by Schalk Cronjé <ys...@gmail.com>.
On 09/09/2014 18:40, Mark Fortner wrote:
> Schalk,
> The only problem I see with the way that you do code reviews on Github, is
> the fact that you can only review change sets. You can't simply go through
> an existing codebase and point out the problems. I suggested Stash and
> Crucible since they're both linked with JIRA, and I think Apache has free
> access to Atlassian's stack for its projects
>
> Cheers,
>
> Mark
>
Thanks Mark. That makes sense.
--
Schalk W. Cronjé
@ysb33r
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Mark Fortner <ph...@gmail.com>.
Schalk,
The only problem I see with the way that you do code reviews on Github, is
the fact that you can only review change sets. You can't simply go through
an existing codebase and point out the problems. I suggested Stash and
Crucible since they're both linked with JIRA, and I think Apache has free
access to Atlassian's stack for its projects
Cheers,
Mark
On Tue, Sep 9, 2014 at 10:15 AM, Schalk Cronj é <ys...@gmail.com> wrote:
> On 09/09/2014 16:57, Mark Fortner wrote:
>
>> If I had to pick one feature that makes git more useful than svn, it would
>> be the ease in creating feature branches. If you want to add a feature,
>> you simply create a local branch to implement the feature, implement it,
>> and commit it, and create a pull request. If you're using Atlassian's
>> Crucible or Stash, it's pretty easy to do a code review of the pull
>> request.
>>
> For me that is the killer feature of Git where it beats Subversion
> hands-down.
>
> Personally I also find that performing a code review of a pull request on
> Github easy enough.
>
> --
> Schalk W. Cronjé
> @ysb33r
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [discuss] Vote to git it?
Posted by Schalk Cronjé <ys...@gmail.com>.
On 09/09/2014 16:57, Mark Fortner wrote:
> If I had to pick one feature that makes git more useful than svn, it would
> be the ease in creating feature branches. If you want to add a feature,
> you simply create a local branch to implement the feature, implement it,
> and commit it, and create a pull request. If you're using Atlassian's
> Crucible or Stash, it's pretty easy to do a code review of the pull
> request.
For me that is the killer feature of Git where it beats Subversion
hands-down.
Personally I also find that performing a code review of a pull request
on Github easy enough.
--
Schalk W. Cronjé
@ysb33r
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 10 Sep 2014 11:55:52 +0200, Luc Maisonobe wrote:
> Hi Gilles,
>
> Le 10/09/2014 11:43, Gilles a écrit :
>> On Wed, 10 Sep 2014 07:49:13 +0300, Silviu Burcea wrote:
>>> This is the killer feature for Git, because many of us, the
>>> newcomers,
>>> like
>>> me, will want to experiment a little before submitting a patch.
>>> This
>>> way, I
>>> can create a local branch and I'm free to do whatever I want. The
>>> SVN
>>> branch is visible on the server, I don't want to publish my crappy
>>> code
>>> before I feel that the feature or the bugfix has high quality and
>>> is
>>> readable enough.
>>
>> This use case does not convince me at all: when working on a
>> feature,
>> you always do it locally (modifying code, preparing unit tests), and
>> SVN certainly does not force you to experiment publicly; it's rather
>> the project's policy that forbids you to commit crappy code. :-)
>>
>> [The advantages of "git" must be somewhere else.]
>
> The advantages are that while doing so you do use git and all its
> features (you do local commits, you do diffs between several things
> you
> try at home, you do branches, you do forward your changes between
> several clones you may have (typically a laptop and a desktop
> computer,
> or a computer at work and another at home). With SVN, you only have
> the
> workspace, you cannot do local commits. Either your modifications are
> on
> the single workspace you have, or you commit them to the central
> server.
> This means that if you want to test several different approaches with
> SVN, you end up doing copies of your workspace, which is a pity since
> you do have a version control system.
>
You do not have to convince me that "git" can do more than
"subversion".
I am convinced; I've always been.[1] But that's not the same as feeling
that a Commons project should absolutely use it.
The "crappy code" argument is not the same as those which you
presented.
I would not mix "efficiency" arguments with principles.
Best,
Gilles
[1] So, let's tackle the next release of Commons Math, with "git",
rather
than continue a hazy discussion for the non-initiated. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Hi Gilles,
Le 10/09/2014 11:43, Gilles a écrit :
> On Wed, 10 Sep 2014 07:49:13 +0300, Silviu Burcea wrote:
>> This is the killer feature for Git, because many of us, the newcomers,
>> like
>> me, will want to experiment a little before submitting a patch. This
>> way, I
>> can create a local branch and I'm free to do whatever I want. The SVN
>> branch is visible on the server, I don't want to publish my crappy code
>> before I feel that the feature or the bugfix has high quality and is
>> readable enough.
>
> This use case does not convince me at all: when working on a feature,
> you always do it locally (modifying code, preparing unit tests), and
> SVN certainly does not force you to experiment publicly; it's rather
> the project's policy that forbids you to commit crappy code. :-)
>
> [The advantages of "git" must be somewhere else.]
The advantages are that while doing so you do use git and all its
features (you do local commits, you do diffs between several things you
try at home, you do branches, you do forward your changes between
several clones you may have (typically a laptop and a desktop computer,
or a computer at work and another at home). With SVN, you only have the
workspace, you cannot do local commits. Either your modifications are on
the single workspace you have, or you commit them to the central server.
This means that if you want to test several different approaches with
SVN, you end up doing copies of your workspace, which is a pity since
you do have a version control system.
best regards,
Luc
>
> Regards,
> Gilles
>
>>
>> Regards,
>> Silviu
>>
>> On Tue, Sep 9, 2014 at 9:12 PM, Mark Fortner <ph...@gmail.com> wrote:
>>
>>> Paul,
>>> Git branching is faster, computationally cheaper, and requires less disk
>>> space than svn branching. This link provides more information:
>>> https://git.wiki.kernel.org/index.php/GitSvnComparison.
>>>
>>> In git, you have a remote repo, and a local repo. Typically, people
>>> create
>>> local branches for experiments or new features and then merge and create
>>> pull-requests whenever they have something that they want to share
>>> with the
>>> community. In svn, whenever you branch, you're branching on the server
>>> first. Usually, if you're new to a code base, you don't want to do
>>> that if
>>> you're just experimenting. Ideally, you want to encourage
>>> experimentation
>>> (and attract new developers), so "feature branches" make a lot of
>>> sense in
>>> that context.
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>>
>>> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Hi Niall,
Le 22/09/2014 14:25, Niall Pemberton a écrit :
> On Wed, Sep 10, 2014 at 10:59 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
>> Le 10/09/2014 11:43, Gilles a écrit :
>>
>>> This use case does not convince me at all: when working on a feature,
>>> you always do it locally (modifying code, preparing unit tests), and
>>> SVN certainly does not force you to experiment publicly; it's rather
>>> the project's policy that forbids you to commit crappy code. :-)
>>
>> The advantage here is that you can split you local work into smaller
>> commits before pushing them to the server. That makes the review easier
>> by clearly separating the various steps of the implementation. It's also
>> convenient to rollback some of the changes and correct them without
>> starting from scratch.
>>
>>
> Can you chose whether you retain the local commit history or not when
> pushing it to the server?
Yes.
If you simply push your work, all the individual commits will appear.
If you prefer to simplify the history and have a single commit resuming
all of your work, your can do this with git merge --squash. I never did
it, so there may be a few intermediate steps, but the end result is that
you can do it.
So both cases are possible, you have the choice.
best regards,
Luc
>
> Niall
>
>
>
>>
>>> [The advantages of "git" must be somewhere else.]
>>
>> Local commits should be one of them though, since it's on the SVN roadmap
>> :)
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3626
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Sep 10, 2014 at 10:59 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 10/09/2014 11:43, Gilles a écrit :
>
> > This use case does not convince me at all: when working on a feature,
> > you always do it locally (modifying code, preparing unit tests), and
> > SVN certainly does not force you to experiment publicly; it's rather
> > the project's policy that forbids you to commit crappy code. :-)
>
> The advantage here is that you can split you local work into smaller
> commits before pushing them to the server. That makes the review easier
> by clearly separating the various steps of the implementation. It's also
> convenient to rollback some of the changes and correct them without
> starting from scratch.
>
>
Can you chose whether you retain the local commit history or not when
pushing it to the server?
Niall
>
> > [The advantages of "git" must be somewhere else.]
>
> Local commits should be one of them though, since it's on the SVN roadmap
> :)
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3626
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [discuss] Vote to git it?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 10/09/2014 11:43, Gilles a écrit :
> This use case does not convince me at all: when working on a feature,
> you always do it locally (modifying code, preparing unit tests), and
> SVN certainly does not force you to experiment publicly; it's rather
> the project's policy that forbids you to commit crappy code. :-)
The advantage here is that you can split you local work into smaller
commits before pushing them to the server. That makes the review easier
by clearly separating the various steps of the implementation. It's also
convenient to rollback some of the changes and correct them without
starting from scratch.
> [The advantages of "git" must be somewhere else.]
Local commits should be one of them though, since it's on the SVN roadmap :)
http://subversion.tigris.org/issues/show_bug.cgi?id=3626
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by sebb <se...@gmail.com>.
On 10 September 2014 11:26, Gilles <gi...@harfang.homelinux.org> wrote:
> On Wed, 10 Sep 2014 12:00:12 +0200, Stefan Bodewig wrote:
>>
>> [on the original topic: I personally like git but would leave the
>> decision to move on to the components]
>>
>> On 2014-09-10, Gilles wrote:
>>
>>> [The advantages of "git" must be somewhere else.]
>>
>>
>> Not sure about "the advantage", but let me show you an example where a
>> DVCS (any DVCS) would have been really useful.
>>
>> Back in 2012 there was some minor security issue in Compress. Apache
>> policy says the fix for a security issue should be a single commit -
>> this is for the benefit of packagers who may want to backport the fix to
>> their older versions. The policy also says the fix should be developed
>> in private and only be committed when ready shortly before building the
>> release so potential attackers watching the commits don't get too much
>> of a head-start.
>>
>> I didn't know about the policy at that time (pure ignorance) and created
>> more than a dozen svn commits experimenting and exploring the fix as it
>> wasn't easy. All visible to the public.
>>
>> My point now is, even if I had known about the policy I would have
>> needed some sort of SCM to explore the problem without too much fear. I
>> personally rely on the safety net offered by an SCM and don't like to
>> develop bigger chunks of code without safepoint commits.
>>
>> With a DVCS like git I can do so in a private branch that I can share
>> with my peers without committing to the ASF git server (have them pull
>> from my private repository) - so we can agree on the patch in private.
>> Once the patch is ready I can rebase my branch and squash all commits to
>> a single one that I can then merge to master and push to the ASF server.
>>
>> I guess what I'm trying to say is a DVCS makes it easier to experiment
>> in a controlled manner and for security issues it offers big advantages.
>>
>
> That is quite convincing! Such a use case could be the basis for Apache
> to _force_ all projects to switch to "git"...
I disagree that this is convincing.
There are PMC-only SVN repos which can be used for collaborative
development of security fixes.
These are better than sharing a private repo, because commits are
automatically mailed to the PMC mailing list.
And not everyone has the ability to share their private Git repos.
In any case, a private Git repo can still be used for local
development, even if the offical repo is SVN.
> Thanks,
> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Dipanjan Laha <di...@gmail.com>.
+1 for moving to git, and using Atlassian's stash and crucible.
Git branching is very different than subversion, and any feature or issue
can have it's own branch and merged into master through a pull request. We
can also have rules on code reviews before a branch is merged onto master
or say rules like the branch must have a green build before it's merged
into master. Using Stash and crucible integrates the workflow quite
seamlessly and it integrates well with Jira. My 2 cents...
Dipanjan
On Wednesday, 10 September 2014, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Wed, 10 Sep 2014 12:00:12 +0200, Stefan Bodewig wrote:
>
>> [on the original topic: I personally like git but would leave the
>> decision to move on to the components]
>>
>> On 2014-09-10, Gilles wrote:
>>
>> [The advantages of "git" must be somewhere else.]
>>>
>>
>> Not sure about "the advantage", but let me show you an example where a
>> DVCS (any DVCS) would have been really useful.
>>
>> Back in 2012 there was some minor security issue in Compress. Apache
>> policy says the fix for a security issue should be a single commit -
>> this is for the benefit of packagers who may want to backport the fix to
>> their older versions. The policy also says the fix should be developed
>> in private and only be committed when ready shortly before building the
>> release so potential attackers watching the commits don't get too much
>> of a head-start.
>>
>> I didn't know about the policy at that time (pure ignorance) and created
>> more than a dozen svn commits experimenting and exploring the fix as it
>> wasn't easy. All visible to the public.
>>
>> My point now is, even if I had known about the policy I would have
>> needed some sort of SCM to explore the problem without too much fear. I
>> personally rely on the safety net offered by an SCM and don't like to
>> develop bigger chunks of code without safepoint commits.
>>
>> With a DVCS like git I can do so in a private branch that I can share
>> with my peers without committing to the ASF git server (have them pull
>> from my private repository) - so we can agree on the patch in private.
>> Once the patch is ready I can rebase my branch and squash all commits to
>> a single one that I can then merge to master and push to the ASF server.
>>
>> I guess what I'm trying to say is a DVCS makes it easier to experiment
>> in a controlled manner and for security issues it offers big advantages.
>>
>>
> That is quite convincing! Such a use case could be the basis for Apache
> to _force_ all projects to switch to "git"...
>
> Thanks,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [discuss] Vote to git it?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 10 Sep 2014 12:00:12 +0200, Stefan Bodewig wrote:
> [on the original topic: I personally like git but would leave the
> decision to move on to the components]
>
> On 2014-09-10, Gilles wrote:
>
>> [The advantages of "git" must be somewhere else.]
>
> Not sure about "the advantage", but let me show you an example where
> a
> DVCS (any DVCS) would have been really useful.
>
> Back in 2012 there was some minor security issue in Compress. Apache
> policy says the fix for a security issue should be a single commit -
> this is for the benefit of packagers who may want to backport the fix
> to
> their older versions. The policy also says the fix should be
> developed
> in private and only be committed when ready shortly before building
> the
> release so potential attackers watching the commits don't get too
> much
> of a head-start.
>
> I didn't know about the policy at that time (pure ignorance) and
> created
> more than a dozen svn commits experimenting and exploring the fix as
> it
> wasn't easy. All visible to the public.
>
> My point now is, even if I had known about the policy I would have
> needed some sort of SCM to explore the problem without too much fear.
> I
> personally rely on the safety net offered by an SCM and don't like to
> develop bigger chunks of code without safepoint commits.
>
> With a DVCS like git I can do so in a private branch that I can share
> with my peers without committing to the ASF git server (have them
> pull
> from my private repository) - so we can agree on the patch in
> private.
> Once the patch is ready I can rebase my branch and squash all commits
> to
> a single one that I can then merge to master and push to the ASF
> server.
>
> I guess what I'm trying to say is a DVCS makes it easier to
> experiment
> in a controlled manner and for security issues it offers big
> advantages.
>
That is quite convincing! Such a use case could be the basis for Apache
to _force_ all projects to switch to "git"...
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Stefan Bodewig <bo...@apache.org>.
[on the original topic: I personally like git but would leave the
decision to move on to the components]
On 2014-09-10, Gilles wrote:
> [The advantages of "git" must be somewhere else.]
Not sure about "the advantage", but let me show you an example where a
DVCS (any DVCS) would have been really useful.
Back in 2012 there was some minor security issue in Compress. Apache
policy says the fix for a security issue should be a single commit -
this is for the benefit of packagers who may want to backport the fix to
their older versions. The policy also says the fix should be developed
in private and only be committed when ready shortly before building the
release so potential attackers watching the commits don't get too much
of a head-start.
I didn't know about the policy at that time (pure ignorance) and created
more than a dozen svn commits experimenting and exploring the fix as it
wasn't easy. All visible to the public.
My point now is, even if I had known about the policy I would have
needed some sort of SCM to explore the problem without too much fear. I
personally rely on the safety net offered by an SCM and don't like to
develop bigger chunks of code without safepoint commits.
With a DVCS like git I can do so in a private branch that I can share
with my peers without committing to the ASF git server (have them pull
from my private repository) - so we can agree on the patch in private.
Once the patch is ready I can rebase my branch and squash all commits to
a single one that I can then merge to master and push to the ASF server.
I guess what I'm trying to say is a DVCS makes it easier to experiment
in a controlled manner and for security issues it offers big advantages.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 10 Sep 2014 07:49:13 +0300, Silviu Burcea wrote:
> This is the killer feature for Git, because many of us, the
> newcomers, like
> me, will want to experiment a little before submitting a patch. This
> way, I
> can create a local branch and I'm free to do whatever I want. The SVN
> branch is visible on the server, I don't want to publish my crappy
> code
> before I feel that the feature or the bugfix has high quality and is
> readable enough.
This use case does not convince me at all: when working on a feature,
you always do it locally (modifying code, preparing unit tests), and
SVN certainly does not force you to experiment publicly; it's rather
the project's policy that forbids you to commit crappy code. :-)
[The advantages of "git" must be somewhere else.]
Regards,
Gilles
>
> Regards,
> Silviu
>
> On Tue, Sep 9, 2014 at 9:12 PM, Mark Fortner <ph...@gmail.com>
> wrote:
>
>> Paul,
>> Git branching is faster, computationally cheaper, and requires less
>> disk
>> space than svn branching. This link provides more information:
>> https://git.wiki.kernel.org/index.php/GitSvnComparison.
>>
>> In git, you have a remote repo, and a local repo. Typically, people
>> create
>> local branches for experiments or new features and then merge and
>> create
>> pull-requests whenever they have something that they want to share
>> with the
>> community. In svn, whenever you branch, you're branching on the
>> server
>> first. Usually, if you're new to a code base, you don't want to do
>> that if
>> you're just experimenting. Ideally, you want to encourage
>> experimentation
>> (and attract new developers), so "feature branches" make a lot of
>> sense in
>> that context.
>>
>> Cheers,
>>
>> Mark
>>
>>
>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Silviu Burcea <si...@gmail.com>.
This is the killer feature for Git, because many of us, the newcomers, like
me, will want to experiment a little before submitting a patch. This way, I
can create a local branch and I'm free to do whatever I want. The SVN
branch is visible on the server, I don't want to publish my crappy code
before I feel that the feature or the bugfix has high quality and is
readable enough.
Regards,
Silviu
On Tue, Sep 9, 2014 at 9:12 PM, Mark Fortner <ph...@gmail.com> wrote:
> Paul,
> Git branching is faster, computationally cheaper, and requires less disk
> space than svn branching. This link provides more information:
> https://git.wiki.kernel.org/index.php/GitSvnComparison.
>
> In git, you have a remote repo, and a local repo. Typically, people create
> local branches for experiments or new features and then merge and create
> pull-requests whenever they have something that they want to share with the
> community. In svn, whenever you branch, you're branching on the server
> first. Usually, if you're new to a code base, you don't want to do that if
> you're just experimenting. Ideally, you want to encourage experimentation
> (and attract new developers), so "feature branches" make a lot of sense in
> that context.
>
> Cheers,
>
> Mark
>
>
>
> On Tue, Sep 9, 2014 at 10:46 AM, Paul Benedict <pb...@apache.org>
> wrote:
>
> > Mark, can you help me understand why git branches (the "feature" branch)
> is
> > better than an svn branch?
> >
> >
> > Cheers,
> > Paul
> >
> > On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner <ph...@gmail.com>
> wrote:
> >
> > > If I had to pick one feature that makes git more useful than svn, it
> > would
> > > be the ease in creating feature branches. If you want to add a
> feature,
> > > you simply create a local branch to implement the feature, implement
> it,
> > > and commit it, and create a pull request. If you're using Atlassian's
> > > Crucible or Stash, it's pretty easy to do a code review of the pull
> > > request.
> > >
> > > Feature branching makes it easy for developers to get their feet wet
> > with a
> > > code base. You can try out experiments. Have branches for each
> > experiment.
> > > It makes it easier to attract new developers to a project.
> > >
> > > From the previous discussion thread, it seems like the main objections
> > were
> > > (paraphrasing a bit here):
> > >
> > > - I'm not familiar with git. I've got a process that works for me
> and
> > I
> > > don't want to change it.
> > > - I don't see the value in it.
> > > - We don't know the impact on the release process.
> > >
> > >
> > > In order to address these concerns, it makes sense to try it out on a
> > > project. The next question is -- which project. The project needs to
> be
> > > central enough that everyone has some skin in the game. It should be a
> > > project that you have an interest in. If you haven't used git before,
> > then
> > > you need to try implementing a feature in that project. The project
> lead
> > > should also be someone who's familiar with git, and feels comfortable
> > with
> > > answering questions about git.
> > >
> > > I think if we can identify a project, and get commitment from everyone
> > who
> > > hasn't tried git, to add a small feature, add some comments, or add a
> > unit
> > > test, we'll learn enough. The project lead can look at the impact on
> the
> > > release process, and report any findings. At least at that point,
> we'll
> > > have learned enough from the process to make an informed decision.
> > >
> > >
> > > Regards,
> > >
> > > Mark
> > >
> > >
> > >
> > > On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <eb...@apache.org>
> > wrote:
> > >
> > > > Le 09/09/2014 16:52, Paul Benedict a écrit :
> > > > > Is there an itch to scratch (need) by moving to git as opposed to
> > just
> > > > > continue using svn?
> > > >
> > > > I guess the "itch" is simply an increasing preference for Git among
> the
> > > > people involved here. I don't think the migration will fix any
> > important
> > > > problem.
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> >
>
--
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast
Re: [discuss] Vote to git it?
Posted by Mark Fortner <ph...@gmail.com>.
Paul,
Git branching is faster, computationally cheaper, and requires less disk
space than svn branching. This link provides more information:
https://git.wiki.kernel.org/index.php/GitSvnComparison.
In git, you have a remote repo, and a local repo. Typically, people create
local branches for experiments or new features and then merge and create
pull-requests whenever they have something that they want to share with the
community. In svn, whenever you branch, you're branching on the server
first. Usually, if you're new to a code base, you don't want to do that if
you're just experimenting. Ideally, you want to encourage experimentation
(and attract new developers), so "feature branches" make a lot of sense in
that context.
Cheers,
Mark
On Tue, Sep 9, 2014 at 10:46 AM, Paul Benedict <pb...@apache.org> wrote:
> Mark, can you help me understand why git branches (the "feature" branch) is
> better than an svn branch?
>
>
> Cheers,
> Paul
>
> On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner <ph...@gmail.com> wrote:
>
> > If I had to pick one feature that makes git more useful than svn, it
> would
> > be the ease in creating feature branches. If you want to add a feature,
> > you simply create a local branch to implement the feature, implement it,
> > and commit it, and create a pull request. If you're using Atlassian's
> > Crucible or Stash, it's pretty easy to do a code review of the pull
> > request.
> >
> > Feature branching makes it easy for developers to get their feet wet
> with a
> > code base. You can try out experiments. Have branches for each
> experiment.
> > It makes it easier to attract new developers to a project.
> >
> > From the previous discussion thread, it seems like the main objections
> were
> > (paraphrasing a bit here):
> >
> > - I'm not familiar with git. I've got a process that works for me and
> I
> > don't want to change it.
> > - I don't see the value in it.
> > - We don't know the impact on the release process.
> >
> >
> > In order to address these concerns, it makes sense to try it out on a
> > project. The next question is -- which project. The project needs to be
> > central enough that everyone has some skin in the game. It should be a
> > project that you have an interest in. If you haven't used git before,
> then
> > you need to try implementing a feature in that project. The project lead
> > should also be someone who's familiar with git, and feels comfortable
> with
> > answering questions about git.
> >
> > I think if we can identify a project, and get commitment from everyone
> who
> > hasn't tried git, to add a small feature, add some comments, or add a
> unit
> > test, we'll learn enough. The project lead can look at the impact on the
> > release process, and report any findings. At least at that point, we'll
> > have learned enough from the process to make an informed decision.
> >
> >
> > Regards,
> >
> > Mark
> >
> >
> >
> > On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <eb...@apache.org>
> wrote:
> >
> > > Le 09/09/2014 16:52, Paul Benedict a écrit :
> > > > Is there an itch to scratch (need) by moving to git as opposed to
> just
> > > > continue using svn?
> > >
> > > I guess the "itch" is simply an increasing preference for Git among the
> > > people involved here. I don't think the migration will fix any
> important
> > > problem.
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
Re: [discuss] Vote to git it?
Posted by Paul Benedict <pb...@apache.org>.
Mark, can you help me understand why git branches (the "feature" branch) is
better than an svn branch?
Cheers,
Paul
On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner <ph...@gmail.com> wrote:
> If I had to pick one feature that makes git more useful than svn, it would
> be the ease in creating feature branches. If you want to add a feature,
> you simply create a local branch to implement the feature, implement it,
> and commit it, and create a pull request. If you're using Atlassian's
> Crucible or Stash, it's pretty easy to do a code review of the pull
> request.
>
> Feature branching makes it easy for developers to get their feet wet with a
> code base. You can try out experiments. Have branches for each experiment.
> It makes it easier to attract new developers to a project.
>
> From the previous discussion thread, it seems like the main objections were
> (paraphrasing a bit here):
>
> - I'm not familiar with git. I've got a process that works for me and I
> don't want to change it.
> - I don't see the value in it.
> - We don't know the impact on the release process.
>
>
> In order to address these concerns, it makes sense to try it out on a
> project. The next question is -- which project. The project needs to be
> central enough that everyone has some skin in the game. It should be a
> project that you have an interest in. If you haven't used git before, then
> you need to try implementing a feature in that project. The project lead
> should also be someone who's familiar with git, and feels comfortable with
> answering questions about git.
>
> I think if we can identify a project, and get commitment from everyone who
> hasn't tried git, to add a small feature, add some comments, or add a unit
> test, we'll learn enough. The project lead can look at the impact on the
> release process, and report any findings. At least at that point, we'll
> have learned enough from the process to make an informed decision.
>
>
> Regards,
>
> Mark
>
>
>
> On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> > Le 09/09/2014 16:52, Paul Benedict a écrit :
> > > Is there an itch to scratch (need) by moving to git as opposed to just
> > > continue using svn?
> >
> > I guess the "itch" is simply an increasing preference for Git among the
> > people involved here. I don't think the migration will fix any important
> > problem.
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [discuss] Vote to git it?
Posted by Mark Fortner <ph...@gmail.com>.
If I had to pick one feature that makes git more useful than svn, it would
be the ease in creating feature branches. If you want to add a feature,
you simply create a local branch to implement the feature, implement it,
and commit it, and create a pull request. If you're using Atlassian's
Crucible or Stash, it's pretty easy to do a code review of the pull
request.
Feature branching makes it easy for developers to get their feet wet with a
code base. You can try out experiments. Have branches for each experiment.
It makes it easier to attract new developers to a project.
>From the previous discussion thread, it seems like the main objections were
(paraphrasing a bit here):
- I'm not familiar with git. I've got a process that works for me and I
don't want to change it.
- I don't see the value in it.
- We don't know the impact on the release process.
In order to address these concerns, it makes sense to try it out on a
project. The next question is -- which project. The project needs to be
central enough that everyone has some skin in the game. It should be a
project that you have an interest in. If you haven't used git before, then
you need to try implementing a feature in that project. The project lead
should also be someone who's familiar with git, and feels comfortable with
answering questions about git.
I think if we can identify a project, and get commitment from everyone who
hasn't tried git, to add a small feature, add some comments, or add a unit
test, we'll learn enough. The project lead can look at the impact on the
release process, and report any findings. At least at that point, we'll
have learned enough from the process to make an informed decision.
Regards,
Mark
On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 09/09/2014 16:52, Paul Benedict a écrit :
> > Is there an itch to scratch (need) by moving to git as opposed to just
> > continue using svn?
>
> I guess the "itch" is simply an increasing preference for Git among the
> people involved here. I don't think the migration will fix any important
> problem.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [discuss] Vote to git it?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 09/09/2014 16:52, Paul Benedict a écrit :
> Is there an itch to scratch (need) by moving to git as opposed to just
> continue using svn?
I guess the "itch" is simply an increasing preference for Git among the
people involved here. I don't think the migration will fix any important
problem.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Paul Benedict <pb...@apache.org>.
Is there an itch to scratch (need) by moving to git as opposed to just
continue using svn?
Cheers,
Paul
On Tue, Sep 9, 2014 at 9:49 AM, sebb <se...@gmail.com> wrote:
> On 9 September 2014 15:32, Gary Gregory <ga...@gmail.com> wrote:
> > On Tue, Sep 9, 2014 at 9:17 AM, sebb <se...@gmail.com> wrote:
> >
> >> On 9 September 2014 14:10, Gary Gregory <ga...@gmail.com> wrote:
> >> > Should we vote to move Commons to git one component at a time (as Math
> >> just
> >> > has), or just vote to move them all at once and be done with it and
> the
> >> > inevitable?
> >>
> >> I think it is far too early to decide.
> >> Math has yet to start using git in earnest.
> >>
> >> Let's not try to run before we have even learnt to crawl.
> >>
> >
> > At Log4j 2, we've switched, and so far so good.
>
> But AFAIK, there is not yet any Commons documentation on how to do
> things in Git.
> Nor what conventions we should use where there are different ways to do
> things.
>
> > Gary
> >
> >
> >> > Gary
> >> >
> >> > --
> >> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> > Java Persistence with Hibernate, Second Edition
> >> > <http://www.manning.com/bauer3/>
> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> > Spring Batch in Action <http://www.manning.com/templier/>
> >> > Blog: http://garygregory.wordpress.com
> >> > Home: http://garygregory.com/
> >> > Tweet! http://twitter.com/GaryGregory
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [discuss] Vote to git it?
Posted by sebb <se...@gmail.com>.
On 9 September 2014 15:32, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Sep 9, 2014 at 9:17 AM, sebb <se...@gmail.com> wrote:
>
>> On 9 September 2014 14:10, Gary Gregory <ga...@gmail.com> wrote:
>> > Should we vote to move Commons to git one component at a time (as Math
>> just
>> > has), or just vote to move them all at once and be done with it and the
>> > inevitable?
>>
>> I think it is far too early to decide.
>> Math has yet to start using git in earnest.
>>
>> Let's not try to run before we have even learnt to crawl.
>>
>
> At Log4j 2, we've switched, and so far so good.
But AFAIK, there is not yet any Commons documentation on how to do
things in Git.
Nor what conventions we should use where there are different ways to do things.
> Gary
>
>
>> > Gary
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > Java Persistence with Hibernate, Second Edition
>> > <http://www.manning.com/bauer3/>
>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > Spring Batch in Action <http://www.manning.com/templier/>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Sep 9, 2014 at 9:17 AM, sebb <se...@gmail.com> wrote:
> On 9 September 2014 14:10, Gary Gregory <ga...@gmail.com> wrote:
> > Should we vote to move Commons to git one component at a time (as Math
> just
> > has), or just vote to move them all at once and be done with it and the
> > inevitable?
>
> I think it is far too early to decide.
> Math has yet to start using git in earnest.
>
> Let's not try to run before we have even learnt to crawl.
>
At Log4j 2, we've switched, and so far so good.
Gary
> > Gary
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [discuss] Vote to git it?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 09/09/2014 21:02, Oliver Heger a écrit :
>
>
> On 09.09.2014 19:56, Luc Maisonobe wrote:
>> Le 09/09/2014 15:17, sebb a écrit :
>>> On 9 September 2014 14:10, Gary Gregory <ga...@gmail.com> wrote:
>>>> Should we vote to move Commons to git one component at a time (as
>>>> Math just
>>>> has), or just vote to move them all at once and be done with it and the
>>>> inevitable?
>>>
>>> I think it is far too early to decide.
>>> Math has yet to start using git in earnest.
>>
>> I agree with this.
>>
>> I think I am fairly at ease with git by now (having used it for about 3
>> years I think), but I also remember there are a lot of things to learn.
>> So the [math] experiment is worth doing and we can try to iron a few
>> things for the other components. One specific task will probably be
>> challenging: doing a release. There are some magics with subversion done
>> by maven in our components and we need the same kind of magic with git.
>> Once we have done that and documented what we have done, it will
>> probably be time to discuss about other components switching or not.
>
> +1
>
> Our decision was to use [math] as a test balloon, so let's be consequent
> and wait for first results.
>
> I also understand that Gary wants to push things forward. So maybe we
> can agree on a kind of time frame? Is there a release pending for
> [math]? Or can you estimate how long you need to come to a decision?
Well, we can always decide to release, we don't release often enough.
I think we need at least one month after git switch, but it will mainly
depend on what will happen in between.
Anyway, it you think we are too slow to release, just tell us to hurry!
By the way, the switch has not been done yet as INFRA seems busy. The
ticket is open.
Luc
>
> Oliver
>
>>
>> best regards,
>> Luc
>>
>>>
>>> Let's not try to run before we have even learnt to crawl.
>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Oliver Heger <ol...@oliver-heger.de>.
On 09.09.2014 19:56, Luc Maisonobe wrote:
> Le 09/09/2014 15:17, sebb a écrit :
>> On 9 September 2014 14:10, Gary Gregory <ga...@gmail.com> wrote:
>>> Should we vote to move Commons to git one component at a time (as Math just
>>> has), or just vote to move them all at once and be done with it and the
>>> inevitable?
>>
>> I think it is far too early to decide.
>> Math has yet to start using git in earnest.
>
> I agree with this.
>
> I think I am fairly at ease with git by now (having used it for about 3
> years I think), but I also remember there are a lot of things to learn.
> So the [math] experiment is worth doing and we can try to iron a few
> things for the other components. One specific task will probably be
> challenging: doing a release. There are some magics with subversion done
> by maven in our components and we need the same kind of magic with git.
> Once we have done that and documented what we have done, it will
> probably be time to discuss about other components switching or not.
+1
Our decision was to use [math] as a test balloon, so let's be consequent
and wait for first results.
I also understand that Gary wants to push things forward. So maybe we
can agree on a kind of time frame? Is there a release pending for
[math]? Or can you estimate how long you need to come to a decision?
Oliver
>
> best regards,
> Luc
>
>>
>> Let's not try to run before we have even learnt to crawl.
>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 09/09/2014 15:17, sebb a écrit :
> On 9 September 2014 14:10, Gary Gregory <ga...@gmail.com> wrote:
>> Should we vote to move Commons to git one component at a time (as Math just
>> has), or just vote to move them all at once and be done with it and the
>> inevitable?
>
> I think it is far too early to decide.
> Math has yet to start using git in earnest.
I agree with this.
I think I am fairly at ease with git by now (having used it for about 3
years I think), but I also remember there are a lot of things to learn.
So the [math] experiment is worth doing and we can try to iron a few
things for the other components. One specific task will probably be
challenging: doing a release. There are some magics with subversion done
by maven in our components and we need the same kind of magic with git.
Once we have done that and documented what we have done, it will
probably be time to discuss about other components switching or not.
best regards,
Luc
>
> Let's not try to run before we have even learnt to crawl.
>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss] Vote to git it?
Posted by sebb <se...@gmail.com>.
On 9 September 2014 14:10, Gary Gregory <ga...@gmail.com> wrote:
> Should we vote to move Commons to git one component at a time (as Math just
> has), or just vote to move them all at once and be done with it and the
> inevitable?
I think it is far too early to decide.
Math has yet to start using git in earnest.
Let's not try to run before we have even learnt to crawl.
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org