On 2/26/25 5:43 PM, Jim Jagielski wrote:
>
>
>> On Feb 10, 2025, at 10:22 AM, Ruediger Pluem <rpl...@apache.org> wrote:
>>
>>
>>
>> On 1/29/25 12:48 PM, Jim Jagielski wrote:
>>>
>>>
>>>> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem <rpl...@apache.org> wrote:
>>>>
>>>>
>>>>
>>>> On 1/27/25 1:35 PM, Jim Jagielski wrote:
>>>>> Now that we have a release out, which gives us, hopefully, some breathing
>>>>> room, should we migrate over to git in earnest? Or
>>>>> maybe, at least, document a series of tasks required to do so that we
>>>>> _can_ migrate?
>>>>
>>>> Eric already started a confluence page for this:
>>>>
>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311628229
>>>>
>>>
>>> Thanks! So far the page sez:
>>>
>>>
>>> Items needed day zero
>>>
>>> 1. ???
>>
>> I added some comments on the page. Some of the points below on the page are
>> IMHO needed by day zero. The release scripts could be
>> developed while we are still on svn in a branch. Hence we would still be
>> able to do a fast release once we switched to git which
>> seems important in case of a need for an emergency release.
>>
>
> I posted this on the wiki. An alternative might be to move all the support
> repos "officially" to git, which would allow them to be
> worked on...
I think this is not required in the first place, but we could do this. Although
there is currently no branches directory below
https://svn.apache.org/viewvc/httpd/dev-tools/release/ or
https://svn.apache.org/viewvc/httpd/dev-tools/ I guess we could create
one and branch the code there. From my point of view this is entirely in the
hand of the person who wants to start working on this
and I am fine with either way.
>
> I am just unsure how much we can do to handle the move to git without the
> source code actually, canonically, being on git (if you
> get my meaning :) )
Just a quick idea:
1. Branch the current dev-tools (either after moving them to git or on svn) and
start switching the code to git.
2. Keep the code easily configurable with regards to the git repo location.
This allows to test the scripts against forks of
https://github.com/apache/httpd where people can do as much "test" release
as they want to to test the new scripts without
the need for the canonical code repository to switch to git before and
screwing up something for others. If you screwed up
the fork you can easily remove it and create a new one.
Regards
Rüdiger
