Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Graham Leggett via dev]

On 25 Apr 2023, at 07:45, Ruediger Pluem  wrote:

> 2. Switching from Subversion to Git is mostly an emotional problem for me. We 
> have some closer ties to Subversion by some
>   overlaps in the community and via mod_dav_svn we kind of partially eat our 
> very own dogfood here by using Subversion.
>   We wouldn't do that any longer with Git. Plus it would switch another of 
> our development tools from an Apache license to GPL.
>   Apart from technical aspects that this change would create we should check 
> if all of the current active committers are fine
>   using Github. While people could use Gitbox and thus avoid Github when we 
> use Git I would like us to leverage the features of
>   Github when we would do this switch and I think this cannot be done if 
> active committers would have issues with Github.

+1.

I've always found the fight about “must be git” to be really tedious. Github 
supports both git and svn to this day, and people are free to use what they 
prefer by using the interface they are most familiar with.

While Github is popular today, this is only because the goals of the owners of 
Github are presently aligned with our goals. As Twitter has taught us, goals 
change at any time and without warning.

Regards,
Graham
—

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Joe Schaefer]

Get over the heartache and brand loyalty and get on rw git.  Github isn't
the only game in town anymore for git hosting, so don't feel trapped by
infra just because it's all they've got in the tank.

On Tue, Apr 25, 2023 at 2:07 PM Eric Covener  wrote:

> On Tue, Apr 25, 2023 at 2:45 AM Ruediger Pluem  wrote:
> >
> >
> >
> > On 4/12/23 2:02 PM, Yann Ylavic wrote:
> > > On Wed, Apr 12, 2023 at 1:31 PM Eric Covener 
> wrote:
> > >>
> > >> On Wed, Apr 12, 2023 at 6:36 AM Yann Ylavic 
> wrote:
> > >>>
> > >>> On Wed, Apr 12, 2023 at 12:26 PM Yann Ylavic 
> wrote:
> > 
> >  On Wed, Apr 12, 2023 at 12:18 PM ylavic 
> wrote:
> > >
> > > @ylavic approved this pull request.
> > >
> > > Three approvals to get ci started?
> > 
> >  Nope.. It seems that gh actions don't run for PRs whatever we do.
> >  The docs[1] say that there should be an "Approve and run" button
> near
> >  the "workflow awaiting approval" text, but it's not the case for
> httpd
> >  mirror, while approving the whole PR looks inefficient..
> > >>>
> > >>> We (PMC/committers) once had the right to close any PRs, but that
> > >>> seems to not be the case anymore either.
> > >>> Something changed since
> > >>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> > >>> probably.
> > >>>
> > 
> >  Any more ideas? Help from infra needed?
> > 
> >  Regards;
> >  Yann.
> > 
> >  [1]
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
> > >>
> > >>
> > >> We are chatting with Daniel about it on ASF slack.
> > >
> > > Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457
> FWIW..
> > >
> >
> > I would like to bring this back here, now that we have an answer in the
> ticket.
> > The root cause for the current situation seems to be that our Github
> repository is just a read only mirror of our Subversion
> > repository. Approving PR's requires write permissions to the Github
> repository.
> >
> > As far as I understand from the ticket we have two options:
> >
> > 1. We establish a monitoring process on PR's that ensures that we detect
> misuse of Github actions by non committers.
> >Then Infra could set the PR's back to "auto-approval".
> >
> > 2. We switch from Subversion to Git and use Git as our read / write main
> repository.
> >
> > My 2 cents on the options:
> >
> > 1. I am not sure which exact monitoring will be sufficient, but it may
> put some larger burden on us to ensure that we
> >detect misuse in a timely manner. Furthermore the question to me will
> be what we can do to stop misuse quickly if we
> >detect it.
> >
> > 2. Switching from Subversion to Git is mostly an emotional problem for
> me. We have some closer ties to Subversion by some
> >overlaps in the community and via mod_dav_svn we kind of partially
> eat our very own dogfood here by using Subversion.
> >We wouldn't do that any longer with Git. Plus it would switch another
> of our development tools from an Apache license to GPL.
> >Apart from technical aspects that this change would create we should
> check if all of the current active committers are fine
> >using Github. While people could use Gitbox and thus avoid Github
> when we use Git I would like us to leverage the features of
> >Github when we would do this switch and I think this cannot be done
> if active committers would have issues with Github.
>
>
> I think r/w github is the way to go, but I know from previous threads
> there are strong feelings against it.
> Right now we seem to not be optimized for either maintainers or
> contributors, it's just inertia. I think it's bad for our image.
>

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Eric Covener]

