+1 from me. (I've always been a supporter of having PIPs in codebase) Le mer. 24 août 2022 à 18:04, Michael Marshall <mmarsh...@apache.org> a écrit :
> 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 > > > > > > > > > >
