Hi Ivan,
Il 15/08/2013 22:13, helix84 ha scritto:
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.
yes, this could be an improvement but I'm not sure how big it is and if
an additional repository will look more confusing that helpful to
people. We will need to add some automatic script to assure that the
master is keep up-to-date with the official master this is need to
safety find merged branch and delete it. Otherwise we will end fastly to
a long unmanageable list of branches.
It is important to note that not all the changes that we want propose to
a pull request are appropriate to be done pushing directly to the pull
branch. Sometime we want just propose something and have the original
author to verify/approve. In such case it is best to open a pull request
against the pull request branch (as I usually done vs the original
developer repository).
Another improvement that you solution introduce is that the committer
that want to perform the merge is able to make the rebase or squash of
the original pull request, in this way there is a chance to save some
stats (github will see this pull request as merged) but I'm not sure
about what of the discussion around the pull request will be lost
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).
yes, I really like to have only a standard workflow. If we introduce a
second organization/repo I will like that at most all the pull requests
come from it.
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.
here the question is much more complex.
I see two different issues:
- a legal/ownership issue: some contribution are very big projects as in
the case of my DSpace-CRIS and the original authors/company want to
maintains the ownership or will be available to transfer it to duraspace
only if a substantial endorsement of the project is done by duraspace.
This mean a sort of incubation status where for example we will open a
jira project to track issue related to this contribution, a wiki area, etc.
- a technical issue: actually we don't have a really plugin/addon
mechanism for dspace. Any contribution need to make some customization
to the "DSpace core" to be able to compile/integrate their features
(sometimes to the pom files others also to java classes). For
DSpace-CRIS we have had to setup several branch on the CILEA/DSpace fork
to manage such integration
I'm sorry, I have more issues to report than answers.
A long term solution requires that:
1) we need to have a real plugin/addon mechanism
2) we need to setup a directory of hight rated/supported addon
(incubation) and a directory of trusted, available out of box, addons
3) we need a market place
Andrea
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
--
Andrea Bollini
Dipartimento Servizi e Soluzioni per l'Amministrazione Universitaria
Divisione Ricerca
Via dei Tizii, 6
00185 Roma, Italy
tel. +39 06 44 486 087 - mob. +39 348 82 77 525
http://www.cineca.it
------------------------------------------------------------------------------
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