On Tue, Apr 25, 2023 at 2:45 AM Ruediger Pluem  wrote:
>
>
>
> On 4/12/23 2:02 PM, Yann Ylavic wrote:
> > On Wed, Apr 12, 2023 at 1:31 PM Eric Covener  wrote:
> >>
> >> On Wed, Apr 12, 2023 at 6:36 AM Yann Ylavic  wrote:
> >>>
> >>> On Wed, Apr 12, 2023 at 12:26 PM Yann Ylavic  wrote:
> 
>  On Wed, Apr 12, 2023 at 12:18 PM ylavic  wrote:
> >
> > @ylavic approved this pull request.
> >
> > Three approvals to get ci started?
> 
>  Nope.. It seems that gh actions don't run for PRs whatever we do.
>  The docs[1] say that there should be an "Approve and run" button near
>  the "workflow awaiting approval" text, but it's not the case for httpd
>  mirror, while approving the whole PR looks inefficient..
> >>>
> >>> We (PMC/committers) once had the right to close any PRs, but that
> >>> seems to not be the case anymore either.
> >>> Something changed since
> >>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> >>> probably.
> >>>
> 
>  Any more ideas? Help from infra needed?
> 
>  Regards;
>  Yann.
> 
>  [1] 
>  https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
> >>
> >>
> >> We are chatting with Daniel about it on ASF slack.
> >
> > Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457 FWIW..
> >
>
> I would like to bring this back here, now that we have an answer in the 
> ticket.
> The root cause for the current situation seems to be that our Github 
> repository is just a read only mirror of our Subversion
> repository. Approving PR's requires write permissions to the Github 
> repository.
>
> As far as I understand from the ticket we have two options:
>
> 1. We establish a monitoring process on PR's that ensures that we detect 
> misuse of Github actions by non committers.
>Then Infra could set the PR's back to "auto-approval".
>
> 2. We switch from Subversion to Git and use Git as our read / write main 
> repository.
>
> My 2 cents on the options:
>
> 1. I am not sure which exact monitoring will be sufficient, but it may put 
> some larger burden on us to ensure that we
>detect misuse in a timely manner. Furthermore the question to me will be 
> what we can do to stop misuse quickly if we
>detect it.
>
> 2. Switching from Subversion to Git is mostly an emotional problem for me. We 
> have some closer ties to Subversion by some
>overlaps in the community and via mod_dav_svn we kind of partially eat our 
> very own dogfood here by using Subversion.
>We wouldn't do that any longer with Git. Plus it would switch another of 
> our development tools from an Apache license to GPL.
>Apart from technical aspects that this change would create we should check 
> if all of the current active committers are fine
>using Github. While people could use Gitbox and thus avoid Github when we 
> use Git I would like us to leverage the features of
>Github when we would do this switch and I think this cannot be done if 
> active committers would have issues with Github.


I think r/w github is the way to go, but I know from previous threads
there are strong feelings against it.
Right now we seem to not be optimized for either maintainers or
contributors, it's just inertia. I think it's bad for our image.

Re: [Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

[Graham Leggett via dev]

On 19 Mar 2020, at 12:26, Graham Leggett  wrote:On 19 Mar 2020, at 02:40, Eric Covener  wrote:Neat, have you thought about mod_auth_form in relation to this?Something on my wishlist has been to not put the password in thesession / not continue to call the original auth provider.Yes - the two modules that will benefit from token support are mod_session (which mod_auth_form is just one possible “onramp” to obtain a session token), and mod_ssl, where the token is the cert.Getting back to this.Added in r1909409 and r1909411.There is a corresponding library for tomcat that allows it to receive bearer auth here: https://github.com/minfrin/tomcat-jwt-authenticatorRegards,Graham—

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Ruediger Pluem]

On 4/12/23 2:02 PM, Yann Ylavic wrote:
> On Wed, Apr 12, 2023 at 1:31 PM Eric Covener  wrote:
>>
>> On Wed, Apr 12, 2023 at 6:36 AM Yann Ylavic  wrote:
>>>
>>> On Wed, Apr 12, 2023 at 12:26 PM Yann Ylavic  wrote:

 On Wed, Apr 12, 2023 at 12:18 PM ylavic  wrote:
>
> @ylavic approved this pull request.
>
> Three approvals to get ci started?

 Nope.. It seems that gh actions don't run for PRs whatever we do.
 The docs[1] say that there should be an "Approve and run" button near
 the "workflow awaiting approval" text, but it's not the case for httpd
 mirror, while approving the whole PR looks inefficient..
>>>
>>> We (PMC/committers) once had the right to close any PRs, but that
>>> seems to not be the case anymore either.
>>> Something changed since
>>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
>>> probably.
>>>

 Any more ideas? Help from infra needed?

 Regards;
 Yann.

 [1] 
 https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
>>
>>
>> We are chatting with Daniel about it on ASF slack.
> 
> Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457 FWIW..
> 

I would like to bring this back here, now that we have an answer in the ticket.
The root cause for the current situation seems to be that our Github repository 
is just a read only mirror of our Subversion
repository. Approving PR's requires write permissions to the Github repository.

As far as I understand from the ticket we have two options:

1. We establish a monitoring process on PR's that ensures that we detect misuse 
of Github actions by non committers.
   Then Infra could set the PR's back to "auto-approval".

2. We switch from Subversion to Git and use Git as our read / write main 
repository.

My 2 cents on the options:

1. I am not sure which exact monitoring will be sufficient, but it may put some 
larger burden on us to ensure that we
   detect misuse in a timely manner. Furthermore the question to me will be 
what we can do to stop misuse quickly if we
   detect it.

2. Switching from Subversion to Git is mostly an emotional problem for me. We 
have some closer ties to Subversion by some
   overlaps in the community and via mod_dav_svn we kind of partially eat our 
very own dogfood here by using Subversion.
   We wouldn't do that any longer with Git. Plus it would switch another of our 
development tools from an Apache license to GPL.
   Apart from technical aspects that this change would create we should check 
if all of the current active committers are fine
   using Github. While people could use Gitbox and thus avoid Github when we 
use Git I would like us to leverage the features of
   Github when we would do this switch and I think this cannot be done if 
active committers would have issues with Github.


Regards

Rüdiger