Re: [Dspace-devel] [Dspace-commit] DSpace codebase will be moving to GitHub. It's official!

2012-03-14 Thread Peter Dietz 
Hi All,

Since we're now ready to migrate all of the remainder code to GitHub, two
questions have popped up.

1) Should we stick with the existing Github.com/dspace/dspace repository,
or should we reimport (a fresh git svn clone) so that we can use the author
mapping to make old commits point to a user's GitHub profile? By pushing
that change, it would make the current repo incompatible with anyone who
has forked it, as the reimport would have completely different commitID's.


2) What should we do about languages? We have
dspace-xmlui-lang
and
dspace-api-lang
I
don't imagine that people like having to manage two separate language
files. So would we want to consolidate that into a single project? If so,
anyone up to doing the work for that refactoring? Where would
messages/language extensions for modules fit?




Peter Dietz



On Thu, Mar 8, 2012 at 5:14 PM, Tim Donohue  wrote:

> Hello developers,
>
> By a unanimous decision on 'dspace-devel', the DSpace codebase will be
> moving to GitHub in the near future.
>
> By my tally, the results were:
>
> 20 developers/committers in favor of migrating (+1 vote)
> 0 developers/committers unsure about migrating (0 vote)
> 0 developers/committers against migrating (-1 vote)
>
> I will now be working with the Committer team to begin this migration
> process. The migration will likely happen in a series of stages in the
> coming weeks.
>
> I've started a wiki page to begin tracking the migration process:
> https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub
>
> (Others are encouraged to add to / enhance this page, as I'm sure there
> are things I've forgotten. Right now, just some initial steps are listed
> there)
>
> The vast majority of this migration process should happen "behind the
> scenes" (most developers won't notice anything until the end). But, once
> we get closer to completion, we will announce the date at which all
> development is now taking place on GitHub. We will also create some
> developer documentation around using the new DSpace GitHub.
>
> If anyone has any questions, or wants to help out in any way (especially
> with creating eventual DSpace GitHub documentation), please let us know!
>
> - Tim (on behalf of the Committers Team)
>
>
> On 2/29/2012 9:58 AM, Tim Donohue wrote:
> > Hi All,
> >
> > As I've previously stated, today we are opening the vote for whether
> > DSpace should move its codebase from SVN to GitHub. More information on
> > what this means is below (see "What does this Migration to GitHub Mean?"
> > section)
> >
> > You may vote by responding to this email thread with one of the
> following:
> >
> > +1 = I vote to migrate to GitHub
> > 0 = I'm neutral (I don't really care one way or the other)
> > -1 = I'd rather DSpace codebase stay on SVN
> >
> > Based on our Voting for Procedural/Policy Changes, this vote will pass
> > if we receive more positive (+1) than negative (-1) votes.
> > https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
> >
> > VOTING WILL BE OPEN FOR ONE WEEK, UNTIL 20:00UTC ON WEDNESDAY, MARCH 7.
> >
> >
> > = What Does this Migration to GitHub Mean? =
> >
> > Essentially, if we vote to migrate the DSpace Codebase to GitHub, the
> > following changes will occur:
> >
> > 1. All DSpace projects/modules/codebases that are still in active
> > development will be migrated to https://github.com/DSpace/
> >
> > 2. The existing SVN codebases will be "archived" and made READ-ONLY (no
> > more changes or future releases will occur in SVN). This SVN archive
> > will likely also be moved to: https://svn.duraspace.org/ (we can setup a
> > redirect such that scm.dspace.org will redirect to the archived
> location).
> >
> > 3. All future development, releases (tags) & branches will occur in the
> > DSpace GitHub projects. This means that any active DSpace developers
> > will need to begin using this codebase instead of SVN.
>
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Dspace-commit mailing list
> dspace-com...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-commit
>
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Dspace-devel mailing list
Dspace-devel@lists.source

Re: [Dspace-devel] [Dspace-commit] DSpace codebase will be moving to GitHub. It's official!

2012-03-16 Thread Mark Diggory 
On Wed, Mar 14, 2012 at 11:53 AM, Peter Dietz  wrote:

