Re: Move to git (Was: Re: httpd 2.4 -> next)

[Ruediger Pluem]

On 2/26/25 5:43 PM, Jim Jagielski wrote:
> 
> 
>> On Feb 10, 2025, at 10:22 AM, Ruediger Pluem  wrote:
>>
>>
>>
>> On 1/29/25 12:48 PM, Jim Jagielski wrote:
>>>
>>>
 On Jan 28, 2025, at 2:21 PM, Ruediger Pluem  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

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Jim Jagielski]

> On Feb 10, 2025, at 10:22 AM, Ruediger Pluem  wrote:
> 
> 
> 
> On 1/29/25 12:48 PM, Jim Jagielski wrote:
>> 
>> 
>>> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem  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 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 :) )

--
Jim

 "Grasping the vine with one hand, he plucked the strawberry with the other.
  How sweet it tasted!"

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Ruediger Pluem]

On 1/29/25 12:48 PM, Jim Jagielski wrote:
> 
> 
>> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem  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.

Regards

Rüdiger

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Jim Jagielski]

> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem  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
???

which doesn't mean, of course, that none exist :-)
--
Jim
"I don't need a compass to tell me which way the wind shines."

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Ruediger Pluem]

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

Regards

Rüdiger

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Jim Jagielski]

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?

--
Jim
"I don't need a compass to tell me which way the wind shines."

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Ruediger Pluem]

On 12/19/24 8:19 PM, Christophe JAILLET wrote:
> 
> Le 18/12/2024 à 21:45, Eric Covener a écrit :
>>> The doc translation trackers are based on svn revision numbers. Or at least
>>> used to be, I'm actually not entirely sure about the current state :P
>> Ah yes, thanks! It seems to be via
>> https://svn.apache.org/repos/asf/httpd/docs-build/trunk/lib/metafile.pl
>> and keywords in the XML files:
>> 
>>
>> I wonder if we can get by without baking it in either the XML or the
>> translations and just provide tooling to compare the english and
>> non-english commits?
> 
> 
> I've never looked at it but metefile.pl has some code related to "git-svn or 
> a git checkout from git.apache.org" and tries to deal
> with it.
> So, something may work out-of-the-box?

As far as I can tell in case of running in a local git clone of our readonly 
git mirror it tries to extract the svn revisions from
the git logs that get added by our Subversion to git mirroring mechanism.

Regards

Rüdiger

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Christophe JAILLET]

Le 18/12/2024 à 21:45, Eric Covener a écrit :

The doc translation trackers are based on svn revision numbers. Or at least
used to be, I'm actually not entirely sure about the current state :P

Ah yes, thanks! It seems to be via
https://svn.apache.org/repos/asf/httpd/docs-build/trunk/lib/metafile.pl
and keywords in the XML files:


I wonder if we can get by without baking it in either the XML or the
translations and just provide tooling to compare the english and
non-english commits?



I've never looked at it but metefile.pl has some code related to 
"git-svn or a git checkout from git.apache.org" and tries to deal with it.

So, something may work out-of-the-box?


CJ

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Christophe JAILLET]

Le 18/12/2024 à 21:06, André Malo a écrit :

Eric Covener wrote:

Are the tasks required to do so known? If so, I can take that on.

Maybe something like this for the must-have tasks:

- Get with Infra and see if there are general caveats (open PRs for
example?) for converting from r/o to r/w
- Clean up or save whatever might go missing when we convert
- give warning of the above + the upcoming cutover attempt.
- make svn r/o (infra) && make github r/w (infra)
- Do a final check of contents and history (multiple eyes)
- Test basic PR flow and CI still happy
- Port the release scripts and run a non-security release (there are a
few regression fixes queued up i believe). I can take a crack at this
probably any time in 1Q with just a little notice to sync up.

The doc translation trackers are based on svn revision numbers. Or at least
used to be, I'm actually not entirely sure about the current state :P

Cheers,
André

BTW, the link related to "Good to see what has already been translated 
and whether it's up to date or not." at 
https://httpd.apache.org/docs-project/goingfurther.html is broken since 
http://home.apache.org/ has been deprecated.


I have a copy of the script somewhere on my HD if this functionality 
should be revived somewhere.

The tool was really nice, but I'm not sure it was really (known and) used.


CJ

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Jim Jagielski]

