Those who wanted to move to Git have given up several days ago, leaving
this thread to be 'argued' by
those who successfully squashed the action. James has already canceled
the test project request in INFRA, and
so it seems pointless for this thread to continue. You won, go off and
have a beer, and enjoy.
On 10/16/2013 11:56 PM, Henri Yandell wrote:
There's no veto notion here - if we're abiding by the lowest denominator of
the base Apache voting rules, vetoes are only for code votes. While this is
to do with code, it's not code itself.
I see it settled in that an understanding is reached.
The majority of those voting have indicated that they have a preference for
git over svn and would like Commons to move in that direction.
I'm definitely confused by the proposal. Being selfish - what's this going
to change? The discussion implied code review would be used (are we moving
to RTC?). It implied that there would be issues in checking all of Commons
out (which has always been very important to me, though I'll admit not
right now as I've not been supporting cross-Commons features the way
others, noticeably Sebb, are). If we break the ability for someone to fix
issues across all components, we increase the likelihood that central
changes won't be pushed out. Will GitHub pull requests get better? Because
they're currently a mess. Will we lose existing contributors due to putting
a hurdle in their way? Will the development workflow change? While I use
git at the moment, I'm aware I use it in an svn way because I'm always
hitting pains where git's support for my workflow involves doing odd items
(acknowledging the issue is me for not developing in a git way). If we move
a component to git, will I still be able to commit to it via some form of
svn2git bridge, or will each partial migration mean a component vanishing
from trunks-proper?
Browsing the git discuss thread, it was surprisingly light on details. To
be excited by this and not feel frustrated, I suspect I'll need more
support (explanations before hand, answers to dumb questions). However this
seems much like the moves to maven1 and maven2. A difference to the
maven1/maven2 moves is that they were done with overlap. Components were
not unusual to have Ant, Maven 1 and Maven 2 build systems.
Summary: I won't add my vote because I don't understand the question. We're
not voting on moving to Git, we're voting on something bigger and only
those voting +1 know what that is :) I'm not against it, but I know there
will be pain, someone else is going to do all the work [hey, I served my
time on jira and svn] and I'll slowly catch up and hopefully not get lost
along the way :)
---
An aside: I'm not convinced btw that another thread entitled "[VOTE] Stay
on Subversion" wouldn't also be passed. To conjecture culturally, those
fastest to respond are most likely to want to move to Git, while those
slower are most likely to want to stay on Subversion. Mobilization of the
SVN vote would probably exceed the Git vote, however I believe there is a
level of those interacting more often with the scm having a greater voice
in the choice of system being interacted with.
Hen
On Wednesday, October 16, 2013, James Ring wrote:
So did any committer want to exercise a veto? Otherwise the matter is
settled right?
On Oct 16, 2013 6:38 PM, "sebb" <seb...@gmail.com> wrote:
On 17 October 2013 02:10, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
On Oct 16, 2013, at 2:46 PM, James Ring wrote:
Do Apache by-laws require a quorum? Was there a quorum for this vote?
Apache voting rules are documented at
http://www.apache.org/foundation/voting.html. However, that page doesn't
define "consensus" which is where some of the disagreement came from.
It's defined in the glossary:
http://www.apache.org/foundation/glossary.html#ConsensusApproval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
