[jira] [Commented] (COMDEV-553) Change the Github default branch to "main" for Teaclave TrustZone SDK

[Rich Bowen (Jira)]

[ 
https://issues.apache.org/jira/browse/COMDEV-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894548#comment-17894548
 ] 

Rich Bowen commented on COMDEV-553:
---

Hi, Yuan,

You appear to have opened this ticket in the wrong place. I assume you want to 
open it under Incubator, rather than Comdev?

> Change the Github default branch to "main" for Teaclave TrustZone SDK
> -
>
> Key: COMDEV-553
> URL: https://issues.apache.org/jira/browse/COMDEV-553
> Project: Community Development
>  Issue Type: Task
>Reporter: Yuan Zhuang
>Priority: Major
>
> Hi community,
> We would like to change the Github default branch for Teaclave TrustZone SDK 
> <[https://github.com/apache/incubator-teaclave-trustzone-sdk]> from "no-std" 
> to "main". This proposal mainly aims to simplify future development and 
> maintenance. 
> The VOTE passed and the mail thread is: 
> [https://lists.apache.org/thread/46sgblqjolxfro42ot7ttv577mqv49xz] 
> Thanks!
> Yuan Zhuang
> Apache Teaclave (incubating) PPMC



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

ASF Plus One Newsletter launched

[Brian Proffitt]

The Marketing and Publicity team has launched the monthly ASF Plus One
Newsletter[1], a roundup of ASF news and activities including project
updates, public good stories, videos, news coverage, and more.

If you have an item you want to see in this monthly roundup, send it to
mark...@apache.org, so we can get your news in.

To get the newsletter delivered directly to your inbox, you can subscribe
to it at the bottom of every newsletter.

Thanks,
Brian

[1]
https://news.apache.org/foundation/entry/asf-plus-one-newsletter-october-2024

Brian Proffitt
VP, Marketing & Publicity
VP, Conferences

[jira] [Created] (COMDEV-555) Move newcommitter and newpmcmember under pmc/

[Rich Bowen (Jira)]

Rich Bowen created COMDEV-555:
-

 Summary: Move newcommitter and newpmcmember under pmc/
 Key: COMDEV-555
 URL: https://issues.apache.org/jira/browse/COMDEV-555
 Project: Community Development
  Issue Type: Improvement
  Components: Website
Reporter: Rich Bowen


The top-level documents [https://community.apache.org/newpmcmember] and 
[https://community.apache.org/newcommitter] should be in the pmc/ directory.
 * Move the files
 * Fix links to templates (will now need to go to ../templates/  rather than 
templates/)
 * Put redirects in /static/.htaccess
 * Update all links (that we can find) to these documents

Related issues 551 and 552 should probably be done first, or at the same time.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Created] (COMDEV-554) AutoIndex icons not displaying

[Rich Bowen (Jira)]

Rich Bowen created COMDEV-554:
-

 Summary: AutoIndex icons not displaying
 Key: COMDEV-554
 URL: https://issues.apache.org/jira/browse/COMDEV-554
 Project: Community Development
  Issue Type: Improvement
  Components: Website
Reporter: Rich Bowen


AutoIndex icons are not displaying in directory listings. See, for example, 
[https://community.apache.org/templates/]

This is presumably just a missing/misconfigured Alias directive in httpd, or a 
misconfigured FancyIndexing directive.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Re: [apache/comdev-site] Refactor of "new pmc member" doc and templates (PR #189)

[Rich Bowen]

> On Oct 31, 2024, at 9:01 AM, Rich Bowen  wrote:
> 
> I see that there is considerable disagreement - 
> https://github.com/apache/comdev-site/pull/189 - with the change that I have 
> made here. While, as I have said, I think that the change is correct as per 
> the advice given at https://github.com/apache/comdev-site/pull/189 

Sorry, clarification: The advice given at 
https://www.apache.org/foundation/voting.html

— 
Rich Bowen
rbo...@rcbowen.com

Re: [apache/comdev-site] Refactor of "new pmc member" doc and templates (PR #189)

[Rich Bowen]

> On Oct 31, 2024, at 9:03 AM, Rich Bowen  wrote:
> 
> 
> 
>> On Oct 31, 2024, at 9:01 AM, Rich Bowen  wrote:
>> 
>> I see that there is considerable disagreement - 
>> https://github.com/apache/comdev-site/pull/189 - with the change that I have 
>> made here. While, as I have said, I think that the change is correct as per 
>> the advice given at https://github.com/apache/comdev-site/pull/189 
> 
> Sorry, clarification: The advice given at 
> https://www.apache.org/foundation/voting.html
> 

I have reverted that specific portion of the PR. As I say in my comment:

Note that I think that vetoes, rather than majority, is what *consistently* 
leads to abuse in our actual projects, while the notion that a majority vote 
could lead to abuse is purely hypothetical and implies that "we" know more than 
the actual members of the PMC. But I sense that I am, ironically, outvoted 
here. :)

Requesting reviews based on the other aspects of my PR, and we can discuss 
vetos vs majorities at our leisure.

— 
Rich Bowen
rbo...@rcbowen.com

Re: Consensus? we do have a glossary (was:Refactor of "new pmc member" doc...)

[Rich Bowen]

> On Oct 31, 2024, at 10:04 AM, Bertrand Delacretaz  
> wrote:
> 
> On Thu, Oct 31, 2024 at 1:57 PM Rich Bowen 
> wrote (on a GitHub page):
>> 
>> I think possibly one of the points of confusion here is the use of the word 
>> "consensus",
>> which has been a point of confusion for years, since that word has several 
>> substantially different uses
> 
> We do have an ASF glossary at
> https://www.apache.org/foundation/glossary, which we might improve and
> which we should IMHO point to more often.
> 
> Or maybe create an additional glossary on the comdev website, and link
> both pages for completeness.


Thank you. I tend to forget that that’s there. While the definition of 
“consensus” there is at odds with how I understand the word, it does seem 
reasonable for me to agree to use that definition. I am willing to accept that 
my *opinion* is different from the *consensus* of the community as to the 
meaning of the word, and I’ll use it accordingly.

I do continue to think that if a PMC votes unanimously-minus-one for a 
particular candidate, that’s a pretty good indicator that there’s dysfunction 
in that PMC. Ironically, if I now attempt to override that position, I would be 
exhibiting the very behavior that I am condemning.

— 
Rich Bowen
rbo...@rcbowen.com

[jira] [Closed] (COMDEV-553) Change the Github default branch to "main" for Teaclave TrustZone SDK

[Yuan Zhuang (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMDEV-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yuan Zhuang closed COMDEV-553.
--
Resolution: Feedback Received

> Change the Github default branch to "main" for Teaclave TrustZone SDK
> -
>
> Key: COMDEV-553
> URL: https://issues.apache.org/jira/browse/COMDEV-553
> Project: Community Development
>  Issue Type: Task
>Reporter: Yuan Zhuang
>Priority: Major
>
> Hi community,
> We would like to change the Github default branch for Teaclave TrustZone SDK 
> <[https://github.com/apache/incubator-teaclave-trustzone-sdk]> from "no-std" 
> to "main". This proposal mainly aims to simplify future development and 
> maintenance. 
> The VOTE passed and the mail thread is: 
> [https://lists.apache.org/thread/46sgblqjolxfro42ot7ttv577mqv49xz] 
> Thanks!
> Yuan Zhuang
> Apache Teaclave (incubating) PPMC



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (COMDEV-553) Change the Github default branch to "main" for Teaclave TrustZone SDK

[Yuan Zhuang (Jira)]

[ 
https://issues.apache.org/jira/browse/COMDEV-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894593#comment-17894593
 ] 

Yuan Zhuang commented on COMDEV-553:


Closed and reopened on Incubator channel. Thanks for your information!

> Change the Github default branch to "main" for Teaclave TrustZone SDK
> -
>
> Key: COMDEV-553
> URL: https://issues.apache.org/jira/browse/COMDEV-553
> Project: Community Development
>  Issue Type: Task
>Reporter: Yuan Zhuang
>Priority: Major
>
> Hi community,
> We would like to change the Github default branch for Teaclave TrustZone SDK 
> <[https://github.com/apache/incubator-teaclave-trustzone-sdk]> from "no-std" 
> to "main". This proposal mainly aims to simplify future development and 
> maintenance. 
> The VOTE passed and the mail thread is: 
> [https://lists.apache.org/thread/46sgblqjolxfro42ot7ttv577mqv49xz] 
> Thanks!
> Yuan Zhuang
> Apache Teaclave (incubating) PPMC



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Consensus? we do have a glossary (was:Refactor of "new pmc member" doc...)

[Bertrand Delacretaz]

On Thu, Oct 31, 2024 at 1:57 PM Rich Bowen 
wrote (on a GitHub page):
>
> I think possibly one of the points of confusion here is the use of the word 
> "consensus",
> which has been a point of confusion for years, since that word has several 
> substantially different uses

We do have an ASF glossary at
https://www.apache.org/foundation/glossary, which we might improve and
which we should IMHO point to more often.

Or maybe create an additional glossary on the comdev website, and link
both pages for completeness.

-Bertrand

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

Re: Consensus? we do have a glossary (was:Refactor of "new pmc member" doc...)

[Jarek Potiuk]

Comment: I also have a natural inclination to think that consensus is a bit
different than "allow veto". But, well, technically that's it. But I think
there is a subtle difference between consensus and "I have the right to
veto" thing - especially that consensus is all about getting people united,
and veto is all about getting them conflicted.
IMHO veto should only be used in very specific situations where the cost of
handling potential veto are much smaller than potential gains from applying
it. I think personally that the cost of veto for cases where people are
involved and control can be exerted overy the whole project are far too big.

Maybe because veto has a very strong meaning in Polish and for Polish
people.

The "liberum veto" [1] was the "golden liberty" thing in the XVI th/ XVII
th/ XVII th century that every Polish-Lithuanian nobleman had the right to
- block any decision by any deciding body. And while historians universally
agree that "liberum veto" was great to build "constitutionalism" in Poland
- at first when it has been used mostly to show different opinions and
trigger discussion (and eventually was withdrawn), they also agree it's
been the  main reason for its fall. Especially when neighbouring "predator"
countries (Russia especially, Prussia and Austria) learned that they can
use it to manipulate the system and started to "buy" liberum veto
from noblemen and started to be applied to more things that
originally intended.

Here an interesting passage from the Wikipedia article:

>  the proceedings of the next few sejms, the veto was still occasionally
overruled, but it became gradually more accepted. Before 20 years had
passed, in 1669 in Kraków, the entire Sejm was prematurely disrupted on the
strength of the liberum veto before it had finished its deliberations by
the Kyiv deputy, Adam Olizar. The practice spiraled out of control, and in
1688, the Sejm was dissolved even before the proceedings had begun or the
Marshal of the Sejm was elected.

This later led to the First [2], Second [3] and Third [4] Partition of
Poland. Poland disappeared from the maps (but luckily not the hearts of
people) for 123 years after.

I see a lot of parallels here.

J.


[1] Liberum veto https://en.wikipedia.org/wiki/Liberum_veto
[2] First Partition of Poland -
https://en.wikipedia.org/wiki/First_Partition_of_Poland
[3] Second Partition of Poland -
https://en.wikipedia.org/wiki/Second_Partition_of_Poland
[4] Third Partition of Poland -
https://en.wikipedia.org/wiki/Third_Partition_of_Poland


On Thu, Oct 31, 2024 at 3:27 PM Rich Bowen  wrote:

>
>
> > On Oct 31, 2024, at 10:04 AM, Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
> >
> > On Thu, Oct 31, 2024 at 1:57 PM Rich Bowen 
> > wrote (on a GitHub page):
> >>
> >> I think possibly one of the points of confusion here is the use of the
> word "consensus",
> >> which has been a point of confusion for years, since that word has
> several substantially different uses
> >
> > We do have an ASF glossary at
> > https://www.apache.org/foundation/glossary, which we might improve and
> > which we should IMHO point to more often.
> >
> > Or maybe create an additional glossary on the comdev website, and link
> > both pages for completeness.
>
>
> Thank you. I tend to forget that that’s there. While the definition of
> “consensus” there is at odds with how I understand the word, it does seem
> reasonable for me to agree to use that definition. I am willing to accept
> that my *opinion* is different from the *consensus* of the community as to
> the meaning of the word, and I’ll use it accordingly.
>
> I do continue to think that if a PMC votes unanimously-minus-one for a
> particular candidate, that’s a pretty good indicator that there’s
> dysfunction in that PMC. Ironically, if I now attempt to override that
> position, I would be exhibiting the very behavior that I am condemning.
>
> —
> Rich Bowen
> rbo...@rcbowen.com
>
>
>

Re: Consensus? we do have a glossary (was:Refactor of "new pmc member" doc...)

[Craig Russell]

I would be in favor of removing "consensus" from our documentation.

It has a general meaning of "group agreement" which is not how we use it here. 

I would propose using "unanimous" instead of "consensus" as there seems to be 
no ambiguity about unanimity. 

And then "majority approval" which is "more +1 than -1 votes".

So we would have these with the Apache three vote minimum:

Procedural votes (new PMC members, new committers) require majority approval 
with at least three +1 votes.

Code changes require unanimous approval with at least three +1 votes.

While I really dislike changing history, "consensus" has been a bad term for so 
long...

Craig


> On Oct 31, 2024, at 07:04, Bertrand Delacretaz  wrote:
> 
> On Thu, Oct 31, 2024 at 1:57 PM Rich Bowen 
> wrote (on a GitHub page):
>> 
>> I think possibly one of the points of confusion here is the use of the word 
>> "consensus",
>> which has been a point of confusion for years, since that word has several 
>> substantially different uses
> 
> We do have an ASF glossary at
> https://www.apache.org/foundation/glossary, which we might improve and
> which we should IMHO point to more often.
> 
> Or maybe create an additional glossary on the comdev website, and link
> both pages for completeness.
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re[2]: Consensus? we do have a glossary (was:Refactor of "new pmc member" doc...)

[Keith N. McKenna]

On 2024-10-31 at 19:17, "Dave Fisher"  wrote:
>> On Oct 31, 2024, at 2:28 PM, Craig Russell  wrote:
>> 
>> I would be in favor of removing "consensus" from our documentation.
>> 
>> It has a general meaning of "group agreement" which is not how we use it
here. 
>> 
>> I would propose using "unanimous" instead of "consensus" as there seems to
be no ambiguity about unanimity. 
>
>Consensus is a great term and is what we do. We don’t do unanimity, we find
an acceptable path by working towards Consensus. We should avoid Votes if at
all possible.
>
>To me Consensus is a Core value of the ASF and without it I have no interest
in the Foundation.
>
>Best,
>Dave
>

+1 from me

Regards
Keith


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

Re: Consensus? we do have a glossary (was:Refactor of "new pmc member" doc...)

[Dave Fisher]

> On Oct 31, 2024, at 2:28 PM, Craig Russell  wrote:
> 
> I would be in favor of removing "consensus" from our documentation.
> 
> It has a general meaning of "group agreement" which is not how we use it 
> here. 
> 
> I would propose using "unanimous" instead of "consensus" as there seems to be 
> no ambiguity about unanimity. 

Consensus is a great term and is what we do. We don’t do unanimity, we find an 
acceptable path by working towards Consensus. We should avoid Votes if at all 
possible.

To me Consensus is a Core value of the ASF and without it I have no interest in 
the Foundation.

Best,
Dave


> 
> And then "majority approval" which is "more +1 than -1 votes".
> 
> So we would have these with the Apache three vote minimum:
> 
> Procedural votes (new PMC members, new committers) require majority approval 
> with at least three +1 votes.
> 
> Code changes require unanimous approval with at least three +1 votes.
> 
> While I really dislike changing history, "consensus" has been a bad term for 
> so long...
> 
> Craig
> 
> 
>> On Oct 31, 2024, at 07:04, Bertrand Delacretaz  
>> wrote:
>> 
>> On Thu, Oct 31, 2024 at 1:57 PM Rich Bowen 
>> wrote (on a GitHub page):
>>> 
>>> I think possibly one of the points of confusion here is the use of the word 
>>> "consensus",
>>> which has been a point of confusion for years, since that word has several 
>>> substantially different uses
>> 
>> We do have an ASF glossary at
>> https://www.apache.org/foundation/glossary, which we might improve and
>> which we should IMHO point to more often.
>> 
>> Or maybe create an additional glossary on the comdev website, and link
>> both pages for completeness.
>> 
>> -Bertrand
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
> 
> Craig L Russell
> c...@apache.org
> 
> 
> -
> 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

Re: [apache/comdev-site] Refactor of "new pmc member" doc and templates (PR #189)

[Rich Bowen]

I see that there is considerable disagreement - 
https://github.com/apache/comdev-site/pull/189 - with the change that I have 
made here. While, as I have said, I think that the change is correct as per the 
advice given at https://github.com/apache/comdev-site/pull/189 I’ll modify my 
PR to revert the specific change about voting so that we can move forward.

That said, I think that empowering *one voice* on a PMC to override the wisdom 
of everyone else on that PMC is unwise, and leads directly to the kind of BDFL 
behavior that I’m actively working against on three different projects at this 
time. I find that deeply frustrating.

—Rich

> On Oct 29, 2024, at 10:25 PM, Craig Russell  wrote:
> 
> I find it very difficult to deal with policy issues via GitHub PR comments.
> 
> Could we please have a separate thread on the dev list where we discuss 
> issues like:
> 
> What does consensus mean? (I think elsewhere it is lazy approval)
> 
> Can PMC votes be vetoed (by a single -1 vote)?
> 
> Can committer votes be vetoed  (by a single -1 vote)?
> 
> If needed, I will volunteer to start such discussion...
> 
> Craig
> 
>> On Oct 29, 2024, at 09:35, Rich Bowen  wrote:
>> 
>> @rbowen  pushed 1 commit.
>> 
>> 9409c82 
>> 
>>  vote outcome definition
>> —
>> View it on GitHub 
>> 
>>  or unsubscribe 
>> .
>> You are receiving this because you are subscribed to this thread.
>> 
> 
> Craig L Russell
> c...@apache.org
> 

— 
Rich Bowen
rbo...@rcbowen.com