Re: Releasing with lazy consensus

[Volkan Yazıcı]

I am aware that certain projects follow this [LAZY][VOTE] convention. But I
am not able to read our release policy in such a way to allow that. What I
would appreciate is that somebody pointing me to a certain part of the
policy and explaining the legal room for this [LAZY][VOTE] act.

For the record, the release post you shared still has the following
statement: *"This vote will close no sooner than 72 hours from now"* of
which I am trying to cut down on.

On Fri, Sep 1, 2023 at 8:56 AM Richard Zowalla  wrote:

> The commons project often releases their parent pom with lazy
> consensus, for example:
> https://lists.apache.org/thread/34onls4fw189smx5gjznkk8z80t3j6lc
>
> Am Freitag, dem 01.09.2023 um 08:52 +0200 schrieb Volkan Yazıcı:
> > Is such a thing possible? It is pretty common that many Java projects
> > have
> > multiple modules having their own release cycles. Some of these
> > modules are
> > miscellaneous "utilities" to support the rest of the code base.
> > Common
> > examples I can think of are
> >
> >- BOM project covering a dozen other projects (e.g., `log4j-bom`
> > for
> >`log4j-core`, `log4j-layout-template-json`, etc.)
> >- Utilities (e.g., `log4j-changelog` used to maintain a changelog
> > and
> >release notes for Java-based Logging Services projects)
> >
> > `log4j-core` release takes 72 hours due to voting. Once that is done,
> > waiting another 72 hours for `log4j-bom` feels like a waste of time.
> > Similarly, `log4j-changelog` is an internally used tool, yet we need
> > to
> > publish it to Maven Central and such. Wouldn't it be possible to
> > release
> > such projects (e.g., `log4j-bom`, `log4j-changelog`) with lazy
> > voting? That
> > is, *"unless there are objections within 24 hours, I'll assume a lazy
> > consensus, and release it".* Can the Release Policy
> >  and/or the Voting
> > Process
> >  accommodate such a
> > practice?
>
>

Re: Releasing with lazy consensus

[Jarek Potiuk]

I would love to hear about it, but I believe releasing any software is an
"act of Foundation" and requires 3 explicit PMC members to say "+1" in
order for it to have legal repercussions.

So I am not so sure if releasing "software" of any kind that can be "ASF
software" should be done without voting and 3 PMC members saying +1. In
fact even the roll calls done by the board when the projects are not active
is to check "Is there enough  (3) active PMC members for the PMC to make a
release).

I believe in justified cases however, you can shorten the voting period or
even vote in "secret" and announce the voting later (for example when you
have security release). The process says that there SHOULD be 72 HRs (not
MUST) and if there are good reasons, it can be shortened. But the act of
voting and 3 +1 from the PMC members is - I believe - obligatory.

A comment on how we deal with possibly similar cases in Airflow - where we
often release up to 90(!) packages 2 times a month (!). Maybe that can help
with designing a similar process.

* we allow "bulk" voting. We prepare the "up to 90" provider packages as a
single "pack" of things we vote on. We have automation and tooling that
allows us to both release and verify  (by PMC members) all those packages
together. We also involve the contributors and those who raised relevant
issues in testing those packages (also heavily automated - example issue
generated here https://github.com/apache/airflow/issues/33305  ) - this is
nice because it allows us to streamline the process and release multiple
things together, whil allow individuals to focus on testing all such
packages individually and report it back in that single place where we
discuss the whole "release pack".

* when a bug / release/packaging/sources/problem is found in only one of
those packages (which does not invalidate the rest) the release manager can
decide to withdraw those faulty packages from that release "pack" but this
does not remove +1 votes that were given for the ones that are good.

* after releasing the "good" packages (and parallel fixing of the broken
ones) - the broken ones are released with fixes as RC2 candidates. In most
cases the fixes are really small, so the "user" testing (i.e. what has been
tested and confirmed working so far) status is carried over to the RC2
candidates. The PMC voting for those RC2 is restarted (i.e. we need three
new +1 from the PMC) .  But this time we turn on "accelerated" voting. We
agree to the rule that in this case 24H (and 3 PMC +1s) is enough for the
vote to complete.

* the 72HR -> 24 HR is only done when there are really small and few fixes
since RC1

This has been discussed at the devlist, agreed and captured in our
processes. For those interested:

Discussion about introducing RC2+ accelerated voting :
https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
Lazy consensus on approving it:
https://lists.apache.org/thread/cv194w1fqqykrhswhmm54zy9gnnv6kgm
Example recent vote result where two packages have been excluded due to
bugs but where release manager decided not to accelerate the voting due to
big number of fixes coming since RC1:
https://lists.apache.org/thread/1kovpkx0t2pm2xrwf61ycqdynp0kdl19
Example vote where we had 24 HR accelerated vote:
https://lists.apache.org/thread/ndm71tjdd3mmx7s904ds6sqxy84vb1fw  (BTW We
also had RC3 for google provider as another bug was found in RC2). - those
rules are transitive. RC3 was also accelerated.

