Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On 5/5/23 2:37 AM, Greg Stein wrote: > Down-thread, Giovanni asks about security patch handling. We can continue to > use repos/private/pmc/httpd/ for that. That area will > not go away. If people want to go "all git", then Infra can provide projects > with a single, private repository that would function > similarly. Thanks for pointing this out. I think the repos/private/pmc/httpd should still stick in Subversion as it is now. And it brings up another point: We need to adjust our release scripts once we made a switch. > > IMO, I definitely think svn is a superior version control system to git. It > is much more approachable and easy to use, compared to > git. I helped to build svn, yet I use git daily; this isn't knee-jerk svn > partisanship; svn is simply better/easier. But *GitHub* And I still use it in other areas at $work that are not that much development driven but need to version control mostly text files and where the GitHub features are not needed / useful. For these cases svn is clearly much better suited than git. Regards Rüdiger
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On Tue, Apr 25, 2023 at 1:45 AM 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. > Today 0% of httpd developers can use those features of GitHub. Switching allows (say:) 90% of our developers, and potentially some downstream developers and users who are familiar with "how to work with upstream code providers, who use GitHub". Stick with 0%, or go with "more than 0%" ? As noted elsewhere, the GitHub Subversion support has been *sunsetted* and will go away. That should be kept in mind. People will not be able to stick to their svn client, whether readonly or read/write. JoeS notes elsewhere that the git support provided by Infra is strongly-linked to GitHub. From the Foundation's standpoint, the amount of utility is provided is vastly higher than any business risk associated with GitHub going dark or pulling their support for our Foundation. We have all our data, all the provenance, and everything we need, should that day ever arise. But it should not concern anybody in the community to create a reliance/dependency upon GitHub. Down-thread, Giovanni asks about security patch handling. We can continue to use repos/private/pmc/httpd/ for that. That area will not go away. If people want to go "all git", then Infra can provide projects with a single, private repository that would function similarly. IMO, I definitely think svn is a superior version control system to git. It is much more approachable and easy to use, compared to git. I helped to build svn, yet I use git daily; this isn't knee-jerk svn partisanship; svn is simply better/easier. But *GitHub* is a fabulous tool. I will take the inferior VCS in order to access the GitHub feature set. It is unfortunate that such a site never got built for svn, but it is what it is. GitHub > svn > git. Cheers, -g
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On Wed, May 03, 2023 at 02:31:35PM -0500, Daniel Gruno wrote: > I am +1 on moving. I do not have any particular love for git or svn on their > own, and I realize that the proposed change does make outside contributions > and certain workflows easier. +1 for the same reasons here. Might be better to call a formal VOTE thread on this with a clearer Subject.
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On 5/3/23 23:03, Christophe JAILLET wrote: Le 03/05/2023 à 21:12, Eric Covener a écrit : On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev wrote: 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. Hi Graham -- it's a little unclear to me where this would put you "vote" wise about moving to read/write Git. Anyone else with a stake have an opinion? It has been since about 2019 since we last discussed it here, I am hoping people have warmed up to it. svn or git both fit my needs. git would be slightly easier for me because of the feature to easily commit only parts of changes of files (I think that some svn clients also support it, but not the one I use) github is great because it can be used for code review without the need to commit something. A patch can be discussed, updated, improved, ... cleanly before being merged. That's a great feature IMHO. git/github would also make the project more attractive for others contributions I think. So, even if I personality really don't care for myself, I would +1 the sake of the project. +1 for me to switch to git, code review will be easier. Just a question, how will security diffs be managed in Github ? Giovanni Just my 2c, CJ OpenPGP_signature Description: OpenPGP digital signature
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
4.05.2023 10:25 tarihinde Stefan Eissing via dev yazdı: Am 03.05.2023 um 23:03 schrieb Christophe JAILLET : Le 03/05/2023 à 21:12, Eric Covener a écrit : On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev wrote: 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. Hi Graham -- it's a little unclear to me where this would put you "vote" wise about moving to read/write Git. Anyone else with a stake have an opinion? It has been since about 2019 since we last discussed it here, I am hoping people have warmed up to it. svn or git both fit my needs. git would be slightly easier for me because of the feature to easily commit only parts of changes of files (I think that some svn clients also support it, but not the one I use) github is great because it can be used for code review without the need to commit something. A patch can be discussed, updated, improved, ... cleanly before being merged. That's a great feature IMHO. git/github would also make the project more attractive for others contributions I think. So, even if I personality really don't care for myself, I would +1 the sake of the project. Many +1s Just my 2c, CJ Svn to git +1
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
> Am 03.05.2023 um 23:03 schrieb Christophe JAILLET > : > > Le 03/05/2023 à 21:12, Eric Covener a écrit : >> On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev >> wrote: >>> >>> 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. >> Hi Graham -- it's a little unclear to me where this would put you >> "vote" wise about moving to read/write Git. >> Anyone else with a stake have an opinion? It has been since about 2019 >> since we last discussed it here, I am hoping people have warmed up to >> it. > > svn or git both fit my needs. > > git would be slightly easier for me because of the feature to easily commit > only parts of changes of files (I think that some svn clients also support > it, but not the one I use) > > github is great because it can be used for code review without the need to > commit something. A patch can be discussed, updated, improved, ... cleanly > before being merged. That's a great feature IMHO. > > git/github would also make the project more attractive for others > contributions I think. > > So, even if I personality really don't care for myself, I would +1 the sake > of the project. Many +1s > > Just my 2c, > > CJ
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
Le 03/05/2023 à 21:12, Eric Covener a écrit : On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev wrote: 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. Hi Graham -- it's a little unclear to me where this would put you "vote" wise about moving to read/write Git. Anyone else with a stake have an opinion? It has been since about 2019 since we last discussed it here, I am hoping people have warmed up to it. svn or git both fit my needs. git would be slightly easier for me because of the feature to easily commit only parts of changes of files (I think that some svn clients also support it, but not the one I use) github is great because it can be used for code review without the need to commit something. A patch can be discussed, updated, improved, ... cleanly before being merged. That's a great feature IMHO. git/github would also make the project more attractive for others contributions I think. So, even if I personality really don't care for myself, I would +1 the sake of the project. Just my 2c, CJ
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On 2023-05-03 14:12, Eric Covener wrote: On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev wrote: 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. Hi Graham -- it's a little unclear to me where this would put you "vote" wise about moving to read/write Git. Anyone else with a stake have an opinion? It has been since about 2019 since we last discussed it here, I am hoping people have warmed up to it. I am +1 on moving. I do not have any particular love for git or svn on their own, and I realize that the proposed change does make outside contributions and certain workflows easier.
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev wrote: > > 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. Hi Graham -- it's a little unclear to me where this would put you "vote" wise about moving to read/write Git. Anyone else with a stake have an opinion? It has been since about 2019 since we last discussed it here, I am hoping people have warmed up to it.
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
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))
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))
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))
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
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
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.. Regards; Yann.
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
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. -- Eric Covener cove...@gmail.com
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On 4/12/23 12:35 PM, 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. I guess we need help from infra. Is it possible that we cannot do all this because our git repository is just a readonly mirror of the Subversion repository and hence none of us is a maintainer of this repository? Regards Rüdiger >
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
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
ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
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.. 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
