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

Wed Feb 12 05:49:07 PST 2014

It sounds like we are moving forward with branching. Thanks Beth for
stepping in to do some of the work.

-- Neal

On Tue, Feb 11, 2014 at 8:26 AM, Kirschner, Beth <bkirschn at umich.edu> wrote:

> Thanks for pointing that out. The hierarchy dump/load will be a bit
> messier, since I'll have to change it's path. I have done this sort of
> thing several years ago (dump/load and changing repo paths), and it was
> fairly straightforward, though a bit tedious. There will be some move
> (deletes/adds) in the svn history.
>
> I'll plan to work on this tomorrow unless I hear objections by end of day
> today.
>
> - Beth
>
> On Feb 10, 2014, at 4:49 PM, Anthony Whyte <arwhyte at umich.edu> wrote:
>
> If you opt for delete with regard to the contrib repos, mind how you craft
> the delete url for the hierarchy project.  In other words, don't delete
> contrib/CARET, just hierarchy.    If you delete get rid of the contrib
> mailsender project as well.
>
> Cheers,
>
> Anth
>
>
>
> anthony whyte | its and mlibrary | university of michigan |
> arwhyte at umich.edu | 517-980-0228
>
>
> On Feb 10, 2014, at 4:41 PM, Matthew Jones wrote:
>
> 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
>
>
> _______________________________________________
> 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/20140212/3f748f33/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1247 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140212/3f748f33/attachment-0003.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1222 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140212/3f748f33/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 992 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140212/3f748f33/attachment-0005.jpg 