I hope it helps.

J.




On Fri, Sep 1, 2023 at 8:53 AM Volkan Yazıcı  wrote:

> Is such a thing possible? It is pretty common that many Java projects have
> multiple modules having their own release cycles. Some of these modules are
> miscellaneous "utilities" to support the rest of the code base. Common
> examples I can think of are
>
>- BOM project covering a dozen other projects (e.g., `log4j-bom` for
>`log4j-core`, `log4j-layout-template-json`, etc.)
>- Utilities (e.g., `log4j-changelog` used to maintain a changelog and
>release notes for Java-based Logging Services projects)
>
> `log4j-core` release takes 72 hours due to voting. Once that is done,
> waiting another 72 hours for `log4j-bom` feels like a waste of time.
> Similarly, `log4j-changelog` is an internally used tool, yet we need to
> publish it to Maven Central and such. Wouldn't it be possible to release
> such projects (e.g., `log4j-bom`, `log4j-changelog`) with lazy voting? That
> is, *"unless there are objections within 24 hours, I'll assume a lazy
> consensus, and release it".* Can the Release Policy
>  and/or the Voting
> Process
>  accommodate such a
> practice?
>

AW: Releasing with lazy consensus

[Christofer Dutz]

Yeah,

thanks for bringing this up … this is actually something I brought up in the 
last board meeting.
I also think it’s not ok to release stuff like parent poms with lazy consensus 
and was currently following up with ASF Legal on that matter.

Just because some projects might be doing it, doesn’t mean it’s ok … possible 
outcome of this might be that this practice will explicitly be forbidden.

My personal reasoning for this:

  *   With a parent pom, I can
 *   Manage dependencies to get in vulnerable versions
 *   Include additional dependencies
 *   Re-Configure plugins configuration
 *   Add plugin executions that might do bad stuff
So I think especially for parent poms we should pay extra attention.

Chris





Von: Jarek Potiuk 
Datum: Freitag, 1. September 2023 um 09:24
An: dev@community.apache.org 
Betreff: Re: Releasing with lazy consensus
I would love to hear about it, but I believe releasing any software is an
"act of Foundation" and requires 3 explicit PMC members to say "+1" in
order for it to have legal repercussions.

So I am not so sure if releasing "software" of any kind that can be "ASF
software" should be done without voting and 3 PMC members saying +1. In
fact even the roll calls done by the board when the projects are not active
is to check "Is there enough  (3) active PMC members for the PMC to make a
release).

I believe in justified cases however, you can shorten the voting period or
even vote in "secret" and announce the voting later (for example when you
have security release). The process says that there SHOULD be 72 HRs (not
MUST) and if there are good reasons, it can be shortened. But the act of
voting and 3 +1 from the PMC members is - I believe - obligatory.

A comment on how we deal with possibly similar cases in Airflow - where we
often release up to 90(!) packages 2 times a month (!). Maybe that can help
with designing a similar process.