> On Dec 18, 2024, at 2:06 PM, Greg Stein  wrote:
> 
> On Wed, Dec 18, 2024 at 11:57 AM Eric Covener  > wrote:
> >...
>> Maybe something like this for the must-have tasks:
>> 
>> - Get with Infra and see if there are general caveats (open PRs for
>> example?) for converting from r/o to r/w
> 
> The git repository (apache/httpd) just becomes canonical. Nothing needs to 
> change.
>  
>> - Clean up or save whatever might go missing when we convert
> 
> The svn repository will be marked readonly. Nothing will go missing. In fact, 
> the svn repository should stick around for archaeology and historical 
> concerns. The git repository holds ported commits from svn, but it might not 
> be perfect (for archaeology). 
> 
> Also don't forget that our svn repository is actually migrated from CVS. This 
> would be the second migration. (and I have no idea where the origin CVS 
> repository might be, for serious archeology people).
>  
>> - give warning of the above + the upcoming cutover attempt.
>> - make svn r/o (infra) && make github r/w (infra)
> 
> The former is a change to a puppet config file. Well-known for infra. (not 
> gonna link here; it is not a public file) ... I don't recall how svn-mirror 
> github repositories are handled. I think it is simply that they don't have a 
> synchronized repository on gitbox.a.o. Humbedooh would know more here.
> 

The "switch" can be made at any time, and have git become primary... So I just 
need info from us when and I'll update the ticket.


--
Jim
"If you can dodge a wrench, you can dodge a ball."

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Eric Covener]

> how should we handle "security" pmc-only repo in git workflow ?
>  Giovanni

Probably keep it in SVN.

-- 
Eric Covener
cove...@gmail.com

Re: Move to git (Was: Re: httpd 2.4 -> next)

[giovanni]

18 dicembre 2024 alle ore 18:56, "Eric Covener" mailto:cove...@gmail.com?to=%22Eric%20Covener%22%20%3Ccovener%40gmail.com%3E > 
scrive:
> 
> > 
> > Are the tasks required to do so known? If so, I can take that on.
> > 
> I don't think the full tasks (or even requirements) are known.
> 
> I had started a scratchpad here
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311628229
> but didn't get far, the focus was on what was absolutely needed to
> cutover. Maybe it just really isn't that much if we'll continue to
> use external processes for release/bugs/voting etc and we can chip
> away at that stuff later.
> 
> Maybe something like this for the must-have tasks:
> 
> - Get with Infra and see if there are general caveats (open PRs for
> example?) for converting from r/o to r/w
> - Clean up or save whatever might go missing when we convert
> - give warning of the above + the upcoming cutover attempt.
> - make svn r/o (infra) && make github r/w (infra)
> - Do a final check of contents and history (multiple eyes)
> - Test basic PR flow and CI still happy
> - Port the release scripts and run a non-security release (there are a
> few regression fixes queued up i believe). I can take a crack at this
> probably any time in 1Q with just a little notice to sync up.
> 
> Then anything else is just gravy (developer doc, issues vs bugzilla, STATUS)
>

how should we handle "security" pmc-only repo in git workflow ?
 Giovanni

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Eric Covener]

> The doc translation trackers are based on svn revision numbers. Or at least
> used to be, I'm actually not entirely sure about the current state :P

Ah yes, thanks! It seems to be via
https://svn.apache.org/repos/asf/httpd/docs-build/trunk/lib/metafile.pl
and keywords in the XML files:


I wonder if we can get by without baking it in either the XML or the
translations and just provide tooling to compare the english and
non-english commits?

Re: Move to git (Was: Re: httpd 2.4 -> next)

[André Malo]

Eric Covener wrote:
> > Are the tasks required to do so known? If so, I can take that on.
> 
> Maybe something like this for the must-have tasks:
> 
> - Get with Infra and see if there are general caveats (open PRs for
> example?) for converting from r/o to r/w
> - Clean up or save whatever might go missing when we convert
> - give warning of the above + the upcoming cutover attempt.
> - make svn r/o (infra) && make github r/w (infra)
> - Do a final check of contents and history (multiple eyes)
> - Test basic PR flow and CI still happy
> - Port the release scripts and run a non-security release (there are a
> few regression fixes queued up i believe). I can take a crack at this
> probably any time in 1Q with just a little notice to sync up.

The doc translation trackers are based on svn revision numbers. Or at least 
used to be, I'm actually not entirely sure about the current state :P

Cheers,
André

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Greg Stein]

