Hi Xiangying, > We can classify the pips under these folders according to the pulsar modules, instead of just placing these pips under these folders in an incrementing sequence number.
I think it's not easy to do this. A proposal can have changes related to multiple modules(Broker, Metadata, Client). Thanks, Penghui On Fri, Aug 26, 2022 at 9:20 AM Xiangying Meng <xiangy...@apache.org> wrote: > Hi Penghui > Thanks for you start this discussion. IMO, It is also a good way for > beginners to learn the design and implementation of each module of Pulsar. > > 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. > We can classify the pips under these folders according to the pulsar > modules, instead of just placing these pips under these folders in an > incrementing sequence number. > > In this way, readers can create a new local branch dedicated to reading and > annotating proposals for themselves to read proposals they are interested > in and write their own understanding and comments anytime and anywhere. > Thanks, > Xiangying Meng > > On Fri, Aug 26, 2022 at 12:23 AM PengHui Li <peng...@apache.org> wrote: > > > 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 > > > >> > > > > > > > > >