* we allow "bulk" voting. We prepare the "up to 90" provider packages as a
single "pack" of things we vote on. We have automation and tooling that
allows us to both release and verify  (by PMC members) all those packages
together. We also involve the contributors and those who raised relevant
issues in testing those packages (also heavily automated - example issue
generated here https://github.com/apache/airflow/issues/33305  ) - this is
nice because it allows us to streamline the process and release multiple
things together, whil allow individuals to focus on testing all such
packages individually and report it back in that single place where we
discuss the whole "release pack".

* when a bug / release/packaging/sources/problem is found in only one of
those packages (which does not invalidate the rest) the release manager can
decide to withdraw those faulty packages from that release "pack" but this
does not remove +1 votes that were given for the ones that are good.

* after releasing the "good" packages (and parallel fixing of the broken
ones) - the broken ones are released with fixes as RC2 candidates. In most
cases the fixes are really small, so the "user" testing (i.e. what has been
tested and confirmed working so far) status is carried over to the RC2
candidates. The PMC voting for those RC2 is restarted (i.e. we need three
new +1 from the PMC) .  But this time we turn on "accelerated" voting. We
agree to the rule that in this case 24H (and 3 PMC +1s) is enough for the
vote to complete.

* the 72HR -> 24 HR is only done when there are really small and few fixes
since RC1

This has been discussed at the devlist, agreed and captured in our
processes. For those interested:

Discussion about introducing RC2+ accelerated voting :
https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
Lazy consensus on approving it:
https://lists.apache.org/thread/cv194w1fqqykrhswhmm54zy9gnnv6kgm
Example recent vote result where two packages have been excluded due to
bugs but where release manager decided not to accelerate the voting due to
big number of fixes coming since RC1:
https://lists.apache.org/thread/1kovpkx0t2pm2xrwf61ycqdynp0kdl19
Example vote where we had 24 HR accelerated vote:
https://lists.apache.org/thread/ndm71tjdd3mmx7s904ds6sqxy84vb1fw  (BTW We
also had RC3 for google provider as another bug was found in RC2). - those
rules are transitive. RC3 was also accelerated.

I hope it helps.

J.




On Fri, Sep 1, 2023 at 8:53 AM Volkan Yazıcı  wrote:

> Is such a thing possible? It is pretty common that many Java projects have
> multiple modules having their own release cycles. Some of these modules are
> miscellaneous "utilities" to support the rest of the code base. Common
> examples I can think of are
>
>- BOM project covering a dozen other projects (e.g., `log4j-bom` for
>`log4j-core`, `log4j-layout-template-json`, etc.)
>- Utilities (e.g., `log4j-changelog` used to maintain a changelog and
>release notes for Java-based Logging Services projects)
>
> `log4j-core` release takes 72 hours due to v

Re: Releasing with lazy consensus

[hans . van . akelyen]

This is a bit of a grey area, so I would love to hear the opinion of others.

From my perspective a vote is only needed when doing a release of the source 
code, all the other things fall under the “convenience binaries/artifacts"
So things like docker images/BOM/packaging based on the source code do not need 
to be voted upon.

We usually combine all these things because if something isn’t working a change 
to the source would be required which would result in a new vote.

There are other things we do which do not require a vote.
We do not vote on documentation/site changes (thy might or might not be linked 
to a release).
A BOM project is not really a mandatory thing to build/use the software so I 
would say just like a website it could fall outside of what you are releasing 
and thus not need a vote….

