I agree that we should finally have PIPs committed to git somewhere. When a PIP is approved it can be committed, but we must run the VOTE and wait for 3 binding +1, this is hard to do with a PR. It already happened a few times that people committed patches related to unapproved PIPs.
Regarding the discussion: I still think that we should keep the discussions on the mailing list. I am not talking about fine grained details that will be discussed on the PR. I am spending much of my time on Pulsar both for work and for personal fun, even though I am still overwhelmed by the flow of GH PRs and notifications. Following the ML is the best way to participate in the discussions. So I suggest: 1) use GIT to keep the PIP design document 2) run the high level discussion on the ML 3) leverage GH PRs comments for fine grained details both on the PIP document and on the related PRs Enrico Il giorno ven 31 mar 2023 alle ore 12:39 Yu <li...@apache.org> ha scritto: > > +1 for allowing collaborators to review, comment, approve, or request > further changes more conveniently > > On Fri, Mar 31, 2023 at 11:26 AM Nitin Goyal <nitin.goyal....@gmail.com> > wrote: > > > +1 (non-binding) > > > > On Fri, 31 Mar, 2023, 08:41 Jun Ma, <momoma...@hotmail.com> wrote: > > > > > +1. > > > > > > Besides using a single source to lift the review efficiency, adding > > > control over the design documents is also a good practice from the > > project > > > management perspective. > > > > > > > > > Best, > > > Jun > > > ________________________________ > > > From: Yunze Xu <y...@streamnative.io.INVALID> > > > Sent: Friday, March 31, 2023 10:44 > > > To: dev@pulsar.apache.org <dev@pulsar.apache.org> > > > Subject: Re: [DISCUSS] We must change the way we review PIPs > > > > > > +1 to me. Once the discussion thread of a PIP became too long, it > > > would be hard to continue the discussion. > > > > > > Thanks, > > > Yunze > > > > > > On Fri, Mar 31, 2023 at 9:13 AM PengHui Li <peng...@apache.org> wrote: > > > > > > > > +1 for creating a folder named "pip" in the main pulsar repo > > > > So far, it is good enough to solve the problems we've had. > > > > > > > > If it is really worth moving to another repo in the future. > > > > We can move it maybe 3, 5 years later. > > > > > > > > Thanks, > > > > Penghui > > > > > > > > > > > > On Fri, Mar 31, 2023 at 8:29 AM tison <wander4...@gmail.com> wrote: > > > > > > > > > Hi Asaf, > > > > > > > > > > Thanks for starting this thread! > > > > > > > > > > I have similar thoughts on using a single source for reviewing PIPs. > > > GH PRs > > > > > are good for conversation, although multiple conversations are still > > > hard > > > > > to follow (which can be natural) > > > > > > > > > > Here is how Rust does it[1] - a self-documented RFC repo + review > > PRs + > > > > > tracking issue on the main repo once accepted. > > > > > > > > > > Here is what I designed for TiDB[2][3]; proposals are placed in a > > > folder > > > > > under the main repo. > > > > > > > > > > We don't have to follow other community's ways, but these two > > practices > > > > > seem good to read. > > > > > > > > > > And, to follow the ASF voting strategy[4][5], we may still need a > > > standard > > > > > vote mail thread and document the result on the mailing list. > > > > > > > > > > Best, > > > > > tison. > > > > > > > > > > [1] https://github.com/rust-lang/rfcs > > > > > [2] https://github.com/pingcap/tidb/tree/master/docs/design > > > > > [3] > > > > > > > > > > > > > > > https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html > > > > > [4] https://www.apache.org/foundation/voting.html > > > > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy > > > > > > > > > > > > > > > Girish Sharma <scrapmachi...@gmail.com> 于2023年3月31日周五 04:33写道： > > > > > > > > > > > +1 (non-binding .. ? ) > > > > > > I've already commented a couple of times (here and there) that the > > > > > process > > > > > > needs to be consolidated at a single place. This is a good and > > > detailed > > > > > > approach. > > > > > > Not sure if there is a historical context behind keeping the > > > discussion > > > > > in > > > > > > dev mailing list.. > > > > > > > > > > > > Regards > > > > > > > > > > > > On Fri, Mar 31, 2023 at 1:57 AM 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? > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Girish Sharma > > > > > > > > > > > > > > > >
