> > One issue will be PIP numbering. If we only merge accepted PIPs, but > all PIPs get numbers, we'll have holes in our pip/ directory. It might > be worth adding a README.md to the pip directory that both explains > the process and enumerates the PIPs (both accepted and rejected). >
I'm ok with adding such a file, but I think it will go stale. How about I add a README and in it include a link showing all PIPs, and explaining PR status is accepted/rejected status? Of course I can detail the process. Is it ok if we won't specify where to have the general discussion, and in 20 PIPs from now we'll see how it evolves organically and then specify that in the process? On Mon, Apr 3, 2023 at 6:26 AM Michael Marshall <mmarsh...@apache.org> wrote: > +1 > > I support having the high-level discussion on the ML, but I can see > that becoming confusing if there are multiple places to discuss the > PIP. In my view, GitHub is great when you want to discuss specific > lines in a PR, but general discussion on the PR's main page is > essentially the same as a mailing list, except the formatting is > generally better. > > One issue will be PIP numbering. If we only merge accepted PIPs, but > all PIPs get numbers, we'll have holes in our pip/ directory. It might > be worth adding a README.md to the pip directory that both explains > the process and enumerates the PIPs (both accepted and rejected). > > For historical reference, Christophe proposed this change within this > thread: https://lists.apache.org/thread/m8dr0hz7qn7rkd48bcp430lcq2q3674g > > The primary objection was a concern about losing PIPs and the issue of > questions about merges. I think we'll be able to address those > concerns. > > Thanks, > Michael > > On Sun, Apr 2, 2023 at 11:14 AM Dave Fisher <wave4d...@comcast.net> wrote: > > > > > > > > Sent from my iPhone > > > > > On Apr 2, 2023, at 7:35 AM, Asaf Mesika <asaf.mes...@gmail.com> wrote: > > > > > > Summarizing so far: > > > > > > Non-binding: Girish Sharma, Nitin Goyal > > > Binding: Christophe Bornet, Penghui Li, Jun Ma, Yu Liu, Lari > > > > > > Questions: > > > 1. Girish - Why do we need to keep the voting in the mailng list? > > > > > > Since it’s mandatory by ASF. > > > Also, I prefer to change the process step by step. This is a big > change as it is. > > > > Voting on PIPs is something that this PMC decided to do. The ASF > mandatory dev list voting is for RELEASES. (and privately for committers > and PMC members) > > > > I also agree that it is a big change and let’s keep changes minimal. > > > > > > > > 2. Tison - Do we keep the voting in the mailing list? > > > > > > Yes > > > > > > 3. Enrico: Discussion on high level details should remain in the > mailing list. > > > > > > Judging from PIPs I read, I would say the majority of the feedback is > not in the scope of the PIP, but in the scope certain section / part of the > PIP. if 90% of the comments already transpire in the PR, I don’t think it > will benefit for the mere 10%. > > > Also, human beings are hard at using two systems at the same time :) > > > > > > A big plus for discussions on PR is that it’s public and everybody can > pitch in (For example, Eron Wright was invited to help on a PIP for Open ID > Connect (Michael) by team members. If the barrier was: joing the mailing > list, we wouldn’t get it. > > > > Subscribing to the mailing list is not a barrier. Simply send an email. > The only delay is waiting for a moderator to let in through. I know because > I’m likely the one who will do this. (The job is mostly ignoring spam.) > > > > It is easy to review emails on https://lists.Apache.org and you can > start a reply there. > > > > > > If it’s very critical for you, we can just leave it open, and let > people decide where to comment. WDYT? > > > > > > 4. Lari - can we consider separate repo. > > > > > > It’s possible of course, but I fear the following: > > > - It’s yet another repo to clone and search. Majority of PIPs are > Pulsar related and majority of Pulsar contributors have that cloned, used > and up to date weekly / daily. It’s would create less friction if it is on > main repo. You need to search? Pulsar is already there, ready. > > > > Not all PIPs are necessarily about the main repository. Since we publish > pips in the website doing these PRs in the pulsar-site repository might be > a good option. > > > > > - Previous discussion long time ago had many decision points which > eventually “klled” the initiative. > > > > > > We can always move it if it really causes a pain point to many people. > > > > > > WDYT? > > > > Thanks for your initiative! > > > > Best, > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > >> On 31 Mar 2023, at 23:05, Lari Hotari <lhot...@apache.org> wrote: > > >> > > >> +1 > > >> > > >> Could we consider a separate repository for the PIP files? > > >> > > >> -Lari > > >> > > >>> On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <asaf.mes...@gmail.com> > wrote: > > >>> > > >>> Hi all, > > >>> > > >>> In the last 2 months, I've increased my PIP review time (I do it in > > >>> cycles), and reviewed quite a few PIPs. > > >>> > > >>> My conclusion as a result of that: > > >>> > > >>> It's nearly impossible to review PIPs using a mailing list. > > >>> We must fix it soon. > > >>> > > >>> *Why?* > > >>> 1. Let's say you review the PIP and find 10 issues. Once you quote > and > > >>> comment on those ten points, you basically started 10 threads of > > >>> conversations. > > >>> After 2-3 ping pongs with quotes of quotes of quotes, it takes you > forever > > >>> to read each thread properly. You find your CTRL-F to search to find > your > > >>> original quote, and reply. Load it up again in your head, switching > to the > > >>> PIP tab to read it again. > > >>> After 10 ping pongs, it becomes almost an impossible mission. > > >>> > > >>> I can say I'm 75% tired just from the process, not from the review > itself. > > >>> > > >>> 2. It's non collaborative by design. > > >>> After 10 ping pongs, the ability of someone to come and join the > discussion > > >>> is 0. They need to go through so many replies, which are half > quotes, find > > >>> the original reply, and browse to the PIP. > > >>> It's no wonder people drop off the PIP review once we cross 5-6 > replies. > > >>> It's no wonder, nobody joins after 10 replies. > > >>> > > >>> 3. It's not open to the public. Non collaborative. > > >>> You can't just get a link, and join the review. Not only because of > (1) and > > >>> (2). You need to join the mailing list. You don't get the past > emails to > > >>> reply. Just joining the list is a high enough bar for many people. > > >>> I personally participated in review of proposals in OpenTelemetry in > the > > >>> last 6 months, even though I'm just an occasional user. Why? They > were > > >>> conducted on GitHub PR , so it was easy for me - click a link and > reply. > > >>> > > >>> 4. All over the place > > >>> Sometimes people comment on the GitHub issue. > > >>> Sometimes on the mailing list. > > >>> Not a single place. > > >>> > > >>> 5. No history. > > >>> Ok, finally the author was convinced. I can't see just the changes. > They > > >>> need to explicitly tell me something was changed. > > >>> > > >>> 6. Delete All. > > >>> They can go crazy, after 1 year, edit the GitHub issue , delete all > the > > >>> text and write "Kafka is the king". No history, nobody can stop > them. It's > > >>> their issue. > > >>> > > >>> 7. Show me all the approved PIPs > > >>> Hard to track it today, hard to maintain it updated. > > >>> > > >>> 8. Resolved comments > > >>> Even though you managed to read all 35 replies so far, in reply 36 > you see > > >>> the author agreed to all 8 out of 10 suggestions. You have no idea of > > >>> knowing that in advance. You just wasted 1 hour. > > >>> > > >>> > > >>> *What do I suggest?* > > >>> > > >>> PR is the main tool we have that allows multiple threaded discussion. > > >>> Git provides history. You can't delete it without approval from PMC > > >>> members. > > >>> > > >>> 1. We'll create a folder named "pip" in the pulsar main repo. It will > > >>> contain one markdown file for each PIP. The file will be named > > >>> "pip-xxx.md".I will write below how to obtain XXX before you start. > > >>> 2. To create a PIP, you grab "pip/template.md" and use it to compose > your > > >>> file in the pip folder. > > >>> 3. You submit this file as a PR named "PIP-xxx: short description". > > >>> 4. You create "[DISCUSS] PIP-xxx: short description" in the DEV > mailing > > >>> list and refer people to your PR, with short text explaining the > gist of > > >>> it. > > >>> 5. People discuss using PR comments, each is its own threaded > comment. > > >>> 6. Comment was done discussion? They resolve it. This way you see > what the > > >>> pending discussions are at a glance. > > >>> 7. Reached consensus? Good. Send "[VOTE] PIP-xxx: short description" > on DEV > > >>> mailing list. > > >>> 8. PIP approved? Awesome. Push commit with link to vote. > > >>> A PMC member will merge it. > > >>> Merge == approved. > > >>> PMC members can add a PIP label. > > >>> 9. Rejected? All good. Close the PR. > > >>> Closed == Rejected. > > >>> It can't be deleted. All comments are still here. > > >>> > > >>> Before you start, you search Pull Requests with label PIP in GitHub > (`is:pr > > >>> "PIP-" in:title`) > > >>> Take the biggest number and add 1. > > >>> It is super rare to have two people create PR at the same time. > > >>> > > >>> *Show me all approved PIPs:* > > >>> Search merged PRs labeled PIP. > > >>> Look at "pip" folder > > >>> > > >>> *Show me rejected PIPs:* > > >>> Search closed PRs with "PIP-" in title, or labeled PIP. > > >>> > > >>> > > >>> This is very similar to how Apache BK works. > > >>> > > >>> WDYT? > > >>> > > > > > >
