Hi Dave, > Let’s outline how PIPs are currently working and then discuss changes.
Yes, I will prepare for the changes. This is the documentation for how PIPs are currently working: https://github.com/apache/pulsar/pull/17270/files#diff-a56445d038f8a3df4c74724076c62437915f091437b4e26a1c5aada7184dcffd The mailing list discussion: https://lists.apache.org/thread/m8dr0hz7qn7rkd48bcp430lcq2q3674g Anyway, I will start a new discussion with the new changes to the current process. > I’m not sure what is meant by putting the PIP into the “codebase”. > Is the proposal to create PIPs here? https://github.com/apache/pulsar/tree/master/wiki Just move out from https://github.com/apache/pulsar/tree/master/wiki to Pulsar codebase /wiki/proposals > I think that a directory structure / convention could be used for pip status: > 1. /wiki/pip/discussion - for PIPs being discussed and specified. > 2. /wiki/pip/proposed - for PIPs ready to be formally DISCUSSED and VOTED > 3. /wiki/pip/accepted - for PIPs that have been accepted and are works in progress > 4. /wiki/pip/complete - for PIPs that have been completed. > 5. /wiki/pip/rejected - for PIPs that were proposed, but then rejected or abandoned. I think it's a good point, I don't see any obvious cons. Thanks, Penghui On Thu, Aug 25, 2022 at 11:40 PM Dave Fisher <w...@apache.org> wrote: > > > On Aug 23, 2022, at 10: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. > > Agreed let’s have a PIP Discussion here to carefully outline how the PIP > process will change. I don’t think that a new PIP should be overly planned > or implemented before the idea is more fully discussed and accepted. The > Apache Way always works best with small incremental and reversible steps. > > Let’s outline how PIPs are currently working and then discuss changes. I’m > not sure what is meant by putting the PIP into the “codebase”. > > Is the proposal to create PIPs here? > https://github.com/apache/pulsar/tree/master/wiki > > I think that a directory structure / convention could be used for pip > status: > > 1. /wiki/pip/discussion - for PIPs being discussed and specified. > 2. /wiki/pip/proposed - for PIPs ready to be formally DISCUSSED and VOTED > 3. /wiki/pip/accepted - for PIPs that have been accepted and are works in > progress > 4. /wiki/pip/complete - for PIPs that have been completed. > 5. /wiki/pip/rejected - for PIPs that were proposed, but then rejected or > abandoned. > > Regards, > Dave > > > > > 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 > >> > >
