> > The problem I thought of not merging the PR proposal is the proposal looks > like the proposed changes never end. The author can continue to update > after approved. I don't want to say all the changes to the proposal need to > be voted on > the mailing list, but we should get a chance to review the changes. >
I guess that by converting the PIP from issue to PR you're forcing a review of any changes, right, especially PIPs that were already approved there by making sure no drastic changes are being made. On Mon, Aug 29, 2022 at 6:33 PM PengHui Li <peng...@apache.org> wrote: > > The only point worth attending to while drafting the new process is how > to > avoid neglected out-of-date proposals. If a proposal was declined, who is > in charge to update its status in the readme? > > That is a good point. IMO, everyone is able to correct the proposal status. > It wasn't easy for us before, only the committer could update the wiki > page. > Of course, in most cases, it is done by the author. But this is not 100% > guaranteed. > We should add this part to the proposal process. > > > There is something appealing in not merging a PR proposal, as this status > update takes care of itself (borrowing from rust RFC). > > The problem I thought of not merging the PR proposal is the proposal looks > like the proposed changes never end. The author can continue to update > after approved. I don't want to say all the changes to the proposal need to > be voted on > the mailing list, but we should get a chance to review the changes. > > Thanks, > Penghui > > On Mon, Aug 29, 2022 at 10:45 PM Asaf Mesika <asaf.mes...@gmail.com> > wrote: > > > I like the idea of keeping the suggestions as files in the repo since as > > you mentioned, it makes the review process using PRs much more > streamlined. > > > > I think keeping the status in an MD file and only there (having a single > > source of truth) will make it less error-prone (people might forget to > move > > between directories) , and also easier to have a single page to view all > > proposals. > > > > The only point worth attending to while drafting the new process is how > to > > avoid neglected out-of-date proposals. If a proposal was declined, who is > > in charge to update its status in the readme? > > There is something appealing in not merging a PR proposal, as this status > > update takes care of itself (borrowing from rust RFC). > > > > One bonus item is that I learned through this long discussion thread > about > > Zulip chat :) > > > > > > > > On Mon, Aug 29, 2022 at 1:55 PM PengHui Li <peng...@apache.org> wrote: > > > > > Hi all, > > > > > > I will merge https://github.com/apache/pulsar/pull/17270 first and > > draft a > > > proposal for > > > the detailed PIP process changes. And will start a new VOTE thread for > > the > > > PIP process change. > > > > > > After the proposal(for PIP process change) is approved. I will go back > > here > > > to discuss > > > how to migrate the old PIPs to the codebase(because we need to follow > > > the new format of PIPs). > > > > > > Thanks, > > > Penghui > > > > > > On Fri, Aug 26, 2022 at 11:20 PM PengHui Li <peng...@apache.org> > wrote: > > > > > > > > Using a directory structure to organize PIP status might make the > git > > > > history a bit less direct because changing state is equivalent with a > > > > file move instead of a line updated in a file. However, if we do it > > > > that way, we could have a README.md file organizing PIP metadata and > > > > linking to the actual PIP file in the directory structure. That > > > > README.md would also serve as the source of truth for PIP numbers > > > > because each PIP pointer would get its associated line number. Then, > > > > concurrent PIPs would need to resolve merge conflicts just before > > > > merging and only then would they acquire their number. > > > > > > > > Oh, get your point, Michael. I think this solution looks better. We > can > > > > also > > > > add something in README.md and users can also get the complete > > > > proposal list here. In the future, maybe we can show it on the > website. > > > > > > > > Best, > > > > Penghui > > > > > > > > On Fri, Aug 26, 2022 at 12:16 PM Michael Marshall < > > mmarsh...@apache.org> > > > > wrote: > > > > > > > >> > We should move to the codebase 100% the same as the original > > > >> documentation. > > > >> > And use another PR to make improvements for it. If it is needed, > we > > > >> should > > > >> > start with an email. > > > >> > We need to have historical records. > > > >> > > > >> +1 I think this is a great idea. It makes sense to copy them > verbatim > > > >> and then worry about updating them in a second step. > > > >> > > > >> Using a directory structure to organize PIP status might make the > git > > > >> history a bit less direct because changing state is equivalent with > a > > > >> file move instead of a line updated in a file. However, if we do it > > > >> that way, we could have a README.md file organizing PIP metadata and > > > >> linking to the actual PIP file in the directory structure. That > > > >> README.md would also serve as the source of truth for PIP numbers > > > >> because each PIP pointer would get its associated line number. Then, > > > >> concurrent PIPs would need to resolve merge conflicts just before > > > >> merging and only then would they acquire their number. > > > >> > > > >> - Michael > > > >> > > > >> On Thu, Aug 25, 2022 at 9:15 PM PengHui Li <peng...@apache.org> > > wrote: > > > >> > > > > >> > 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 > > > >> > > > > >> > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > >
