I've converted all correspondence here into PIP: https://github.com/apache/pulsar/issues/20207 Also opened a new email thread on it.
On Mon, Apr 3, 2023 at 12:46 PM Asaf Mesika <asaf.mes...@gmail.com> wrote: > 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? >> > >>> >> > > >> > >> >
