On May 5, 2011, at 1:14 PM, Graham Triggs wrote:
> 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.
Maybe in the case that module is maintained "externally" of the DSpace Project
SVN Repository... but otherwise, its all there in the commit log. I don't
promote depending on non-open source packages from other communities at all as
part of the distribution. To take it even further... those dependencies need
to be all published in the Maven Central Repo... examples of exceptions should
always be treated as optionals, for instance, the oracle rdbms driver...
> 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.
But my concern about mediating that "din" still applies when all those changes
are pushed to the master for a release... I only want to monitor those areas
that are mission critical to our needs.
> 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.
All that is great and I'm all for it, but it doesn't speak to the need for the
Community to provide a somewhat "sanctioned" workspace that folks can go to to
get at modules (thirdparty or core) that represents a canonical central point
for those forks ongoing in the community. So the reasons I state do not have to
do with rights to commit to those points as much as compartmentalizing the
activity on the project so that the developers can be more efficient at keeping
track of ongoing work in their area of interest.
Mark
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Technologielaan 9 - 3001 Heverlee - Belgium
------------------------------------------------------------------------------
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
