[sakai-pmc] PROPOSAL: svn cleanup

[Steve Swinsburg]

Link tool wasn't on the original list and won't be touched in this round.

JFL, see earlier email. The projects that affect 2.8 and 2.9 and hybrid and
pure poms and are no longer on the list to move. Does that reverse your -1?

In response to Anthony, I see this task taking an hour max. Your new
proposal would take much longer, time which I do not have at this point.
Active contrib projects are generally maintained by someone or some team
other than the main Sakai maintainers so I would suggest they be
recommended to be moved by their own people - they might not want to move
at this time and unless we have some official space then we can't really
force them. If we were to say that contrib is being turned off then that
could be encouragement enough ;)
There are also bits of code in there linked from all over confluence and
everywhere else so it would take a concerted effort to move properly.

The projects I listed are well and truly deprecated. If we move to github
this cleanup will put us in good stead so we know what to move and don't
waste time moving stuff that is dead. Then everything that's deprecated we
can make an decision on about moving to a special location or doing
something else with.


sent from mobile device
On 11/12/2013 8:24 AM, "Anthony Whyte" <arwhyte at umich.edu> wrote:

>
> *Seth:* Is this a -1 to the whole proposal or just specific parts? We
> have historically moved projects that are deprecated, but haven't for some
> time (see the existing contrib/deprecated folder). This brings us up to
> date with that practice.
>
>
> The practice to which Steve refers to above is long dead.  We deliberately
> stopped moving projects dropped from the core distribution to contrib long
> ago because doing so wasted good time better spent elsewhere.
>
> I'd rather see this proposal dropped in favor of one that repoints Steve's
> clean up energies towards migrating contrib projects deemed useful to
> Github (as Adrian Fish has done for Clog and Yaft) and ensuring that they
> build against 10.  This would help prepare the way for a more general
> proposal aimed at shifting current development (i.e., Sakai trunk) to Git
> and Github sometime during the summer of 2014.
>
> I like the /svn/deprecated option
>
>
> I am not a fan of svn/deprecated.  In theory, a capability could be
> dropped from the core distribution and yet continue to be maintained by a
> segment of the community.  It would be misleading to label such projects as
> deprecated by pushing it into svn/deprecated if there are organizations
> willing to maintain the code.
>
> Linktool is one such example.  Out of the build for 10+; alive and kicking
> for 2.9 and earlier.  I expect Rutgers will continue to maintain linktool
> for some time.
>
> *Cris:* The only ones are hybrid and pure-poms so in the interest of
> simplicity, those will be dropped from this proposal and can be moved when
> 2.9 becomes unsupported. I dislike updating tags - if there is another 2.9
> release they could possibly be adjusted then.
>
>
> Linktool is another.
>
>
> anthony whyte | its and mlibrary | university of michigan |
> arwhyte at umich.edu | 517-980-0228
>
>
> On Dec 10, 2013, at 3:30 PM, Matthew Jones wrote:
>
> Ya, I like that one too. If we avoided the repos that were used (hybrid,
> pure-poms, was) then that wouldn't cause a problem for previous builds (and
> JFL's objection)
>
>
> On Tue, Dec 10, 2013 at 3:28 PM, Kirschner, Beth <bkirschn at umich.edu>wrote:
>
>> On Dec 9, 2013, at 6:01 PM, Steve Swinsburg <steve.swinsburg at gmail.com>
>> wrote:
>>
>> > Megan: Thanks for the note. I'll wait to hear from UMich about that
>> project.
>> >
>> UM is not using https://source.sakaiproject.org/svn/gradtools - it can
>> be removed (we are using
>> https://source.sakaiproject.org/svn/msub/umich.edu/ctools/gradtools/ --
>> looks like that was created in 2009).
>>
>> > Matt: I was going to use svnadmin to do it but the easier option is to
>> just move them into a /svn/deprecated folder, so will do that for now.
>> >
>> I like the /svn/deprecated option
>>
>> > Cris: The only ones are hybrid and pure-poms so in the interest of
>> simplicity, those will be dropped from this proposal and can be moved when
>> 2.9 becomes unsupported. I dislike updating tags - if there is another 2.9
>> release they could possibly be adjusted then.
>> >
>> > Seth: Is this a -1 to the whole proposal or just specific parts? We
>> have historically moved projects that are deprecated, but haven't for some
>> time (see the existing contrib/deprecated folder). This brings us up to
>> date with that practice.
>> >
>> > cheers,
>> > Steve
>> >
>> >
>> > On Tue, Dec 10, 2013 at 4:14 AM, Seth Theriault <slt at columbia.edu>
>> wrote:
>> > On Mon, Dec 9, 2013 at 10:27 AM, Matthew Jones <matthew at longsight.com>
>> wrote:
>> > > Rather than move them to contrib, which would lose the history unless
>> we/you
>> > > use svnadmin to dump and reload into contrib (which you may or may
>> not be
>> > > considering), perhaps keeping them in that repo and moving them all
>> into
>> > > /svn/deprecated or /svn/msub/deprecated would be a better/easier idea.
>> >
>> > I don't see any real reasons to specifically move these projects to
>> > contrib. It just creates more work and ways to break things.
>> >
>> > Seth
>> >
>> >
>> > _______________________________________________
>> > sakai-pmc mailing list
>> > sakai-pmc at collab.sakaiproject.org
>> > http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
>>
>> _______________________________________________
>> sakai-pmc mailing list
>> sakai-pmc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
>>
>
> _______________________________________________
> 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/20131211/04a8f16b/attachment-0001.html