You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jagunet.com> on 2024/12/13 14:16:43 UTC
httpd 2.4 -> next
Hi All!
Come '25 I'll have some cycles to get back into some serious httpd work, and am looking to find out what our next steps are. I've followed along the lists but have really not been active. Do we have a plan forward, past httpd-2.4? I'd like to see what areas I could look into to help us drive forward. Some things that I want to do is reboot my work on various proxy enhancements, including auto discovery and balancer metrics.
Some considerations and potential topics of discussion:
1. On trunk, baseline something newer than c89
2. Update the autoconf suite
3. future roadmap
Basically the question is: Is httpd basically in maintenance mode or do we want to try to get some momentum going?
Cheers
--
Jim
"If you can dodge a wrench, you can dodge a ball."
Re: httpd 2.4 -> next
Posted by Jim Jagielski <ji...@jagunet.com>.
> On Dec 18, 2024, at 9:50 AM, Joe Orton <jo...@redhat.com> wrote:
>
> Moving to C11 could be interesting, also requiring a OpenSSL 3+
> baseline?
>
Plus it would provide some features that we depend on APR currently, such as long long* and atomics.
* long long is actually in C99
--
Jim
"If you can dodge a wrench, you can dodge a ball."
Re: httpd 2.4 -> next
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Dec 13, 2024 at 09:16:43AM -0500, Jim Jagielski wrote:
> Hi All!
>
> Come '25 I'll have some cycles to get back into some serious httpd
> work, and am looking to find out what our next steps are. I've
> followed along the lists but have really not been active. Do we have a
> plan forward, past httpd-2.4? I'd like to see what areas I could look
> into to help us drive forward. Some things that I want to do is reboot
> my work on various proxy enhancements, including auto discovery and
> balancer metrics.
Nice! I've been quite short on time the last few months with various
work distractions as well. From my side, I'd like to see a 2.5.x release
series to prepare for 2.6, there are various trunk improvements which
are hard/impossible to backport to 2.4.x and it would be good to get
them out there.
> Some considerations and potential topics of discussion:
>
> 1. On trunk, baseline something newer than c89
> 2. Update the autoconf suite
> 3. future roadmap
Moving to C11 could be interesting, also requiring a OpenSSL 3+
baseline?
Regards, Joe
Re: httpd 2.4 -> next
Posted by Nick Edwards <ni...@gmail.com>.
On Sat, Dec 14, 2024 at 7:13 AM Eric Covener <co...@gmail.com> wrote:
>
>
> but is there something we can do on top of pingora (the rust
> cloudflare library-ish thing) that makes it easier for people who like
oh hell no... let's stay away from rust, it's worse than systemd (and I
never thought that possible)
rust libs from today are not compat with rust of 12 to 18 months ago,
forcing the OS maintainer to manually force and install of latest rust,
often b source, over riding the distro. now that might be fine for home
geeks, but thats never going to happen in a server environment like ASP's,
ISP's big corporates, governments other ngo's.
One example, we are using an outdated particular software engine because
although the OS is not even 2 years old, its rust major/minor is not compat
with current engine, and I'll out them, Cisco, recently told us "go update
rust", really???? 207 machines or 7, about that, nahhh not gonna happen,
we'll find a replacement.
So unless you are prepared to release new majors (2.8) 2 years later, (3.0)
2 years after that and so on, for gods sake, forget rust.
It is aptly named, because rust should be left to rust away to a crumbling
pile of ....
Merry Christmas y'all
Re: httpd 2.4 -> next
Posted by Jim Jagielski <ji...@jagunet.com>.
> On Dec 16, 2024, at 3:12 AM, Ruediger Pluem <rp...@apache.org> wrote:
>
>
>
> On 12/14/24 10:05 AM, Thomas Meyer wrote:
>>
>>
>> Am 13. Dezember 2024 22:12:56 MEZ schrieb Eric Covener <co...@gmail.com>:
>>> On Fri, Dec 13, 2024 at 9:17 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>>>
>>>> Hi All!
>>>>
>>>> Come '25 I'll have some cycles to get back into some serious httpd work, and am looking to find out what our next steps are. I've followed along the lists but have really not been active. Do we have a plan forward, past httpd-2.4? I'd like to see what areas I could look into to help us drive forward. Some things that I want to do is reboot my work on various proxy enhancements, including auto discovery and balancer metrics.
>>>>
>>>> Some considerations and potential topics of discussion:
>>>>
>>>> 1. On trunk, baseline something newer than c89
>>>> 2. Update the autoconf suite
>>>> 3. future roadmap
>>>>
>>>> Basically the question is: Is httpd basically in maintenance mode or do we want to try to get some momentum going?
>>
>> The project seems to be basically dead from my experience.
>
> I disagree that it is dead, but I admit that is has very low activity currently and since quite some time.
>
>>
>>>
>>> Other than the obvious shortage of contributors, I think one big
>>
>> As someone who has tried to get a patch merged for over one year now, my experience is a bit different. Only a few people seem to react on pull requests or mailing list at all, look at all the open GitHub PRs, that are open since month.
>>
>> There may be a lack of contributors but there seems to be even a greater lack of maintainers and their time :-(
>
> I am sorry about this and I am somewhat guilty to it as well. But as you and others already pointed out it is mainly a lack of
> time resources which affects me as well. I think none of us doing the development here is currently full time dedicated to this
> project and hence our main focus is to "keep the lights on" and then spend the remaining time on the things that itches us most.
>
>>
>>> dilemma is that a post-2.4 needs to thread such a tiny needle where
>>> it's both similar enough for people to be able to move to it (skills,
>>> compat, migration wise), but different enough to justify the extra
>>> effort on both sides.
>>>
>>> There's also the baggage of httpd and C. While individually this might
>>> be a strength to you and I (and any other long-time contributors), I
>>> don't think it is for prospective contributors, possible
>>> sponsors/partners, or users.
>>>
>>> I only follow developments in other servers at a very cursory level,
>>> but is there something we can do on top of pingora (the rust
>>> cloudflare library-ish thing) that makes it easier for people who like
>>> httpd to adopt for example?
>>
>
> I am not sure if writing things in Rust would attract that much more developers.
> I think our own Rust experience with mod_tls and rustls is a bit mixed and we
> hit the issue with frequent API changes on the Rust side or more specifically on the
> rustls side as mentioned in other posts to this thread.
>
I am also unsure the value of a language change at this point, and especially how many current developers are savvy enough with Rust.
Personally, I think some agreed upon Roadmap might be the more effective route. If people knew the direction we are going, and that we are kind of committed to that direction, then potential contributors would be more apt to join, if they knew that they were joining a project with a future.
--
Jim
"If you can dodge a wrench, you can dodge a ball."
Re: httpd 2.4 -> next
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/14/24 10:05 AM, Thomas Meyer wrote:
>
>
> Am 13. Dezember 2024 22:12:56 MEZ schrieb Eric Covener <co...@gmail.com>:
>> On Fri, Dec 13, 2024 at 9:17 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>> Hi All!
>>>
>>> Come '25 I'll have some cycles to get back into some serious httpd work, and am looking to find out what our next steps are. I've followed along the lists but have really not been active. Do we have a plan forward, past httpd-2.4? I'd like to see what areas I could look into to help us drive forward. Some things that I want to do is reboot my work on various proxy enhancements, including auto discovery and balancer metrics.
>>>
>>> Some considerations and potential topics of discussion:
>>>
>>> 1. On trunk, baseline something newer than c89
>>> 2. Update the autoconf suite
>>> 3. future roadmap
>>>
>>> Basically the question is: Is httpd basically in maintenance mode or do we want to try to get some momentum going?
>
> The project seems to be basically dead from my experience.
I disagree that it is dead, but I admit that is has very low activity currently and since quite some time.
>
>>
>> Other than the obvious shortage of contributors, I think one big
>
> As someone who has tried to get a patch merged for over one year now, my experience is a bit different. Only a few people seem to react on pull requests or mailing list at all, look at all the open GitHub PRs, that are open since month.
>
> There may be a lack of contributors but there seems to be even a greater lack of maintainers and their time :-(
I am sorry about this and I am somewhat guilty to it as well. But as you and others already pointed out it is mainly a lack of
time resources which affects me as well. I think none of us doing the development here is currently full time dedicated to this
project and hence our main focus is to "keep the lights on" and then spend the remaining time on the things that itches us most.
>
>> dilemma is that a post-2.4 needs to thread such a tiny needle where
>> it's both similar enough for people to be able to move to it (skills,
>> compat, migration wise), but different enough to justify the extra
>> effort on both sides.
>>
>> There's also the baggage of httpd and C. While individually this might
>> be a strength to you and I (and any other long-time contributors), I
>> don't think it is for prospective contributors, possible
>> sponsors/partners, or users.
>>
>> I only follow developments in other servers at a very cursory level,
>> but is there something we can do on top of pingora (the rust
>> cloudflare library-ish thing) that makes it easier for people who like
>> httpd to adopt for example?
>
I am not sure if writing things in Rust would attract that much more developers.
I think our own Rust experience with mod_tls and rustls is a bit mixed and we
hit the issue with frequent API changes on the Rust side or more specifically on the
rustls side as mentioned in other posts to this thread.
Regards
Rüdiger
Re: httpd 2.4 -> next
Posted by Thomas Meyer <th...@m3y3r.de>.
Am 13. Dezember 2024 22:12:56 MEZ schrieb Eric Covener <co...@gmail.com>:
>On Fri, Dec 13, 2024 at 9:17 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> Hi All!
>>
>> Come '25 I'll have some cycles to get back into some serious httpd work, and am looking to find out what our next steps are. I've followed along the lists but have really not been active. Do we have a plan forward, past httpd-2.4? I'd like to see what areas I could look into to help us drive forward. Some things that I want to do is reboot my work on various proxy enhancements, including auto discovery and balancer metrics.
>>
>> Some considerations and potential topics of discussion:
>>
>> 1. On trunk, baseline something newer than c89
>> 2. Update the autoconf suite
>> 3. future roadmap
>>
>> Basically the question is: Is httpd basically in maintenance mode or do we want to try to get some momentum going?
The project seems to be basically dead from my experience.
>
>Other than the obvious shortage of contributors, I think one big
As someone who has tried to get a patch merged for over one year now, my experience is a bit different. Only a few people seem to react on pull requests or mailing list at all, look at all the open GitHub PRs, that are open since month.
There may be a lack of contributors but there seems to be even a greater lack of maintainers and their time :-(
>dilemma is that a post-2.4 needs to thread such a tiny needle where
>it's both similar enough for people to be able to move to it (skills,
>compat, migration wise), but different enough to justify the extra
>effort on both sides.
>
>There's also the baggage of httpd and C. While individually this might
>be a strength to you and I (and any other long-time contributors), I
>don't think it is for prospective contributors, possible
>sponsors/partners, or users.
>
>I only follow developments in other servers at a very cursory level,
>but is there something we can do on top of pingora (the rust
>cloudflare library-ish thing) that makes it easier for people who like
>httpd to adopt for example?
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: httpd 2.4 -> next
Posted by Eric Covener <co...@gmail.com>.
On Fri, Dec 13, 2024 at 9:17 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
> Hi All!
>
> Come '25 I'll have some cycles to get back into some serious httpd work, and am looking to find out what our next steps are. I've followed along the lists but have really not been active. Do we have a plan forward, past httpd-2.4? I'd like to see what areas I could look into to help us drive forward. Some things that I want to do is reboot my work on various proxy enhancements, including auto discovery and balancer metrics.
>
> Some considerations and potential topics of discussion:
>
> 1. On trunk, baseline something newer than c89
> 2. Update the autoconf suite
> 3. future roadmap
>
> Basically the question is: Is httpd basically in maintenance mode or do we want to try to get some momentum going?
Other than the obvious shortage of contributors, I think one big
dilemma is that a post-2.4 needs to thread such a tiny needle where
it's both similar enough for people to be able to move to it (skills,
compat, migration wise), but different enough to justify the extra
effort on both sides.
There's also the baggage of httpd and C. While individually this might
be a strength to you and I (and any other long-time contributors), I
don't think it is for prospective contributors, possible
sponsors/partners, or users.
I only follow developments in other servers at a very cursory level,
but is there something we can do on top of pingora (the rust
cloudflare library-ish thing) that makes it easier for people who like
httpd to adopt for example?
Re: Move to git (Was: Re: httpd 2.4 -> next)
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
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)
Posted by Ruediger Pluem <rp...@apache.org>.
On 2/26/25 5:43 PM, Jim Jagielski wrote:
>
>
>> On Feb 10, 2025, at 10:22 AM, Ruediger Pluem <rp...@apache.org> wrote:
>>
>>
>>
>> On 1/29/25 12:48 PM, Jim Jagielski wrote:
>>>
>>>
>>>> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem <rp...@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
Re: Move to git (Was: Re: httpd 2.4 -> next)
Posted by Jim Jagielski <ji...@jagunet.com>.
> On Feb 10, 2025, at 10:22 AM, Ruediger Pluem <rp...@apache.org> wrote:
>
>
>
> On 1/29/25 12:48 PM, Jim Jagielski wrote:
>>
>>
>>> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem <rp...@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 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)
Posted by Ruediger Pluem <rp...@apache.org>.
On 1/29/25 12:48 PM, Jim Jagielski wrote:
>
>
>> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem <rp...@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.
Regards
Rüdiger
Re: Move to git (Was: Re: httpd 2.4 -> next)
Posted by Jim Jagielski <ji...@jagunet.com>.
> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem <rp...@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
???
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)
Posted by Ruediger Pluem <rp...@apache.org>.
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)
Posted by Jim Jagielski <ji...@jagunet.com>.
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)
Posted by Ruediger Pluem <rp...@apache.org>.
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:
>> <!-- $LastChangedRevision$ -->
>>
>> 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)
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
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:
> <!-- $LastChangedRevision$ -->
>
> 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)
Posted by Eric Covener <co...@gmail.com>.
> 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:
<!-- $LastChangedRevision$ -->
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)
Posted by André Malo <nd...@perlig.de>.
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)
Posted by Jim Jagielski <ji...@jagunet.com>.
> On Dec 18, 2024, at 12:56 PM, Eric Covener <co...@gmail.com> 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)
Posted by Jim Jagielski <ji...@jagunet.com>.
> On Dec 18, 2024, at 2:06 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On Wed, Dec 18, 2024 at 11:57 AM Eric Covener <covener@gmail.com <ma...@gmail.com>> 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)
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Dec 18, 2024 at 11:57 AM Eric Covener <co...@gmail.com> 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)
Posted by Eric Covener <co...@gmail.com>.
> how should we handle "security" pmc-only repo in git workflow ?
> Giovanni
Probably keep it in SVN.
--
Eric Covener
covener@gmail.com
Re: Move to git (Was: Re: httpd 2.4 -> next)
Posted by gi...@paclan.it.
18 dicembre 2024 alle ore 18:56, "Eric Covener" <covener@gmail.com mailto:covener@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)
Posted by Eric Covener <co...@gmail.com>.
> 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)
Posted by Jim Jagielski <ji...@jagunet.com>.
> On Dec 18, 2024, at 12:19 PM, Eric Covener <co...@gmail.com> wrote:
>
> On Wed, Dec 18, 2024 at 11:55 AM Jim Jagielski <ji...@jagunet.com> 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)
Posted by Eric Covener <co...@gmail.com>.
On Wed, Dec 18, 2024 at 11:55 AM Jim Jagielski <ji...@jagunet.com> 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.
Move to git (Was: Re: httpd 2.4 -> next)
Posted by Jim Jagielski <ji...@jagunet.com>.
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?
--
Jim
"If you can dodge a wrench, you can dodge a ball."