On 5 May 2011 22:48, Tim Donohue <tdono...@duraspace.org> wrote:
> I will state that I *completely* agree that we should have an "open
> development workspace" for anyone (committers or non-committers) to
> create their own Maven projects & DSpace plugins. But, I think that is
> *NOT* the same as what the "modules workspace" currently is. The
> "modules workspace" is currently an unfortunate jumble of "stable,
> controlled" modules, unstable/experimental modules, third-party
> developed modules, and outdated/obsolete modules.
> I admit, I'm still hazy on whether you are suggesting that we should
> remove the Committer boundaries/gatekeeping on *all* Maven projects, or
> just on a sub-set of those projects. Obviously, there's a big
> difference there. So, I'd be curious to hear which "boundaries" you
> would see as remaining, and which would "go away" based on your
> suggestions.
>
I'm going to jump in with a fairly definitive statement / viewpoint - people
can shoot it down as they see fit.
There are plenty of open development workspaces that people can use for
creating addons - start a project on SourceForge, Google Code, GitHub. It's
trivial for anyone to just go ahead and do that, and applying their own
governance, without needing to be let in the door by one of our gatekeepers.
Saying that we need to provide an open development workspace is tantamount
to saying - if you want to find an addon, go and look in the source tree.
I've said it before, and I'll reiterate it here - that is a fundamentally
broken way for people to discover what addons exist for DSpace. We should be
concentrating on a user (not just developer) friendly website - directories,
tagging, project pages for the addons. You discover the addons in the
catalog, and the project page points to where the source is.
Or, if we really want to push, lets stop screwing about with svn reorgs,
granular permissions, module directories, etc. - and just run our own
FusionForge server.
But all these discussions and confusion are showing me is that we should
just simplify it even further beyond release vs addons (which is itself a
simplification from current situation of some parts of the release being in
'modules' alongside addons, prototypes, etc.)... and get back down to
'release' - and possibly a few 'important' addons - that sit in the official
source tree, and are subject to all that is entailed by DSpace governance.
And we absolutely encourage there to be more addons by the community, and in
doing so we ensure that we are providing ways for them to be discoverable by
the community - but the source tree(s) kept clearly separate from 'DSpace'
itself.
This would encounter an issue about moving projects between source trees
when they become 'official' or 'unofficial' - but I wouldn't expect that
situation to arise all that often.
It sounds like a tough point of view, but really it's about giving freedom
to the community. It sets addons free of the central gatekeepers, and let's
them define their own path. But we can only achieve that if we draw an
absolutely clear line for what is covered by DSpace governance and
responsibility.
> We want to attain a build process that allows for addons to exist
> > independently of the release cycle. thats always been the case.
>
> I think we found out yesterday that several people are not sure if we
> actually want that. We had several "undecided" votes (more 'undecided'
> than 'decided' votes in fact).
>
I'll be bold and say that we probably more decided than you suggest if you
take the statement of face value. Yes, if something is an addon - something
that an end user / developer can take and apply to their own DSpace
installation, and where we don't make a dependency on it from what we
release as a "packaged" DSpace - then it can be simply be released whenever
it's 'ready', at some point after the release(s) that it works with, then I
don't think any committer is perturbed by it having an independent release
cycle.
But where we do have a dependency from the "packaged" DSpace - whether it's
enabled (-stats?) or disabled (-discovery?) by default - then it ceases to
be an addon. Then we do have an issue about it's release cycle, it's release
procedures, it's governance, and it's accountability.
And to touch back on what was an earlier point:
>These are honest questions. The Committers as a whole have never
>discussed these sorts of policy changes. Obviously, we *don't* allow
>anyone who wants to work on XMLUI or JSPUI (as examples) to just start
>committing code. These policies can always be changed, but we need to
>discuss these changes before jumping to conclusions.
The interesting thing here is that any UI we could ultimately treat as an
'addon' - in that it's entirely feasible (with a bit of work on things like
configuration) to take either JSPUI or XMLUI - or develop any alternative UI
- as an addon, which is released on a separate schedule, has it's own
development team, governance, etc.
Clearly, we need to have at least one UI that is part of the release, and
subject to DSpace governance, etc. - but [proving that it can be done] we
currently have one new UI (webmvc) being developed essentially as an
'addon'. And it's possible that at some point it might become part of the
release, and / or JSPUI may move out of the release to be an addon (if there
is anyone still wanting to maintain it). I'll stress that I'm saying this an
example of how things could work, not a recommendation or roadmap.
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
