On 5 May 2011 17:27, Tim Donohue <tdono...@duraspace.org> wrote:
> Robin can correct me if I'm wrong, but I feel Robin's questions were
> more related to *policy decisions* from the Committers group. For
> example, his first question could have been reworded as: "What should be
> our *policy* around who should have commit rights to various modules?".
>
Well, at the risk of putting words in Robin's mouth (apologies, and correct
me as well if I'm wrong), but I feel the question is a little more direct
about the implications of our development strategy with the async proposals.
If our 'official release' contains / bundles projects that are developed
outside of the main trunk - which it does / is proposed it would do
(-services, -stats, -discovery) - then those 'module' projects may have
directly committed contributions from people that aren't officially
recognised as committers.
Whilst we certainly encourage and include contributions from outside the
committer group, if the release contains code that has been committed by
someone that is not recognised as a committer, then there is probably at
least a transparency issue.
To be honest, I worry that jumping directly into technology
> implementation ideas (git/github, etc.) only muddles things a bit. I
> don't mean any offense with this suggestion, I'm just noting that I
> don't think we're even all on the "same page" yet -- which is where we
> need to be before we can make decisions on *how* we want to move forward.
>
I agree, but also note that we can't completely separate policy from the
technology we use. Whilst git and svn have the same restrictions as to who
can make changes to particular trees in the master copy, development and
contribution strategies differ distinctly between the two technologies.
With svn, if you haven't got commit rights, then you have to create a patch
that someone else may or may not be able to apply, which may become out of
date, etc.
For git, you would encourage that a developer creates a 'fork' with their
changes, and at some point have it pulled back to the master.
So, there is a lot less pressure to for a developer to have direct commit
rights to the master, in order for them to be productive. Not only is this a
benefit to encouraging more community contributions, but it can change the
policy as to when the [master] commit rights are granted.
But as you say, we can determine our needs for accountability and visibility
- both in the process as well as the code - without considering how we
deliver it.
G
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
