I support moving PIPs to the code base. When we discussed this option during last year's redesign of the PIP process, an objection was that "merging" a PIP could be construed as acceptance of the PIP. As long as we are clear that we merge all proposed PIP PRs because it is good to have the historical record, I think we'll be able to prevent confusion.
> Also we have old PIPs that have been abandoned or that never completed VOTEs This raises the question of how to handle historical PIPs. We could do some work to move PIPs out of the wiki and out of issues into the code base. The wiki is just another git repo, so any committer should be able to help migrate PIPs in the wiki to the apache/pulsar git repo. This might also be an opportunity to double check the status on old PIPs. Thanks, Michael On Wed, Aug 24, 2022 at 10:23 AM 丛搏 <congbobo...@gmail.com> wrote: > > Hi all, > > I also think it's a good idea. Not only can it prevent the duplication of PIP > numbers, but most importantly, it is easier to annotate, in other words, > It can review the PIP just like the review code, it can make the problem > more focused, and it is easier for the viewer to annotate at any time. > It didn't make a huge difference, just from ISSUE to PR. We have no > reason not to change it, having it will greatly improve the review > efficiency of PIP. > > Thanks, > Bo > > PengHui Li <peng...@apache.org> 于2022年8月24日周三 10:01写道： > > > > Hi Rajan, > > > > > I didn't understand this part. You want one to create a PR before > > submitting a proposal? That's clearly not a good idea because if the PIP > > approach will change then the entire development effort will be wasted and > > that's the whole purpose of PIP. I guess creating PIP into an issue and > > discussing the issue is definitely working and it's an easier way to > > discuss quickly rather than discussing over email threads. > > > > Sorry, I mean create a PR to add the proposal, not the implementation. > > Before adding the proposal, we should discuss the motivation on the mailing > > list first. > > > > > Let's not change this practice without good discussion and agreement from > > the community. > > > > I don't think this essentially changes this part, it just provides a way > > for reviewers to > > review the details of the proposal more efficiently. For a quick > > discussion, this will not change > > it. Let me try to clarify the procedure after we applied this idea > > > > > > 1. Send the email first to discuss the motivation of your proposal > > 2. Discuss the motivation under the mailing list and request a PIP > > number if there are no objections > > 3. Create a PR to add the detailed proposal > > 4. *Send out the VOTE email with the PR link* > > 5. *Review the proposal(The PR) on Github and vote under the mailing > > list.* > > 6. Merge the PR of the proposal after the proposal get 3 (+1) bindings > > > > The only difference is step 4 and step 5. Currently, we share the issue > > link to ask for a review. > > > > Thanks, > > Penghui > > > > On Wed, Aug 24, 2022 at 1:22 AM Rajan Dhabalia <dhabalia...@gmail.com> > > wrote: > > > > > Hi, > > > > > > >>> I think we can move all the PIPs to the codebase and the new proposal > > > and proposal without any reviews should happen with a PR first. So that we > > > can review and comment easily. > > > > > > I didn't understand this part. You want one to create a PR before > > > submitting a proposal? That's clearly not a good idea because if the PIP > > > approach will change then the entire development effort will be wasted and > > > that's the whole purpose of PIP. I guess creating PIP into an issue and > > > discussing the issue is definitely working and it's an easier way to > > > discuss quickly rather than discussing over email threads. > > > > > > Let's not change this practice without good discussion and agreement from > > > the community. > > > > > > Thanks, > > > Rajan > > > > > > On Thu, Aug 18, 2022 at 8:27 AM PengHui Li <peng...@apache.org> wrote: > > > > > > > Hi all, > > > > > > > > Currently, the new proposal will be added to the issue list and then > > > shared > > > > link in the email > > > > to request the proposal review. It's really hard to review a long > > > proposal > > > > if you want to comment > > > > in detail. > > > > > > > > Here is an example: > > > > https://github.com/apache/pulsar/issues/16763#issuecomment-1219606491 > > > > This seems very unintuitive. > > > > > > > > I think we can move all the PIPs to the codebase and the new proposal > > > > and > > > > proposal without > > > > any reviews should happen with a PR first. So that we can review and > > > > comment easily. > > > > Certainly, all the votes should happen on the mailing list. And we can > > > also > > > > discuss the > > > > proposal on the mailing list. > > > > > > > > Following this way, we don't need to sync the PIPs from the issue to the > > > > wiki page. > > > > We can just add a link that points to the PIPs dir to the contribution > > > > guide or README. > > > > > > > > We have another pain point about the duplicated PIP number. We can > > > maintain > > > > a file, a list of > > > > all the proposal contains the approved, in-review, drafting. Before > > > > creating a proposal, we should > > > > have a discussion first on the mailing list, just get feedback on the > > > > motivation. If there are no objections, > > > > the proposal owner can add a line to the file with the PIP number > > > through a > > > > PR, like PIP-123: xxx (Under Discussion). > > > > So that we can prevent the duplicated PIP number(which will conflict if > > > > someone merged first). > > > > After the PR is merged, we can send out a new PR to add the proposal. > > > > > > > > Thanks, > > > > Penghui > > > > > > >