> Hi All,
>
> Since we're now ready to migrate all of the remainder code to GitHub, two
> questions have popped up.
>
> 1) Should we stick with the existing Github.com/dspace/dspace repository,
> or should we reimport (a fresh git svn clone) so that we can use the author
> mapping to make old commits point to a user's GitHub profile? By pushing
> that change, it would make the current repo incompatible with anyone who
> has forked it, as the reimport would have completely different commitID's.
>

I think we should drop the existing repo and reimport with corrected
authors.  Unless there is any possible means to just update the existing
repo with the authors.  Yes this will be a pain for those of us who have
forked... but were actually the ones capable of managing this migration.


>
> 2) What should we do about languages? We have 
> dspace-xmlui-lang
>  and
> dspace-api-lang
>  I
> don't imagine that people like having to manage two separate language
> files. So would we want to consolidate that into a single project? If so,
> anyone up to doing the work for that refactoring? Where would
> messages/language extensions for modules fit?
>

Each project is "separate" and meant to be updated separately.  If we want
to merge and refocus this so that language updates are part of minor
releases, I'm ok as it will probably lead to less confusion for the
community.  This means that dspace-api-lang would go under
dspace-api/src/main/resources  and that dspace-xmlui-lang would go under
dspace-xmlui/src/main/webapp/

Finally, I want to toss in that my Maven project consolidation coding
combined with the above will really simplify dspace build...
https://github.com/mdiggory/DSpace/tree/maven-project-consolidation

Mark

-- 
[image: @mire Inc.]
*Mark Diggory *(Schedule a
Meeting
)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Re: [Dspace-devel] [Dspace-commit] DSpace codebase will be moving to GitHub. It's official!

2012-03-16 Thread Peter Dietz 
As I thought about this a bit more, I did somewhat have a change of heart,
and kind of think we ought to "properly" redo it.

Imagine when DSpace migrates to xyz-version-control in a decade. We'll all
be emeritus, and wondering where our place in history is.  And the future
people migrating the code will be like, hey, home come there's two
different mappings for authors.

Another possible question, is people who have svn commits, but will not be
creating github accounts, those commits need to be swallowed by a user. So
either ping everyone else to be like, hey, can you create an account,
otherwise we dump all their commit attribution onto another user. I'm not
sure what happens if you have a partial author mapping.

And to address the, hey, your broke my fork of you. We could leave
DSpace/DSpace renamed to DSpace/DSpace-pre-official until everyone un-forks
it, and then we just spend the half-day fixing forks.

So, consider me talked-in-and-out of shall we.



Peter Dietz



On Fri, Mar 16, 2012 at 4:39 PM, Mark Diggory  wrote:

>
>
> On Wed, Mar 14, 2012 at 11:53 AM, Peter Dietz  wrote:
>
>> Hi All,
>>
>> Since we're now ready to migrate all of the remainder code to GitHub, two
>> questions have popped up.
>>
>> 1) Should we stick with the existing Github.com/dspace/dspace repository,
>> or should we reimport (a fresh git svn clone) so that we can use the author
>> mapping to make old commits point to a user's GitHub profile? By pushing
>> that change, it would make the current repo incompatible with anyone who
>> has forked it, as the reimport would have completely different commitID's.
>>
>
> I think we should drop the existing repo and reimport with corrected
> authors.  Unless there is any possible means to just update the existing
> repo with the authors.  Yes this will be a pain for those of us who have
> forked... but were actually the ones capable of managing this migration.
>
>
>>
>> 2) What should we do about languages? We have 
>> dspace-xmlui-lang
>>  and
>> dspace-api-lang
>>  I
>> don't imagine that people like having to manage two separate language
>> files. So would we want to consolidate that into a single project? If so,
>> anyone up to doing the work for that refactoring? Where would
>> messages/language extensions for modules fit?
>>
>
> Each project is "separate" and meant to be updated separately.  If we want
> to merge and refocus this so that language updates are part of minor
> releases, I'm ok as it will probably lead to less confusion for the
> community.  This means that dspace-api-lang would go under
> dspace-api/src/main/resources  and that dspace-xmlui-lang would go under
> dspace-xmlui/src/main/webapp/
>
> Finally, I want to toss in that my Maven project consolidation coding
> combined with the above will really simplify dspace build...
> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation
>
> Mark
>
> --
>  [image: @mire Inc.]
> *Mark Diggory *(Schedule a 
> Meeting
> )
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
>
>
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Re: [Dspace-devel] [Dspace-commit] DSpace codebase will be moving to GitHub. It's official!

