Mailing List Archive

On 2/16/24 2:10 PM, Eric Covener wrote:
>> Will apreq 2.18 still be released?
>
> I think we should, but we need someone to do the release work and 3
> active PMC members to approve it. Prior to the recent activity, the
> subproject was essentially unchanged and unreleased for 10 years (with
> 1 failed release due to lack of votes)
>
> I would like to understand if libapreq remains viable as a project
> managed by the httpd PMC. We had this conversation last year on the
> private list and the next step is to bring it here.

I reread the thread on the private list. Did the discussed reach out to other
PMC's happen?

>
> It is possible the next release comes with an end-of-life date in the
> future. If this codebase has a community elsewhere, they should join
> us or take it over.If there is anyone out there who wants to get more
> involved, please speak up.
>
>
> I count myself as a release vote of last resort only, but i don't
> think we should be committing to future fixes/releases if nearly
> everyone is in this category.

I am in that category as well.
I don't have time in the foreseeable future to evaluate if its worth keeping at least parts of it in trunk to be used for the
locations in httpd where we parse form data (there are some). I guess it could be beneficial to have this capability in a central
location.
OTOH looking in what we have in trunk I am a bit confused. The trunk code does not seem to have the perl
glue any longer that is present in the standalone code. Did it go somewhere else back then? How
would perl users continue to use it even if we would release trunk today and would close down the
standalone apreq with a terminal release today?

I would be trying to help with a vote on a terminal release by this PMC if no one else wants to take over the code base as is,
but we should clearly retire it then.
As we discussed back then I am not sure if it will be possible to move it into the Attic or
if there is some other way. In the worst case we just note it at https://httpd.apache.org/apreq/
As far as I can tell there is no offer to download it from our downloads page. Hence even today
people need to go to https://dlcdn.apache.org/httpd/libapreq/ directly.

Regards

Rüdiger

On Fri, Feb 16, 2024 at 9:22?AM Ruediger Pluem <rpluem@apache.org> wrote:
>
>
>
> On 2/16/24 2:10 PM, Eric Covener wrote:
> >> Will apreq 2.18 still be released?
> >
> > I think we should, but we need someone to do the release work and 3
> > active PMC members to approve it. Prior to the recent activity, the
> > subproject was essentially unchanged and unreleased for 10 years (with
> > 1 failed release due to lack of votes)
> >
> > I would like to understand if libapreq remains viable as a project
> > managed by the httpd PMC. We had this conversation last year on the
> > private list and the next step is to bring it here.
>
> I reread the thread on the private list. Did the discussed reach out to other
> PMC's happen?

I don't think so, we just had Steve looped in from mod_perl.

> As we discussed back then I am not sure if it will be possible to move it into the Attic or
> if there is some other way. In the worst case we just note it at https://httpd.apache.org/apreq/

I later read the full attic process would not be possible, it was
specifically discussed in some thread that it is n/a for subprojects.
I think we'd just annnounce and add a README if this is the result.

On Fri, Feb 16, 2024 at 08:10:57AM -0500, Eric Covener wrote:
> I count myself as a release vote of last resort only, but i don't
> think we should be committing to future fixes/releases if nearly
> everyone is in this category.

Thanks for raising it here, Eric. Same for me.

Regards, Joe

On Fri, Feb 16, 2024, 16:21 Ruediger Pluem <rpluem@apache.org> wrote:

>
>
> On 2/16/24 2:10 PM, Eric Covener wrote:
> >> Will apreq 2.18 still be released?
> >
> > I think we should, but we need someone to do the release work and 3
> > active PMC members to approve it. Prior to the recent activity, the
> > subproject was essentially unchanged and unreleased for 10 years (with
> > 1 failed release due to lack of votes)
> >
> > I would like to understand if libapreq remains viable as a project
> > managed by the httpd PMC. We had this conversation last year on the
> > private list and the next step is to bring it here.
>
> I reread the thread on the private list. Did the discussed reach out to
> other
> PMC's happen?
>
> >
> > It is possible the next release comes with an end-of-life date in the
> > future. If this codebase has a community elsewhere, they should join
> > us or take it over.If there is anyone out there who wants to get more
> > involved, please speak up.
> >
> >
> > I count myself as a release vote of last resort only, but i don't
> > think we should be committing to future fixes/releases if nearly
> > everyone is in this category.
>
> I am in that category as well.
> I don't have time in the foreseeable future to evaluate if its worth
> keeping at least parts of it in trunk to be used for the
> locations in httpd where we parse form data (there are some). I guess it
> could be beneficial to have this capability in a central
> location.
> OTOH looking in what we have in trunk I am a bit confused. The trunk code
> does not seem to have the perl
> glue any longer that is present in the standalone code. Did it go
> somewhere else back then? How
> would perl users continue to use it even if we would release trunk today
> and would close down the
> standalone apreq with a terminal release today?
>
> I would be trying to help with a vote on a terminal release by this PMC if
> no one else wants to take over the code base as is,
> but we should clearly retire it then.
>

+1 to letting it RIP (maybe with a note inviting future contributors should
there ever be interest in picking it up)

There just aren't enough active community members around it anymore IMHO.

Issac

On Fri, Feb 16, 2024 at 2:11?PM Eric Covener <covener@gmail.com> wrote:
>
> I count myself as a release vote of last resort only, but i don't
> think we should be committing to future fixes/releases if nearly
> everyone is in this category.

+1, since I know the code I can eventually look at or propose patches
after the last release (if needed, possibly in a patches/ directory or
so), but I'm not willing to engage more than that by myself.


Regards;
Yann.

On Tue, 20 Feb 2024 at 09:51, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Fri, Feb 16, 2024 at 2:11?PM Eric Covener <covener@gmail.com> wrote:
> >
> > I count myself as a release vote of last resort only, but i don't
> > think we should be committing to future fixes/releases if nearly
> > everyone is in this category.
>
> +1, since I know the code I can eventually look at or propose patches
> after the last release (if needed, possibly in a patches/ directory or
> so), but I'm not willing to engage more than that by myself.
>

I've made releases before and can do so again and/or vote on releases,
but I've never done much coding in this area and wouldn't be confident
of doing much in the future either.

> If there is anyone out there who wants to get more
> involved, please speak up.



I’m interested in getting involved, but am unsure where to start. As an
introduction, I come from application layer development with languages like
Python and a general understanding and familiarity with C toolchain.

Will