Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-27 Thread koteswara Rao Gundapaneni
I agree the core idea behind the Asf is contribute in a committ mode

Others should be added for different areas

Who are redflagged should be re grouped

Regards
Koti



On Tue, 27 Feb 2024, 20:04 koteswara Rao Gundapaneni, <
koti.gundapan...@gmail.com> wrote:

>
> I totally agree the knowledge base is essential
>
> Regards
> Koti
>
>
> On Tue, 27 Feb 2024, 19:28 potiuk (via GitHub),  wrote:
>
>>
>> potiuk commented on PR #16:
>> URL:
>> https://github.com/apache/comdev-working-groups/pull/16#issuecomment-1966599011
>>
>>If there are no more comments. I'd love to get this one merged and
>> then maybe others (I can do as well) add a bit more why`s for different
>> areas. I think also - when we have a few whys we might actually regroup the
>> "red-flags" and have them groupped according to the `why` they are
>> referring to - rather than link them individually - but taht migh be a
>> refactor of the docs when we add 2nd or 3rd why as well.
>>
>>
>> --
>> This is an automated message from the Apache Git Service.
>> To respond to the message, please log on to GitHub and use the
>> URL above to go to the specific comment.
>>
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>
>> For queries about this service, please contact Infrastructure at:
>> us...@infra.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>>
>>


Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-27 Thread koteswara Rao Gundapaneni
I totally agree the knowledge base is essential

Regards
Koti


On Tue, 27 Feb 2024, 19:28 potiuk (via GitHub),  wrote:

>
> potiuk commented on PR #16:
> URL:
> https://github.com/apache/comdev-working-groups/pull/16#issuecomment-1966599011
>
>If there are no more comments. I'd love to get this one merged and then
> maybe others (I can do as well) add a bit more why`s for different areas. I
> think also - when we have a few whys we might actually regroup the
> "red-flags" and have them groupped according to the `why` they are
> referring to - rather than link them individually - but taht migh be a
> refactor of the docs when we add 2nd or 3rd why as well.
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-27 Thread via GitHub


rbowen merged PR #16:
URL: https://github.com/apache/comdev-working-groups/pull/16


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-27 Thread via GitHub


potiuk commented on PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#issuecomment-1966599011

   If there are no more comments. I'd love to get this one merged and then 
