Hi JB, > As a separate discussion, maybe we could consider doing the release > directly in both general incubator and podling dev mailing list (it > would be closer to what a project does post graduation).
Thanks for your suggestion! My initial concern with sending a single release vote to both mailing lists was that it might make the tally ambiguous. When I think about it again, however, I no longer consider this a significant problem. Voters could indicate whether they are voting as a PPMC member, as an IPMC member with a binding vote, or in both capacities. This would be similar to the current practice of suggesting binding voters identify their status and Apache ID. The Release Manager would simply need to record the PPMC endorsement and the binding IPMC approval separately. The wording I have proposed for the Incubator release policy is compatible with this practice. It defines the release vote to take place on both the podling dev list and the Incubator general list, concurrently or sequentially, and requires both voting thresholds to be satisfied, but it does not prescribe how the discussion must be threaded. A single vote thread sent to both lists would therefore be compatible with the proposed wording and, as you noted, would be closer to the process used after graduation. If you find better wording, feel free to send a patch. Best, tison. Dave Fisher <[email protected]> 于2026年9月3日周四 22:45写道： > Running concurrent votes will require Tooling to make changes to make > changes to ATR. > > In ATR we could handle the logistics of a VOTE on two lists at once > (rather than sequential votes) > > In this case the truly binding votes will belong to IPMC members who will > need to cast them using ATR’s Vote page after logging in with MFA. Each > VOTE thread will get votes as they are cast. > > ATR provides many of the standard checks. > > I support this change to the IPMC’s guidelines. > > Best, > Dave > > > On Sep 3, 2026, at 7:13 AM, Jean-Baptiste Onofré <[email protected]> > wrote: > > > > Hi Tison > > > > Technically, what matters is the IPMC vote (as you mentioned). The > > "pre-vote" in the podling should happen before, but could be > > "concurrent". I think your update is good. > > > > As a separate discussion, maybe we could consider doing the release > > directly in both general incubator and podling dev mailing list (it > > would be closer to what a project does post graduation). > > > > Regards > > JB > > > > On Thu, Sep 3, 2026 at 6:18 AM tison <[email protected]> wrote: > >> > >> Hi, > >> > >> I opened a PR to modify the release guidelines [^1] under the Incubator > [1]. > >> > >> [1] https://github.com/apache/incubator/pull/145 > >> > >> Briefly, I wrote: > >> > >>> During incubation, PPMC members learn how to govern an ASF project. A > >> PPMC operates like a PMC but reports to the Incubator PMC rather than to > >> the ASF Board. The PPMC release vote ensures that the Podling community > >> participates in producing and reviewing ASF releases. Because the PPMC > >> cannot make formal decisions on behalf of the ASF, the Incubator PMC > >> provides the binding approval required for a Podling release to become > an > >> ASF release. > >>> > >>> The PPMC vote and the Incubator PMC vote MAY be conducted concurrently > >> or, at the Podling's discretion, sequentially. The timing and conduct of > >> the votes MUST follow the applicable requirements of the Apache Voting > >> Process and the ASF Release Policy. > >>> > >>> The proposed release is approved only when both of the following > >> requirements have been satisfied: > >>> > >>> - At least three PPMC members have voted +1, and there are more +1 than > >> -1 votes from PPMC members. > >>> - At least three Incubator PMC members have cast binding +1 votes, and > >> there are more binding +1 than binding -1 votes. > >>> > >>> Only votes from Incubator PMC members are binding for the purpose of > ASF > >> release approval. The PPMC vote is a separate incubation requirement > >> intended to ensure that the Podling community participates in the > release > >> process. > >> > >> This continues the discussion at [2]. And I noticed some historical > >> discussions about the interaction between IPMC and PPMCs around > releases. > >> > >> [2] https://lists.apache.org/thread/j0008npmljw3j6ckko6o9tcrttgmgo1n > >> > >> Feel free to drop your comments and see if we should make any changes > here. > >> > >> Best, > >> tison. > >> > >> [^1] Basically, the Incubator does not define Release Policies. Legal > and > >> Infra do [3][4]. The IPMC formally conducts Podling's releases. Within > the > >> Incubator, we define guidelines to help the PPMC learn how to run an ASF > >> project. > >> > >> [3] https://www.apache.org/legal/release-policy.html > >> [4] https://infra.apache.org/policies.html > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
