Hey guys,
it's great to see commiters reviewing other developers' code, as for
example the recent developments by Keiji and Andrea.
I wanted to suggest an easier way to facilitate such collaboration.
Currently, the reviewer comments and waits for the original developer to
incorporate the comments. An obvious improvement would be for the developer
to give the reviewer write access to his fork. The disadvantages are that
you don't know in advance who will be reviewing your code and maybe you
have other public branches that you don't want to let others touch.
An improvement to that solution would be to have another fork of the
DSpace/DSpace repository (let's call it *collab*) where all commiters (and,
if we decide so, also other trusted developers) would have write access. So
if you're working on any issue in Jira and you're ready to launch a pull
request, you would create the source branch of that PR in *collab*. That
way, with everyone having access to it, they could fix obvious mistakes
right away, even on already open PRs. The original developer would still
have the freedom to develop in his own personal fork without interference.
As I mentioned, we could also decide to open this *collab *repository for
non-commiters, as a way to give trusted developers more privilieges - a
gradual progress towards commitership. In this case, the *collab* repository
would not be under DSpace/collab, but under a separate "organization"
(which is a GitHub term for a group of people with access privileges to a
group of repositories).
What do you think?
I also have a second, similar but distinct idea. I'll call this *contrib*. *
contrib* would be a separate repository, *not* a fork of DSpace/DSpace, but
a place where optional addons would be officially published and could be
collaboratively maintained.
Over the existence of the DSpace project, there has been a dozen of quite
successful DSpace addons, which were intentionally not made part of DSpace,
but maintained in parallel. They all have their target group, but do not
necessarily contribute towards the direct DSpace objectives or commiters
are not able/willing to maintain them. Examples of such addons include SRW,
Minho stats, OAIExtended, Semantic Search, REST API or DSpace-CRIS. It is
my observation that it's a lot of work to maintain so called out-of-tree
code. The benefit of *collab* would be that the maintenace burden of
maintaining addons could be shared with a wider community. For example, if
the original author doesn't have time to work on porting their addon to
work with the newest version of DSpace, an interested user could contribute
with such porting work and ever user of that addon would immediately have
access to it.
An open question about the *contrib* repository is how it would deal with
versioning. It is often desirable to keep an up-to-date version of an addon
for an older version of DSpace because the older version is deployed in
production. This could be solved using anything from separate directories,
branches or even several collab repositories for different versions of
DSpace.
Do you approve? Disapprove? Have any comments? Do you have any additional
use cases that could be adressed by shared repositories?
Regards,
~~helix84
Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
