> On Jan 20, 2019, at 8:57 AM, sebb <[email protected]> wrote:
>
> On Sun, 20 Jan 2019 at 13:44, Gary Gregory <[email protected]> wrote:
>>
>> I think the simplest would be to migrate them all. Then we can forget all
>> of that svn tree and mark it as read-only.
>
> +1
>
> It will make it easier to find things if they are all in one place.
+1. Agree. I’ll ask INFRA, what all we mirror from svn to github. I’ll ask that
they migrate those. We can, after the fact, decide which to put in the “attic.”
Thanks guys.
-Rob
>
>> Gary
>>
>> On Sun, Jan 20, 2019 at 6:48 AM Rob Tompkins <[email protected]> wrote:
>>
>>>
>>>
>>>> On Jan 20, 2019, at 4:08 AM, sebb <[email protected]> wrote:
>>>>
>>>>> On Sun, 20 Jan 2019 at 03:53, Rob Tompkins <[email protected]> wrote:
>>>>>
>>>>> Hey guys,
>>>>>
>>>>> I’m curious if you saw my conversation with Chris Lambertus over in
>>> INFRA about what to do with our SVN repos [1]? I’m not quite sure what to
>>> do now that we have the vote [2], to move the repos over. It seems that
>>> they want to “freeze” svn and make it read only in the migration. Do we
>>> want to take everything under “proper,” and make it it’s own git repo (I
>>> would think not).
>>>>
>>>> To clarify: every component/top-level directory under proper/ should
>>>> have its own git repo - if it is migrated.
>>>
>>> +1. Yes I agree.
>>>
>>>>
>>>>> I think we actually need to decide what the list is that we take
>>> up….alas that may warrant another [VOTE] (we’ll see what INFRA says there).
>>> So let’s see if we can draft that up (use “in” or “out” next to a component
>>> that we think should be “in the move to gitbox):
>>>>>
>>>>> bcel/ - in
>>>>> beanutils/ - in
>>>>> bsf/ - in
>>>>> chain/ - out
>>>>> codec/ - in
>>>>> commons-parent/ - in
>>>>> commons-skin/ - out
>>>>> commons-configuration/ - in
>>>>> daemon/ - in
>>>>> digester/ - in
>>>>> email/ - in
>>>>> exec/ - in
>>>>> functor/ - in
>>>>> jci/ - in
>>>>> jcs/ - in
>>>>> jelly/ - in
>>>>> jexl/ - in
>>>>> jxpath/ - in
>>>>> logging/ - in (ugh)
>>>>> net/ - in (ugh)
>>>>
>>>> What does (ugh) mean ?
>>>
>>> Pardon me there. I wish to retract my opinions over the antiquity of these
>>> components. :-)
>>>
>>> -Rob
>>>
>>>>
>>>>> ognl/ - in
>>>>> proxy/ - out
>>>>> validator/ - in
>>>>> vfs/ - in
>>>>> weaver/ - already done.
>>>>>
>>>>> Note. My audit was clearly incomplete as @MattBenson noticed that
>>> weaver was already done. Please edit the list as you see fit, and then I
>>> will try to take what we have with our previous [VOTE] to INFRA for
>>> migration. If they want us to be more explicit about our desires, then I
>>> will come back with an explicit proposal as opposed to the general one [2].
>>>>>
>>>>> Also pardon if this seems overly officious, I’m just trying to adhere
>>> to the apache rules as best I can.
>>>>>
>>>>> Cheers,
>>>>> -Rob
>>>>>
>>>>> [1] https://markmail.org/message/eevorsittlor3sez <
>>> https://markmail.org/message/eevorsittlor3sez>
>>>>> [2] https://markmail.org/message/5cqs3zxrr6dadj3n <
>>> https://markmail.org/message/5cqs3zxrr6dadj3n>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
