+1
I think some of this becomes easier if / when we move to Git - particularly
with the more 'sandbox' type developments, where forking to prototype of a
set of changes to the existing code and merging back in at a later date is
required.
But I wouldn't advocate accelerating making that kind of decision without
really considering the consequences. It would probably be a good idea to use
Git for the GSoC projects as a way to ease ourselves into the management of
Git forks, and inform a decision to switch later.
G
On 8 April 2011 16:18, Tim Donohue <tdono...@duraspace.org> wrote:
> All (especially Committers),
>
> +1 to what Mark Diggory states below about bringing in progress DSpace
> projects (especially major ones) to a more public space.
>
> I'd like to see us all get in the habit of working more "publicly",
> especially when it comes to redesign of core features of DSpace.
>
> So, if possible, I'd encourage all major DSpace projects/prototypes (no
> matter how early in their development phase) to do the following:
>
> (1) Create a central SVN space for this code (either in 'sandbox' or in
> 'modules'). Where you put it doesn't matter as much as that it is
> publicly available. Alternatively, if you have an external, public SVN
> or git repository, you can also share it there.
>
> (2) Put some early documentation up on the Wiki (obviously doesn't need
> to be perfect, but something people can start from). This also provides
> an area where others can give immediate feedback, help in brainstorming,
> etc.
>
> (3) Create a JIRA issue / placeholder to link the SVN location with the
> early wiki documentation (and assign it to yourself). This helps ensure
> all developers are aware of the project, even if they aren't subscribed
> to 'dspace-changelog' or watching the wiki closely.
>
> For examples of projects which are already working/sharing code in a
> more "public" manner, please see the following:
>
> * Graham Triggs' WebMVC project:
> * SVN: http://scm.dspace.org/svn/repo/modules/webmvc/
> * Wiki Docs:
> https://wiki.duraspace.org/display/DSPACE/WebMVC+%28Freemarker%29+UI
>
> * Robin Taylor's SWORD Client Project/Prototype:
> * SVN: http://scm.dspace.org/svn/repo/sandbox/sword-client-prototype/
> * JIRA Issue describing it: https://jira.duraspace.org/browse/DS-602
>
> * My (Tim Donohue's) Easy Installer Project/Prototype:
> * SVN: http://scm.dspace.org/svn/repo/sandbox/installer-prototype/
> * Wiki Docs:
> https://wiki.duraspace.org/display/DSPACE/InstallerPrototype
> * JIRA: https://jira.duraspace.org/browse/DS-802
>
> So, I'd encourage both the CGI project/prototype and the Configurable
> Reviewer workflow project/prototype to try and follow a similar public
> path.
>
> - Tim
>
> On 4/7/2011 6:47 PM, Mark Diggory wrote:
> > It would be good to see more documentation of the project in the wiki.
> > We may be able to provide more transparency and peer review on the
> > project if there were more detail concerning it. So far the CGI work
> > has about one paragraph of description. And we all appear to want to
> > contribute viewpoints in this area, it would be better to bring the
> > whole topic and the code work into center stage with greater detail on
> > what your up to.
> >
> > https://wiki.duraspace.org/display/DSPACE/CGIProposal
> >
> > I'm of the opinion that more coordination needs to occur here to make
> > sure we are all not on a collision course with our work. We've
> > already had to readjust Reviewer workflow once to adapt to Curation
> > tools and we will need a significant dialog with you concerning the
> > fact that curation tools have a bit of incompatibility with how it is
> > wired to hardcoded workflow stages where the configurable Reviewer
> > workflow is, well an non-hardcoded series of configured workflow
> > stages. If you have time next week, it would be great to have a skype
> > call or IRC chat on the topic.
> >
> > TBH, I really don't think that architectural redesigns of critical
> > areas of DSpace should happen without significant discussion and
> > feedback with the community. This includes what we are about to
> > present with the Reviewer Workflow. I think its important to bring
> > this stuff into the community earlier to asure that when others want
> > to participate (GSoC or otherwise) theres a sufficient door open to
> > allow that participation. It would also allow for less replication of
> > effort because we are already working similar activities with Reviewer
> > Workflow which will be coming out shortly as well.
> >
> > So, yes, I would love a look, but also, I think we want the community
> > to have an opportunity for peer review and possible opportunities for
> > GSoC students to participate in the work.
> >
> > Best,
> > Mark
> >
> > On Thu, Apr 7, 2011 at 10:32 AM, Richard Rodgers<rrodg...@mit.edu>
> wrote:
> >> HI Mark:
> >>
> >> You might want to keep an eye on the CGI stuff we are working on - it
> essentially amounts to your option #3
> >> (DB serialization). I should have a demo ready by OR11, but if you are
> interested in 'early access', I'd be happy to give you a look.
> >>
> >> Thanks,
> >>
> >> Richard
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Dspace-commit mailing list
> dspace-com...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-commit
>
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
