[sakai-pmc] [cle-release-team] [Building Sakai] Lazy consensus proposal to branch Sakai 10
Kirschner, Beth
bkirschn at umich.edu
Tue Feb 11 05:26:20 PST 2014
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140211/3c769553/attachment-0001.html
-------------- 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/20140211/3c769553/attachment-0003.jpg
-------------- 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/20140211/3c769553/attachment-0004.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/20140211/3c769553/attachment-0005.jpg
More information about the sakai-pmc
mailing list