2012-03-19 Thread Tim Donohue 
RE: the complete "rebuild" of the existing DSpace/DSpace GitHub.

I'm also OK with rebuilding it entirely (and re-mapping all SVN users -> 
GitHub Users).  However, I agree with Peter Dietz, that we should rename 
the existing "DSpace/DSpace" to "DSpace/DSpace-pre-official" (or perhaps 
"DSpace-pre-migration" or "DSpace-unmaintained").  We should also post a 
warning to all users that they need to switch to 'forking' the new 
official "DSpace/DSpace".

I've updated our migration docs to detail this:
https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub#MigrationtoGitHub-MainCodebases

- Tim

On 3/16/2012 4:00 PM, Peter Dietz wrote:
> As I thought about this a bit more, I did somewhat have a change of
> heart, and kind of think we ought to "properly" redo it.
>
> Imagine when DSpace migrates to xyz-version-control in a decade. We'll
> all be emeritus, and wondering where our place in history is.  And the
> future people migrating the code will be like, hey, home come there's
> two different mappings for authors.
>
> Another possible question, is people who have svn commits, but will not
> be creating github accounts, those commits need to be swallowed by a
> user. So either ping everyone else to be like, hey, can you create an
> account, otherwise we dump all their commit attribution onto another
> user. I'm not sure what happens if you have a partial author mapping.
>
> And to address the, hey, your broke my fork of you. We could leave
> DSpace/DSpace renamed to DSpace/DSpace-pre-official until everyone
> un-forks it, and then we just spend the half-day fixing forks.
>
> So, consider me talked-in-and-out of shall we.
>
>
>
> Peter Dietz
>
>
>
> On Fri, Mar 16, 2012 at 4:39 PM, Mark Diggory  > wrote:
>
>
>
> On Wed, Mar 14, 2012 at 11:53 AM, Peter Dietz  > wrote:
>
> Hi All,
>
> Since we're now ready to migrate all of the remainder code to
> GitHub, two questions have popped up.
>
> 1) Should we stick with the existing Github.com/dspace/dspace
> repository, or should we reimport (a fresh git svn clone) so
> that we can use the author mapping to make old commits point to
> a user's GitHub profile? By pushing that change, it would make
> the current repo incompatible with anyone who has forked it, as
> the reimport would have completely different commitID's.
>
>
> I think we should drop the existing repo and reimport with corrected
> authors.  Unless there is any possible means to just update the
> existing repo with the authors.  Yes this will be a pain for those
> of us who have forked... but were actually the ones capable of
> managing this migration.
>
>
> 2) What should we do about languages? We have dspace-xmlui-lang
> 
> 
>  and
> dspace-api-lang
> 
> 
>  I
> don't imagine that people like having to manage
> two separate language files. So would we want to consolidate
> that into a single project? If so, anyone up to doing the work
> for that refactoring? Where would messages/language extensions
> for modules fit?
>
>
> Each project is "separate" and meant to be updated separately.  If
> we want to merge and refocus this so that language updates are part
> of minor releases, I'm ok as it will probably lead to less confusion
> for the community.  This means that dspace-api-lang would go under
> dspace-api/src/main/resources  and that dspace-xmlui-lang would go
> under dspace-xmlui/src/main/webapp/
>
> Finally, I want to toss in that my Maven project consolidation
> coding combined with the above will really simplify dspace build...
> https://github.com/mdiggory/DSpace/tree/maven-project-consolidation
>
> Mark
>
> --
> @mire Inc.
>   *Mark Diggory *(Schedule a Meeting
> 
> )
> /2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
> /Esperantolaan 4, Heverlee 3001, Belgium/
> http://www.atmire.com 
>
>
>

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel