I'm also +1 on having some documentation describing the project you're
working on, and how to get started. Which is why I made a getting started
guide for
Discovery<https://wiki.duraspace.org/display/DSPACE/DSpace+Discovery+HowTo>
and
WebMVC<https://wiki.duraspace.org/display/DSPACE/WebMVC+%28Freemarker%29+UI>
.
If anyone would like their project to be sync'ed to github, I've got the
conversion process figured out.
## One time process to copy a svn project into a Git project, while
preserving all commit history.
git svn clone -s http://scm.dspace.org/svn/repo/modules/webmvc/
## Create a public repo on github
git remote add github g...@github.com:DSpace/webmvc.git
For now, I'm just one-way syncing projects. SVN being official, and github
being a public mirror.
The nightly cron job:
#!/bin/bash
cd /home/peter/NetBeansProjects/github/webmvc-project/webmvc
git svn fetch
for branch in `git branch`; do git checkout $branch; git svn rebase; done
git push github --all
However, an ideal workflow for development, would be to convert the project
to Github. With the DSpace "organization" repo as the official version.
Users can fork it, and have their local improvements, and send a pull
request to the DSpace organization to incorporate your improvements. This
lets big changes by Mark Diggory get a bit of time to get a few eyes on an
upcoming commit, before it gets merged into trunk. It also allow lowers the
barrier to entry, so that new developers can send a pull request that shows
their changes and an official DSpace commiter will review the changes and
merge it into master/trunk. Its also possible for a University organization,
such as MIT to fork the DSpace copy, then Richard and Sands can then fork
the MIT copy, and send pull requests to the MIT organization saying I've
added new-MIT-feature-1. Sands could then wear a different hat, when he's
going to make an official DSpace/Duraspace commit, and work from a
repository for himself that is directly forked from DSpace/DSpace.
Sorry if this sounds like excessive rambling, its somewhat cleared when you
draw things out on a whiteboard. But it does get a bit hairy at times:
[image: many-branches.png]
For an example pull request. Kim forked Stuart's Easy Deposit project (a
configurable php submission interface for Sword), and Kim made improvements
to his own version of the repository, and notified the project owner,
Stuart, that he'd like him to review and hopefully accept and merge the
improvements into master. This one is interesting because it is developed
solely in git.
https://github.com/stuartlewis/EasyDeposit/pull/1
For all of our "modules", they are outside of trunk anyways. The only
connection they have with trunk is that they get wired in through a pom,
while they're both checked out to nearby directories.
An example module project, that I've got synced to Github. (Note: official
commits happen in svn).
https://github.com/DSpace/webmvc
<https://github.com/DSpace/webmvc>And you can notice that I had a comment on
the commit, and could easily ask it, and bug the committer to hopefully get
a response:
https://github.com/DSpace/webmvc/commit/82b802ead0cfc1522e20d4a0f55160a392d4a38e
Additionally, I've got our main branch/tag/trunk DSpace code,
http://scm.dspace.org/svn/repo/dspace/, mirrored in Github at:
https://github.com/DSpace/DSpace
Its got an attached wiki, but its mostly just advice for how to work with
the Git repository.
Peter Dietz
On Fri, Apr 8, 2011 at 11:18 AM, 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
