[sakai-pmc] [cle-release-team] [Building Sakai] Lazy consensus proposal to branch Sakai 10

Mon Feb 10 13:41:10 PST 2014

Agreed, everyone who has access to source currently for SVN maintenance
would have access to do this, you would be included.

I've never actually done it for Sakai, but these Stack Overflow
questions/answers below sound like what you'd need for step #1. You (or
someone else) would need to "svnadmin dump" the entire contrib repo, then
"svnadmindumpfilter" out everything on
https://jira.sakaiproject.org/browse/INFRSTR-255, then "svnadmin load" them
in. I'm guessing you can do this without any downtime.

For the legacy repos in contrib, sure either delete, leave them as-is or
take away write access. We're not going to reload/filter them (3) as that
would certainly be downtime on the contrib repo. The rest of this list
sounds great.

Refs:
-
http://stackoverflow.com/questions/417726/how-to-move-a-single-folder-from-one-subversion-repository-to-another-repository
-
http://stackoverflow.com/questions/13010496/svn-move-code-with-history-between-two-repositories

On Mon, Feb 10, 2014 at 4:32 PM, Kirschner, Beth <bkirschn at umich.edu> wrote:

> I think the real question is who has access to do this? The commands to do
> this are 'svnadmin dump' and 'svnadmin load'. Since  I have svnadmin
> access, so in theory, I should be able to do this.
>
> These are the contrib tools in the .externals file:
> roster2 https://source.sakaiproject.org/contrib/roster2/trunk
>  hierarchy https://source.sakaiproject.org/contrib/caret/hierarchy/trunk/
> delegatedaccess
> https://source.sakaiproject.org/contrib/delegatedaccess/trunk/
>  external-calendaring-service
> https://source.sakaiproject.org/contrib/external-calendaring-service/trunk/
>
>  signup https://source.sakaiproject.org/contrib/signup/trunk/
>
>
> Has there been any discussion on what to do with the legacy repos in
> contrib once they've been moved to core? I can think of several choices:
> 1) Leave them as read-only
> 2) Use 'svn delete' to remove them, but retain the historic commits
> 3) Completely delete the contrib repos
>
> I'd vote for option #2, but can go with option #1 while people discuss so
> that we can move things forward.  We're now 10 days behind schedule on
> creating a branch, so I'd like to help move things forward.
>
> I'd like to propose that I do the following:
>
> 1) Migrate the above contrib repos into core
> 2) Update .externals and svn:externals for the above
> 3) Mark the above contrib repos as read-only for now
>
> I can do this on Wednesday -- so I'd like to request lazy consensus to on
> having me moving forward with this by end of Tuesday.
>
> - Beth
>
> On Feb 10, 2014, at 3:05 PM, Neal Caidin <neal.caidin at apereo.org> wrote:
>
> I don't think the contrib tools have made it into core. Unfortunately not
> a lot of folks know how to do this, and so it could be a week or more
> before this gets done, unless there is a volunteer who has the knowledge
> and time to do it sooner.
>
> -- Neal
>
>
>
> On Mon, Feb 10, 2014 at 10:56 AM, Kirschner, Beth <bkirschn at umich.edu
> > wrote:
>
> On Feb 7, 2014, at 1:01 PM, Neal Caidin <neal.caidin at apereo.org> wrote:
>
> So sounds like it is a blocker then?
>
> jars in shared:
> backport-util-concurrent-3.1.jar
> ical4j-1.0.5.2.jar
>
> Can we make the proposal contingent upon finding a solution to this issue?
> Should there be a Jira to track (seems like that would be helpful for folks
> who want to follow the progress)?
>
> IMO, I don't think JIRA Blockers should block branching 10.0. Branching
> should be contingent on having trunk configured with the tools/modules
> needed for 10.0. What's the status on moving contrib tools to core? I know
> Anthony put a lot of work into that.
>
> - Beth
>
> Thanks,
> Neal
>
>
> Anthony Whyte February 7, 2014 at 12:58 PM
> No, did not exclude it.  I can test it though I doubt I'll get to it today.
>
>
> anthony whyte | its and mlibrary | university of michigan |
> arwhyte at umich.edu | 517-980-0228
>
>
>
>
> _______________________________________________
> sakai-pmc mailing list
> sakai-pmc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
>  Aaron Zeckoski February 7, 2014 at 12:41 PM
> I think Anthony tried this already and it failed but I will let him add
> more details about what he tried.
> -AZ
>
>
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
> Matthew Jones February 7, 2014 at 12:16 PM
> Well for the backport-utils, we should just need to add an exclusion to
> the ical4j dependency, as that's not needed on java 5+ as has been stated.
>
> <exclusion>
>   <artifactId>backport-util-concurrent</artifactId>
>   <groupId>backport-util-concurrent</groupId>
> </exclusion>
>
> I forget why the ical4j then needed to be in shared as it wasn't for
> calendar. I don't remember the discussion.
>
>
>
> _______________________________________________
> sakai-pmc mailing list
> sakai-pmc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
>  Aaron Zeckoski February 7, 2014 at 11:51 AM
> Not objecting to commons-codec but I am objecting to the additional jars
> in shared:
> backport-util-concurrent-3.1.jar
> ical4j-1.0.5.2.jar
>
> Especially backport which is basically supposed to allow java 1.4 to use
> concurrent stuff which is part of java 5 and java 6. Since we require java
> 6 it is crazy to put a backporting util into shared.
>
> I had understood last week that we were unable to get those out of shared
> last week but if I am wrong on that please let me know.
> -AZ
>
>
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>  Anthony Whyte February 7, 2014 at 11:28 AM
> Neal--Aaron's objection is quite likely different than mine.  My objection
> is based on a proposal that fails to list all contrib modules slated for
> transfer.  A bit of word smithing will eliminate my objection.  Aaron's
> objects, if I read him correctly, to the current requirement imposed by
> signup and ecs that the following two jars be deployed to shared/lib:
>
> backport-util-concurrent-3.1.jar
> ical4j-1.0.5.2.jar
>
> [note: commons-codec-1.8.jar is also now deployed to shared/lib but I'd be
> surprised if anyone objects to its new home given that 27 modules depend on
> it]
>
> If Aaron is objecting to the above (which I thought we had resolved last
> week at ApereoCamp) you've got a real blocker on your hands.
>
> Cheers,
>
> Anth
>
> anthony whyte | its and mlibrary | university of michigan |
> arwhyte at umich.edu | 517-980-0228
>
>
>
>
>
> --
> Neal Caidin
> Sakai Community Coordinator
> Apereo Foundation
> neal.caidin at apereo.org
> Skype me! (but let me know in advance for the first interaction) - nealkdin
>
> _______________________________________________
> sakai-pmc mailing list
> sakai-pmc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
>
>
>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140210/a0c08329/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1222 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140210/a0c08329/attachment.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1247 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140210/a0c08329/attachment-0001.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 992 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140210/a0c08329/attachment-0002.jpe 