maybe others (I can do as well) add a bit more why`s for different areas. I 
think also - when we have a few whys we might actually regroup the "red-flags" 
and have them groupped according to the `why` they are referring to - rather 
than link them individually - but taht migh be a refactor of the docs when we 
add 2nd or 3rd why as well.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-24 Thread via GitHub


potiuk commented on PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#issuecomment-1962324323

   Ready for the next round of reviews.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-24 Thread via GitHub


potiuk commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501396031


##
wg-advisors/red-flags.md:
##
@@ -15,7 +15,7 @@ not a policeman enforcing the rules.
 * Has a website external to apache.org
 * Is missing reports
 * Is missing release votes
-* Has too many release candidates
+* Has too many release candidates: [why](why/why_release_process.md)

Review Comment:
   I tried to separate it, but indeed it seems better if it is combined in the 
release process. I just stressed how important it is to engage the dev 
community in the release/testing process and added a little description 
summarising why we are doing it. Should be explained now.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-24 Thread via GitHub


potiuk commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501395596


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.
+
+## Is it mandatory and what are conditions?
+
+The process is mandatory for all ASF projects. The process is the same for all 
projects. This 

Review Comment:
   Added. Also split out the "non-negotiables". 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-24 Thread via GitHub


potiuk commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501395470


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.
+
+## Is it mandatory and what are conditions?
+
+The process is mandatory for all ASF projects. The process is the same for all 
projects. This 
+
+## Are there variations for different projects?
+
+Not really. The process is the same for all projects.

Review Comment:
   I added a short description describing those variations - with the goal to 
make it clearer for both "purposes". I hope it's better now.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-24 Thread via GitHub


potiuk commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501372589


##
wg-advisors/red-flags.md:
##
@@ -15,7 +15,7 @@ not a policeman enforcing the rules.
 * Has a website external to apache.org
 * Is missing reports
 * Is missing release votes
-* Has too many release candidates
+* Has too many release candidates: [why](why/why_release_process.md)

Review Comment:
   It's an interesting one. This is precisely the kind of discussions that I 
**hoped** the `why` document will start :)
   
   IMHO that one actually deserves a separate "why", as this red flag is (now 
that you explained it not really about software releases "per se" but about 
communication and process around the releases, and possibly about involving the 
community during the relase process and engaging them in testing  - whcih is a 
subtly different thing and possibly deserves another "why". I wil propose 
something soon :)



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-24 Thread via GitHub


potiuk commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501372091


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.
+
+## Is it mandatory and what are conditions?
+
+The process is mandatory for all ASF projects. The process is the same for all 
projects. This 
+
+## Are there variations for different projects?
+
+Not really. The process is the same for all projects.

Review Comment:
   Yes. Worth mentioning the variations.
   
   But I think going into oo many details is not a good idea. It will be of 
coure always an art how "deep" we should describe it here, but the rule of 
thumb I think such document should not go into details where the linked 
document cover them, it should be a one-pager max and it should mostly focus on 
the most important "why's" - providing a very broad context that is otherwise 
distiributed among several documents, heads of people, discussions etc. etc. 
   
   I think it serves two purposes:
   
   * for the advisor - so that they can always come back here and immediately 
see - hey, why actually we are doing it ?  - a... here it is - and go into 
details if needed
   
   * for the advised ones - to be assured that what we are advising them is not 
a "cargo cult" and tha we have very good reason that you can read about it here 
why we are doing it - without having to go through all the piles of documents 
and discussions or asking others. 
   
   I will expand it a little bit soon.



##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.
+
+## Is it mandatory and what are conditions?
+
+The process is mandatory for all ASF projects. The process is the same for all 
projects. This 

Review Comment:
   Yep. I will add it.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-24 Thread via GitHub


potiuk commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501371159


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.

Review Comment:
   Good point. 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread via GitHub


tisonkun commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501326585


##
wg-advisors/red-flags.md:
##
@@ -15,7 +15,7 @@ not a policeman enforcing the rules.
 * Has a website external to apache.org
 * Is missing reports
 * Is missing release votes
-* Has too many release candidates
+* Has too many release candidates: [why](why/why_release_process.md)

Review Comment:
   The answer is not included in the new file. Do you expect elaborate it in 
the new file later, or we should create a dedicated answer.
   
   I remember that the original purpose of this "red flag" was to encourage RMs 
to waiting for more inputs instead of eagerly cancelling release candidates 
which increases the release burden.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread via GitHub


tisonkun commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501325628


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.
+
+## Is it mandatory and what are conditions?
+
+The process is mandatory for all ASF projects. The process is the same for all 
projects. This 

Review Comment:
   ```suggestion
   The process is mandatory for all ASF projects. The process is the same for 