Kr,
Hans
On 1 Sep 2023 at 09:24 +0200, Jarek Potiuk , wrote:
> I would love to hear about it, but I believe releasing any software is an
> "act of Foundation" and requires 3 explicit PMC members to say "+1" in
> order for it to have legal repercussions.
>
> So I am not so sure if releasing "software" of any kind that can be "ASF
> software" should be done without voting and 3 PMC members saying +1. In
> fact even the roll calls done by the board when the projects are not active
> is to check "Is there enough (3) active PMC members for the PMC to make a
> release).
>
> I believe in justified cases however, you can shorten the voting period or
> even vote in "secret" and announce the voting later (for example when you
> have security release). The process says that there SHOULD be 72 HRs (not
> MUST) and if there are good reasons, it can be shortened. But the act of
> voting and 3 +1 from the PMC members is - I believe - obligatory.
>
> A comment on how we deal with possibly similar cases in Airflow - where we
> often release up to 90(!) packages 2 times a month (!). Maybe that can help
> with designing a similar process.
>
> * we allow "bulk" voting. We prepare the "up to 90" provider packages as a
> single "pack" of things we vote on. We have automation and tooling that
> allows us to both release and verify (by PMC members) all those packages
> together. We also involve the contributors and those who raised relevant
> issues in testing those packages (also heavily automated - example issue
> generated here https://github.com/apache/airflow/issues/33305 ) - this is
> nice because it allows us to streamline the process and release multiple
> things together, whil allow individuals to focus on testing all such
> packages individually and report it back in that single place where we
> discuss the whole "release pack".
>
> * when a bug / release/packaging/sources/problem is found in only one of
> those packages (which does not invalidate the rest) the release manager can
> decide to withdraw those faulty packages from that release "pack" but this
> does not remove +1 votes that were given for the ones that are good.
>
> * after releasing the "good" packages (and parallel fixing of the broken
> ones) - the broken ones are released with fixes as RC2 candidates. In most
> cases the fixes are really small, so the "user" testing (i.e. what has been
> tested and confirmed working so far) status is carried over to the RC2
> candidates. The PMC voting for those RC2 is restarted (i.e. we need three
> new +1 from the PMC) . But this time we turn on "accelerated" voting. We
> agree to the rule that in this case 24H (and 3 PMC +1s) is enough for the
> vote to complete.
>
> * the 72HR -> 24 HR is only done when there are really small and few fixes
> since RC1
>
> This has been discussed at the devlist, agreed and captured in our
> processes. For those interested:
>
> Discussion about introducing RC2+ accelerated voting :
> https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
> Lazy consensus on approving it:
> https://lists.apache.org/thread/cv194w1fqqykrhswhmm54zy9gnnv6kgm
> Example recent vote result where two packages have been excluded due to
> bugs but where release manager decided not to accelerate the voting due to
> big number of fixes coming since RC1:
> https://lists.apache.org/thread/1kovpkx0t2pm2xrwf61ycqdynp0kdl19
> Example vote where we had 24 HR accelerated vote:
> https://lists.apache.org/thread/ndm71tjdd3mmx7s904ds6sqxy84vb1fw (BTW We
> also had RC3 for google provider as another bug was found in RC2). - those
> rules are transitive. RC3 was also accelerated.
>
> I hope it helps.
>
> J.
>
>
>
>
> On Fri, Sep 1, 2023 at 8:53 AM Volkan Yazıcı  wrote:
>
> > Is such a thing possible? It is pretty common that many Java projects have
> > multiple modules having their own release cycles. Some of these modules are
> > miscellaneous "utilities" to support the rest of the code base. Common
> > examples I can think of are
> >
> > - BOM project covering a dozen other projects (e.g., `log4j-bom` for
> > `log4j-core`, `log4j-layout-template-json`, etc.)
> > - Utilities (e.g., `log4j-changelog` used to maint

Re: Releasing with lazy consensus

[Volkan Yazıcı]

Thanks for sharing insights from the Airflow land, much appreciated.

"Bulk" voting is something I have heard before. Certainly can be a solution
*if* the packages don't depend on each other. Otherwise I cannot see how it
helps with the cases I shared earlier. That is, `log4j-core` needs to be
released first so that `log4j-bom` can be updated and released. Put another
way, both can't be released simultaneously.

On Fri, Sep 1, 2023 at 9:24 AM Jarek Potiuk  wrote:

> I would love to hear about it, but I believe releasing any software is an
> "act of Foundation" and requires 3 explicit PMC members to say "+1" in
> order for it to have legal repercussions.
>
> So I am not so sure if releasing "software" of any kind that can be "ASF
> software" should be done without voting and 3 PMC members saying +1. In
> fact even the roll calls done by the board when the projects are not active
> is to check "Is there enough  (3) active PMC members for the PMC to make a
> release).
>
> I believe in justified cases however, you can shorten the voting period or
> even vote in "secret" and announce the voting later (for example when you
> have security release). The process says that there SHOULD be 72 HRs (not
> MUST) and if there are good reasons, it can be shortened. But the act of
> voting and 3 +1 from the PMC members is - I believe - obligatory.
>
> A comment on how we deal with possibly similar cases in Airflow - where we
> often release up to 90(!) packages 2 times a month (!). Maybe that can help
> with designing a similar process.
>
> * we allow "bulk" voting. We prepare the "up to 90" provider packages as a
> single "pack" of things we vote on. We have automation and tooling that
> allows us to both release and verify  (by PMC members) all those packages
> together. We also involve the contributors and those who raised relevant
> issues in testing those packages (also heavily automated - example issue
> generated here https://github.com/apache/airflow/issues/33305  ) - this is
> nice because it allows us to streamline the process and release multiple
> things together, whil allow individuals to focus on testing all such
> packages individually and report it back in that single place where we
> discuss the whole "release pack".
>
> * when a bug / release/packaging/sources/problem is found in only one of
> those packages (which does not invalidate the rest) the release manager can
> decide to withdraw those faulty packages from that release "pack" but this
> does not remove +1 votes that were given for the ones that are good.
>
> * after releasing the "good" packages (and parallel fixing of the broken
> ones) - the broken ones are released with fixes as RC2 candidates. In most
> cases the fixes are really small, so the "user" testing (i.e. what has been
> tested and confirmed working so far) status is carried over to the RC2
> candidates. The PMC voting for those RC2 is restarted (i.e. we need three
> new +1 from the PMC) .  But this time we turn on "accelerated" voting. We
> agree to the rule that in this case 24H (and 3 PMC +1s) is enough for the
> vote to complete.
>
> * the 72HR -> 24 HR is only done when there are really small and few fixes
> since RC1
>
> This has been discussed at the devlist, agreed and captured in our
> processes. For those interested:
>
> Discussion about introducing RC2+ accelerated voting :
> https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
> Lazy consensus on approving it:
> https://lists.apache.org/thread/cv194w1fqqykrhswhmm54zy9gnnv6kgm
> Example recent vote result where two packages have been excluded due to
> bugs but where release manager decided not to accelerate the voting due to
> big number of fixes coming since RC1:
> https://lists.apache.org/thread/1kovpkx0t2pm2xrwf61ycqdynp0kdl19
> Example vote where we had 24 HR accelerated vote:
> https://lists.apache.org/thread/ndm71tjdd3mmx7s904ds6sqxy84vb1fw  (BTW We
> also had RC3 for google provider as another bug was found in RC2). - those
> rules are transitive. RC3 was also accelerated.
>
> I hope it helps.
>
> J.
>
>
>
>
> On Fri, Sep 1, 2023 at 8:53 AM Volkan Yazıcı  wrote:
>
> > Is such a thing possible? It is pretty common that many Java projects
> have
> > multiple modules having their own release cycles. Some of these modules
> are
> > miscellaneous "utilities" to support the rest of the code base. Common
> > examples I can think of are
> >
> >- BOM project covering a dozen other projects (e.g., `log4j-bom` for
> >`log4j-core`, `log4j-layout-template-json`, etc.)
> >- Utilities (e.g., `log4j-changelog` used to maintain a changelog and
> >release notes for Java-based Logging Services projects)
> >
> > `log4j-core` release takes 72 hours due to voting. Once that is done,
> > waiting another 72 hours for `log4j-bom` feels like a waste of time.
> > Similarly, `log4j-changelog` is an internally used tool, yet we need to
> > publish it to Maven Central and such. Wouldn't it be possible to release
> > 

