On Jan 28, 2009, at 12:47 AM, Jason Dillon wrote:
On Jan 28, 2009, at 1:47 AM, Kevan Miller wrote:
There are some usages of GIT that would not fit well into an
Apache project. For instance, I would not want to see project
members using GIT as a private means of sharing code updates.
Ultimately, code needs to get into our svn repo -- that's where
we should be sharing code.
Why do you have a problem with users sharing code via their own
GIT repos? I guess I can kinda see your concern, but I'd expect
folks with significant changes to the codebase to want to share
their GIT repos with others *before* pushing those changes back
into SVN.
Right. So, I wouldn't want a few people to decide to implement some
new function, start sharing code (privately amongst themselves),
and then dump it into svn. IIUC, GIT makes this pretty easy to do.
Currently, this sort of activity would happen in an svn sandbox or
via patches posted to a Jira. In either case the collaboration and
work should be public. I want to make sure we maintain this.
Jay's example of a security-related patch is a very compelling
example as to why sharing code directly via GIT instead of SVN can
be a good idea at times.
Sure. I'm not denying that GIT has potential advantages. I'll point
out that we can share security patches, already. Certainly not as
easily as GIT *could*, but it's not that hard, either... Also, the
code sharing occurs publicly within the security community. So, all
members of the security team can participate. We'd also require some
kind of access control on any GIT-based code sharing that occurs.
Until *everyone* is using GIT and we have community policies
governing its usage, svn and our mailing lists are where we need to
be collaborating.
Why does *everyone* need to use GIT? IMO it is just a tool, some
folks might prefer BZR, HG or SVK, making use of the features/
advantages that each tool provides. I don't see why there would
ever need to be a point where *everyone* is on the same tool since
ATM the underlying authoritative and definitive location for the
codebase is the ASF SVN.
Let me explain what I meant by that... Until we have community policy
that governs our usage of GIT, I think GIT should not be used to share
code between members of our community. Until then, use it as a tool to
improve your local development -- just like you might use SVK (I'm not
familiar with BZR or HG). If GIT improves your productivity, that's
fantastic.
However, if you and Joe start sharing GIT to privately share code
(merging between your two GIT repos), then I'd be concerned. Just like
I'd be concerned if you and Joe were privately sharing code patches.
Does that make sense?
If you and Joe are sharing code in an SVN sandbox, via patches in
JIRA, or via patches in community mailing list emails, then everyone
in the community can participate. That sort of openness needs to be
maintained with any usage of GIT within the community.
* * *
I really don't see what the harm is that you seem worried about.
I'm not sure that we need any "policies governing its usage" either,
no more than we need guidelines on how some one uses /bin/vi or
notepad.exe, unless you mean the content not the tool, and in that
case I think the general docs we have on that is sufficient.
IMO GIT allows for a much more flexible development model, and I
really don't see why we'd want to take away that flexibly with tape
(of the red kind).
Maintaining open communication is my only concern. That's the only
"red tape" that I'm putting on the process. I'm not saying this can't
be fixed. Just that we'd have to work out the issues...
As always, I'd like to hear from others in the community...
It might be useful if you could let others know how you're using GIT.
--kevan