On Wed, Dec 18, 2024 at 11:57 AM Eric Covener  wrote:
>...

> Maybe something like this for the must-have tasks:
>
> - Get with Infra and see if there are general caveats (open PRs for
> example?) for converting from r/o to r/w
>

The git repository (apache/httpd) just becomes canonical. Nothing needs to
change.


> - Clean up or save whatever might go missing when we convert
>

The svn repository will be marked readonly. Nothing will go missing. In
fact, the svn repository should stick around for archaeology and historical
concerns. The git repository holds ported commits from svn, but it might
not be perfect (for archaeology).

Also don't forget that our svn repository is actually migrated from CVS.
This would be the second migration. (and I have no idea where the origin
CVS repository might be, for serious archeology people).


> - give warning of the above + the upcoming cutover attempt.
> - make svn r/o (infra) && make github r/w (infra)
>

The former is a change to a puppet config file. Well-known for infra. (not
gonna link here; it is not a public file) ... I don't recall how svn-mirror
github repositories are handled. I think it is simply that they don't have
a synchronized repository on gitbox.a.o. Humbedooh would know more here.

>...

Cheers,
-g

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Jim Jagielski]

> On Dec 18, 2024, at 12:56 PM, Eric Covener  wrote:
> 
>> Are the tasks required to do so known? If so, I can take that on.
> 
> I don't think the full tasks (or even requirements) are known.
> 
> I had started a scratchpad here
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311628229
> but didn't get far, the focus was on what was absolutely needed to
> cutover.  Maybe it just really isn't that much if we'll continue to
> use external processes for release/bugs/voting etc and we can chip
> away at that stuff later.
> 
> Maybe something like this for the must-have tasks:
> 
> - Get with Infra and see if there are general caveats (open PRs for
> example?) for converting from r/o to r/w
> - Clean up or save whatever might go missing when we convert
> - give warning of the above + the upcoming cutover attempt.
> - make svn r/o (infra) && make github r/w (infra)
> - Do a final check of contents and history (multiple eyes)
> - Test basic PR flow and CI still happy
> - Port the release scripts and run a non-security release (there are a
> few regression fixes queued up i believe). I can take a crack at this
> probably any time in 1Q with just a little notice to sync up.
> 
> Then anything else is just gravy (developer doc, issues vs bugzilla, STATUS)



https://issues.apache.org/jira/browse/INFRA-26379

--
Jim
"If you can dodge a wrench, you can dodge a ball."

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Eric Covener]

> Are the tasks required to do so known? If so, I can take that on.

I don't think the full tasks (or even requirements) are known.

I had started a scratchpad here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311628229
but didn't get far, the focus was on what was absolutely needed to
cutover.  Maybe it just really isn't that much if we'll continue to
use external processes for release/bugs/voting etc and we can chip
away at that stuff later.

Maybe something like this for the must-have tasks:

- Get with Infra and see if there are general caveats (open PRs for
example?) for converting from r/o to r/w
- Clean up or save whatever might go missing when we convert
- give warning of the above + the upcoming cutover attempt.
- make svn r/o (infra) && make github r/w (infra)
- Do a final check of contents and history (multiple eyes)
- Test basic PR flow and CI still happy
- Port the release scripts and run a non-security release (there are a
few regression fixes queued up i believe). I can take a crack at this
probably any time in 1Q with just a little notice to sync up.

Then anything else is just gravy (developer doc, issues vs bugzilla, STATUS)

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Jim Jagielski]

> On Dec 18, 2024, at 12:19 PM, Eric Covener  wrote:
> 
> On Wed, Dec 18, 2024 at 11:55 AM Jim Jagielski  wrote:
>> 
>> 
>> As long as we're thinking future plans, should we discuss making 'git' the 
>> primary version control and more fully embracing a Github-based workflow?
> 
> +1
> 
> We have a passing vote to do it from the last 18 months or so, just
> not tackled yet.


Are the tasks required to do so known? If so, I can take that on.

--
Jim
"If you can dodge a wrench, you can dodge a ball."

Re: Move to git (Was: Re: httpd 2.4 -> next)

[Eric Covener]

On Wed, Dec 18, 2024 at 11:55 AM Jim Jagielski  wrote:
>
>
> As long as we're thinking future plans, should we discuss making 'git' the 
> primary version control and more fully embracing a Github-based workflow?

+1

We have a passing vote to do it from the last 18 months or so, just
not tackled yet.