Re: Releasing with lazy consensus

[Jarek Potiuk]

> "Bulk" voting is something I have heard before. Certainly can be a
solution
*if* the packages don't depend on each other. Otherwise I cannot see how it
helps with the cases I shared earlier. That is, `log4j-core` needs to be
released first so that `log4j-bom` can be updated and released. Put another
way, both can't be released simultaneously.

Oh yeah. Those we have a fair share of. Even in the last release we had a
chicken-egg problem of dependencies and we had to split and manually tweak
the release process - that was a bit of a headache.
Maybe what will help - in essence with Airflow we do keep two "separate"
release trains

a) core airflow <- single package release
b) providers <- this is where the bulk voting happens (and here often
happens that there are cross-dependencies between them - but when you
release them together it's fine)

But sometimes we release certain "providers" first even if they are not
"usable" - precisely so that the later "core airflow" release makes use of
them. So "smart" splitting the releases might also help.

J


On Fri, Sep 1, 2023 at 10:25 AM Volkan Yazıcı  wrote:

> Thanks for sharing insights from the Airflow land, much appreciated.
>
> "Bulk" voting is something I have heard before. Certainly can be a solution
> *if* the packages don't depend on each other. Otherwise I cannot see how it
> helps with the cases I shared earlier. That is, `log4j-core` needs to be
> released first so that `log4j-bom` can be updated and released. Put another
> way, both can't be released simultaneously.
>
> On Fri, Sep 1, 2023 at 9:24 AM Jarek Potiuk  wrote:
>
> > I would love to hear about it, but I believe releasing any software is an
> > "act of Foundation" and requires 3 explicit PMC members to say "+1" in
> > order for it to have legal repercussions.
> >
> > So I am not so sure if releasing "software" of any kind that can be "ASF
> > software" should be done without voting and 3 PMC members saying +1. In
> > fact even the roll calls done by the board when the projects are not
> active
> > is to check "Is there enough  (3) active PMC members for the PMC to make
> a
> > release).
> >
> > I believe in justified cases however, you can shorten the voting period
> or
> > even vote in "secret" and announce the voting later (for example when you
> > have security release). The process says that there SHOULD be 72 HRs (not
> > MUST) and if there are good reasons, it can be shortened. But the act of
> > voting and 3 +1 from the PMC members is - I believe - obligatory.
> >
> > A comment on how we deal with possibly similar cases in Airflow - where
> we
> > often release up to 90(!) packages 2 times a month (!). Maybe that can
> help
> > with designing a similar process.
> >
> > * we allow "bulk" voting. We prepare the "up to 90" provider packages as
> a
> > single "pack" of things we vote on. We have automation and tooling that
> > allows us to both release and verify  (by PMC members) all those packages
> > together. We also involve the contributors and those who raised relevant
> > issues in testing those packages (also heavily automated - example issue
> > generated here https://github.com/apache/airflow/issues/33305  ) - this
> is
> > nice because it allows us to streamline the process and release multiple
> > things together, whil allow individuals to focus on testing all such
> > packages individually and report it back in that single place where we
> > discuss the whole "release pack".
> >
> > * when a bug / release/packaging/sources/problem is found in only one of
> > those packages (which does not invalidate the rest) the release manager
> can
> > decide to withdraw those faulty packages from that release "pack" but
> this
> > does not remove +1 votes that were given for the ones that are good.
> >
> > * after releasing the "good" packages (and parallel fixing of the broken
> > ones) - the broken ones are released with fixes as RC2 candidates. In
> most
> > cases the fixes are really small, so the "user" testing (i.e. what has
> been
> > tested and confirmed working so far) status is carried over to the RC2
> > candidates. The PMC voting for those RC2 is restarted (i.e. we need three
> > new +1 from the PMC) .  But this time we turn on "accelerated" voting. We
> > agree to the rule that in this case 24H (and 3 PMC +1s) is enough for the
> > vote to complete.
> >
> > * the 72HR -> 24 HR is only done when there are really small and few
> fixes
> > since RC1
> >
> > This has been discussed at the devlist, agreed and captured in our
> > processes. For those interested:
> >
> > Discussion about introducing RC2+ accelerated voting :
> > https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
> > Lazy consensus on approving it:
> > https://lists.apache.org/thread/cv194w1fqqykrhswhmm54zy9gnnv6kgm
> > Example recent vote result where two packages have been excluded due to
> > bugs but where release manager decided not to accelerate the voting due
> to
> > big number of fixes coming sinc

Re: Requests for comdev membership

[Craig L Russell]

I recently sent a PR for the site and nothing happened. No one reviewed. No one 
commented. 

Just one data point but... Is there a process for review of PRs?

Craig

On 2023/08/17 03:50:04 Rich Bowen wrote:
> It seems to me that the recent requests for comdev membership are symptoms
> of broken process. I understand that this is necessary to get things done,
> but the fact that someone has to be a comdev member in order to edit the
> website is broken. I am not sure what the way forward is here, but if
> someone has some insight into how things work, and can suggest a more
> reasonable way around this than making contractors comdev members, I would
> be much appreciative
> 
> Rich
> 

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Requests for comdev membership

[Ayush Saxena]

I just checked the repo, there aren't any open PRs from you Craig [1]
or I am checking the wrong place maybe, though I don't have the c-bit
on comdev, but would have definitely tried to review. I tried to check
what policy is followed with comdev but couldn't find any reference to
that. If there is a lack of volunteers who can review the code, the
project can have CTR [2] if not already.

Though I do agree the content of the website is pretty generic and
centric to the entire Apache community and a lot of people have
insights around that & they can contribute to that or help with
that

Letting all apache committers access to that repo might be a solution
but that looks like taking away a part from the comdev, and mostly the
folks on the PMC won't agree and is fair enough too, they did the hard
work maintaining that and developing the content, they might not want
anybody else who they don't trust to change or modify that

-Ayush


[1] https://github.com/apache/comdev-site/pulls
[2] https://www.apache.org/foundation/glossary#CommitThenReview

On Fri, 1 Sept 2023 at 23:59, Craig L Russell  wrote:
>
> I recently sent a PR for the site and nothing happened. No one reviewed. No 
> one commented.
>
> Just one data point but... Is there a process for review of PRs?
>
> Craig
>
> On 2023/08/17 03:50:04 Rich Bowen wrote:
> > It seems to me that the recent requests for comdev membership are symptoms
> > of broken process. I understand that this is necessary to get things done,
> > but the fact that someone has to be a comdev member in order to edit the
> > website is broken. I am not sure what the way forward is here, but if
> > someone has some insight into how things work, and can suggest a more
> > reasonable way around this than making contractors comdev members, I would
> > be much appreciative
> >
> > Rich
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org