all projects.
   ```
   
   Typo.
   
   Also, I agree with Justin's comment that the process can be subtly 
different. Or you can elaborate a bit what "the same" part is that is mandatory.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread via GitHub


tisonkun commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501325488


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.
+
+## Is it mandatory and what are conditions?
+
+The process is mandatory for all ASF projects. The process is the same for all 
projects. This 
+
+## Are there variations for different projects?
+
+Not really. The process is the same for all projects.

Review Comment:
   > some projects consider the RM as an implicit +1
   
   Here is a patch to explain no RM implicit +1 
https://github.com/apache/www-site/pull/338.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread Justin Mclean
HI,

> An implicit +1 from the RM is not something that should be encouraged.

I agree, but some projects still do it.

> Also the minimum length of time for voting is 72 hours, except for
> urgent security-related releases.

A few projects have longer times for voting, so they still fit within the 72 
minimum.

Kind Regards,
Justin

Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread sebb
On Sat, 24 Feb 2024 at 00:53, justinmclean (via GitHub)  wrote:
>
>
> justinmclean commented on code in PR #16:
> URL: 
> https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501297317
>
>
> ##
> wg-advisors/why/why_release_process.md:
> ##
> @@ -0,0 +1,30 @@
> +# Release process
> +
> +## Summary
> +
> +ASF project release software following a well defined process involving PMC 
> members voting on release
> +candidates, publishing the artifacts in the ASF distribution system, and 
> announcing the release to the
> +community.
> +
> +## Links to relevant documents
> +
> +* [Release Policy](https://www.apache.org/dev/release.html)
> +* [Release Distribution 
> Policy](https://www.apache.org/dev/release-distribution.html)
> +
> +## Why are we doing it?
> +
> +We are doing it because this is what the ASF is doing. ASF delivers 
> "Software for the public good"
> +and the act of releasing software is a key part of that. The process is 
> designed to ensure that the
> +software is properly vetted and that the community is aware of the release 
> and that the process of
> +releasing software is transparent, open and secure. Releasing the software 
> is a Legal Act of the
> +Foundation and it has consequences for the Foundation as software released 
> by the Foundation is
> +the main way the Foundation interacts with the public and can be hold 
> accountable for the software
> +it releases.
> +
> +## Is it mandatory and what are conditions?
> +
> +The process is mandatory for all ASF projects. The process is the same for 
> all projects. This
> +
> +## Are there variations for different projects?
> +
> +Not really. The process is the same for all projects.
>
> Review Comment:
>There is some variation: a few projects use super majority voting, some 
> have voters sign releases, the length of time a vote is open often varies, 
> some projects consider the RM as an implicit +1, not all projects announce 
> releases, and there are probably a few things I've forgotten about.

An implicit +1 from the RM is not something that should be encouraged.

Also the minimum length of time for voting is 72 hours, except for
urgent security-related releases.

>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.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: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread via GitHub


justinmclean commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501297317


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.
+
+## Is it mandatory and what are conditions?
+
+The process is mandatory for all ASF projects. The process is the same for all 
projects. This 
+
+## Are there variations for different projects?
+
+Not really. The process is the same for all projects.

Review Comment:
   There is some variation: a few projects use super majority voting, some have 
voters sign releases, the length of time a vote is open often varies, some 
projects consider the RM as an implicit +1, not all projects announce releases, 
and there are probably a few things I've forgotten about.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread via GitHub


justinmclean commented on code in PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501296133


##
wg-advisors/why/why_release_process.md:
##
@@ -0,0 +1,30 @@
+# Release process
+
+## Summary 
+
+ASF project release software following a well defined process involving PMC 
members voting on release
+candidates, publishing the artifacts in the ASF distribution system, and 
announcing the release to the
+community.
+
+## Links to relevant documents
+
+* [Release Policy](https://www.apache.org/dev/release.html) 
+* [Release Distribution 
Policy](https://www.apache.org/dev/release-distribution.html)
+
+## Why are we doing it?
+
+We are doing it because this is what the ASF is doing. ASF delivers "Software 
for the public good"
+and the act of releasing software is a key part of that. The process is 
designed to ensure that the
+software is properly vetted and that the community is aware of the release and 
that the process of
+releasing software is transparent, open and secure. Releasing the software is 
a Legal Act of the 
+Foundation and it has consequences for the Foundation as software released by 
the Foundation is
+the main way the Foundation interacts with the public and can be hold 
accountable for the software
+it releases.

Review Comment:
   I'd note it also gives the PMC and release manager some legal protection.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



Re: [PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread via GitHub


potiuk commented on PR #16:
URL: 
https://github.com/apache/comdev-working-groups/pull/16#issuecomment-1961978300

   > Interesting idea. Yeah, I like this. It also gives us something to point 
to when projects push back, in a "this isn't personal, it's just the way things 
are" kind of way. Especially in conjunction with the notion that we're also 
there to learn, and possibly improve the process/rules.
   
   100% agree. There is a huge value in something being publicly stated in 
"semi-official" way. Just writing things down and pointing to it as a link is 
enough to stop treating things as personal opinion but something that is 
"commonly understood". Also when we connect it with the gorup of advisors who 
are mostly a "group ASF members who actually care enough to spend their 
personal time on helping other projects" has additional benefit that it is not 
seen as something that is "top-> bottom" but more like "group of peers agreed 
this is how it is".


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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



[PR] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

2024-02-23 Thread via GitHub


potiuk opened a new pull request, #16:
URL: https://github.com/apache/comdev-working-groups/pull/16

   I would like to propose the "why" folder, where we will keep a (very) short 
summary about some of the rules and policies that we will be - as Advisors - 
discussing with the projects we will advise.
   
   I think we need something like that - also as a place where we
   - advisors - will be able to update and exchange our understanding on why 
there are certain rules and policies. Also to discuss future variations and 
changes to those rules, possibly resulting from interactions with multiple PMCs 
when we will learn from them how they are applying certain rules and policies 
in their environment.
   
   I gave an example of how I see such "why" captured information could look 
like - starting with the most familiar (for me) release process and I am 
curious what others think about it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@community.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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