Hi all, A few rough thoughts inline..
On 8/15/2013 3:13 PM, helix84 wrote: > 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'm not sure if I fully understand the benefits to this workflow. It has some niceties, but seems to add more steps in other cases.. For example, suppose I make a nice new enhancement to my DSpace and stick it in my own GitHub repo. If my GitHub repo is a fork from DSpace/DSpace, it's a rather quick process to generate a new PR directly there. But, if I need to go through DSpace-collab/DSpace, then I first need to create a branch there (and ensure that branch is up-to-date) before creating a PR in DSpace/DSpace. This seems like it takes an extra step (unless I'm misunderstanding) Or, what if I misunderstand and just create a PR to DSpace-collab/DSpace (or fork DSpace-collab/DSpace instead of DSpace/DSpace)? It creates an extra step to then move this PR to DSpace/DSpace. I worry essentially we're gonna get folks coming through differing routes & forking different places / submitting PRs to different places. All of this could accidentally cause more management work on Committers. (Maybe I'm misunderstanding this proposed workflow though. I'm just worried it makes certain PR tasks slightly easier while making other tasks much more complex...and also means we essentially have to watch/maintain two repos at once. If I am misunderstanding, then feel free to correct my assumptions!) > 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. I think I agree with Andrea Bollini on this part. The hardest part in some cases is around "who controls/owns/maintains the code". Although conceptually it seems like a nice idea to pull things things into one GitHub account -- it may not be possible in terms of code control/ownership. There needs to be a formalized code/license "handover" to some other supporting entity (e.g. DuraSpace or the DSpace Committers). Otherwise folks may assume that any projects under a "DSpace-collab" account are actually being managed/maintained/supported by DSpace Committers or DuraSpace. If code ownership/maintenance/support is not clearly communicated, we run the risk of misleading our users or accidentally causing mistrust (if we aren't maintaining things that they assume we should be maintaining). Maybe it'd be possible to "fork" third-party addons into a "DSpace-collab" or similar account, and therefore provide a centralized space to submit PRs back to that third-party. That way code ownership stays with the third-party. But, I'm not sure if there's much benefit to that over just creating your own individual fork & submitting back PRs? Ideally, I'd also rather have a better DSpace plugin framework to support third-party addons (like Andrea mentioned). We need to avoid "centralizing" the code/support for all addons, as our Committer team cannot do it all, and in many cases third-parties are in a better situation to manage the addon. Instead, we need to build a way to easily locate/find third-party addons, but also make it clear *who* owns/maintains/supports those addons and what the addon licensing terms are (this all starts to sound like a "marketplace" idea to me) My ideas here are still very rough, and as I said above, it's possible I'm misunderstanding some suggestions. But, those are my immediate (rough) thoughts. - Tim ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
