Hi all, I have pushed out a PR https://github.com/apache/pulsar/pull/17270 which wants to copy the PIP and proposal template to the codebase.
The PR doesn't want to make some changes to the proposal process before we have approval. Since we will make some changes to the current PIP process, I want to copy the old one to the codebase so that all the subsequent updates will have historical records. Finally, the PIP process changes should be done with a new VOTE email. With https://github.com/apache/pulsar/pull/17270, we can have a PR to show all the details which can help the reviewer to easily review. Thanks, Penghui On Thu, Aug 25, 2022 at 12:57 PM tison <wander4...@gmail.com> wrote: > Hi Penghui, > > > IMO, the final status of the proposal should be summarized in the > proposal. > > Agree. It's not exclusive. What I propose is that if you want to track > proposals in a project, track issues. But it seems your opinion is not to > do so. Then it's a nonissue. Flink FLIP tracks proposal status with the > proposal content and it works well. Although, I'd still highlight that > maintainer efforts are required to maintain the metadata. > > > As I know, if we have an issue tracking all the proposal status, not all > the contributors make contributions. Only the committers and the author? > > I don't propose to track the status _within_ the issue. But if you want to > track in a project, only committer have the privilege :) > > > if the discussion of the motivation doesn't have objections and is > discussed enough. > > This is quite vague and hard to follow. > > Rust RFCs have a nonmandatory pre-RFC stage. I think we can encourage the > proposer to discuss on the mailing list or any channel with committers > first. But any proposer can take their proposal number once proposed and a > committer clicks the merge button. Still, I'm concerned about adding such a > step to exclusively allocate a proposal number. > > I would suggest you collect the suggestions in this discussion thread, and > propose a process as shown in > > * https://github.com/rust-lang/rfcs#readme > * https://github.com/pingcap/tidb/tree/master/docs/design#readme > > So that we can have a vote. Instead of rushing into making several PRs to > move content fragmentedly. > > Best, > tison. > > > PengHui Li <peng...@apache.org> 于2022年8月25日周四 10:59写道： > > > Hi Tison, > > > > Thanks for providing more context. > > > > > Rust RFCs hold in a separate repo so that they can use the PR number as > > the > > proposal number to prevent duplicates. It's a bit overhead for Pulsar to > > hold a separate repo. So I'd prefer to hold proposals in the same repo > > under the dev/proposals folder and resolve the PR number duplicates issue > > as described above. Although, it can still be a bit awkward. But at least > > we can quickly notice duplicate numbers and resolve them. Using the PR > > number as the proposal number keeps it unique, but the number will be > > discontinuous. Especially if we're proposing in the main repo, the number > > will grow quickly. > > > > The PR number can provide unique numbers. Everyone can create PRs, maybe > > not related to PIP, but we are not able to revert it. > > > > > In this direction, we can associate a proposal with a tracking issue > and > > manipulate the proposal status represented by their tracking issue. It > > doesn't mean we keep the current issue discussion process. You can regard > > it as an umbrella ticket for the proposal. See > > https://github.com/pingcap/tidb/issues/26022 as an example. > > > > > In this direction, we should always ensure that there're several eyes > on > > the project. Otherwise, we can easily end up with an out-of-sync project. > > > > IMO, the final status of the proposal should be summarized in the > proposal. > > We can have some metadata for md file which allow us to have a page that > > can > > show all the proposals like the bookkeeper does > > https://bookkeeper.apache.org/community/bookkeeper-proposals > > From my personal view, I prefer this way of the bookkeeper. This will > allow > > all the users find the proposals on the website, instead of going to > search > > in the > > issue list. > > > > And the md file is the source of the truth. I think we can only provide > one > > way to > > update the proposal status (from a PR). So that all the contributors can > > contribute. > > As I know, if we have an issue tracking all the proposal status, not all > > the contributors > > make contributions. Only the committers and the author? Maybe the author > > can change > > the policy but still can't involve more people to review. > > > > > It seems the confusion comes from we have to merge one PR first to > > prevent > > duplicate numbers. If it's a certain concern, see also my comment above > > using the PR number as the proposal, or even host a separate proposal > repo > > as rust-lang/rfcs does and keep the number growing normally. I can > provide > > experience to maintain this sort of resource. > > > > Yes, it looks to request a PIP number through a PR. IMO, it is necessary. > > The reviewer can only merge the PR (request the PIP number) if the > > discussion > > of the motivation doesn't have objections and is discussed enough. > > Without this step, maybe only the author thinks that "I can create a > > proposal for now" (maybe > > no response on the mailing list). > > > > Best, > > Penghui > > > > On Thu, Aug 25, 2022 at 10:31 AM PengHui Li <peng...@apache.org> wrote: > > > > > > So that we can review the details and improve these 2 documents (I > see > > > the last update > > > for these two documents are 2021 and 2020) > > > > > > Sorry, I think it's not a good idea. > > > 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. > > > > > > Penghui > > > > > > > > > On Thu, Aug 25, 2022 at 10:28 AM PengHui Li <peng...@apache.org> > wrote: > > > > > >> Hi Michael, > > >> > > >> > 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. > > >> > > >> Yes, I think it's a good idea. IMO, we can migrate them one by one. > > >> To provide more context for each one like the discussion email, vote > > email > > >> , and the approvals (Of course, very early proposals did not require > > >> approval). > > >> So that all the contributors can help with the migration process. > > >> > > >> I think I can move [0] [1] to the codebase first. > > >> > > >> [0] > > >> > > > https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-Template > > >> [1] > > >> > > > https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-%28PIP%29 > > >> > > >> So that we can review the details and improve these 2 documents (I see > > >> the last update > > >> for these two documents are 2021 and 2020) > > >> > > >> Thanks, > > >> Penghui > > >> > > >> On Thu, Aug 25, 2022 at 9:44 AM tison <wander4...@gmail.com> wrote: > > >> > > >>> Hi Penghui, > > >>> > > >>> Thanks for starting this discussion! +1 for holding PIPs in the > > codebase. > > >>> > > >>> I'd like to share some experience working on open-source projects > > holding > > >>> proposals as code. > > >>> > > >>> 1. Rust RFCs: codebase https://github.com/rust-lang/rfcs > > >>> 2. TiDB Proposals: > > >>> https://github.com/pingcap/tidb/tree/master/docs/design#readme > > >>> > > >>> Reflect on topics in this thread: > > >>> > > >>> > any reviews should happen with a PR first > > >>> > > >>> The experience should be similar to reviewing on Google Docs while > > >>> keeping > > >>> all conversations on GitHub and thus synced on the mailing list. You > > can > > >>> preview can some examples: > > >>> > > >>> * https://github.com/pingcap/tidb/pull/23673 > > >>> * https://github.com/rust-lang/rfcs/pull/42 > > >>> > > >>> Furthermore, continuous follow-up like PIP-198 can discuss > > implementation > > >>> details and update the proposal content one PR by another. The > downside > > >>> is > > >>> that even trivial typo fixes should go through a PR. > > >>> > > >>> > Certainly, all the votes should happen on the mailing list. > > >>> > > >>> Yes. We should have an explicit [VOTE] and [RESULT][VOTE] thread on > the > > >>> mailing list while keeping a reference within the proposal content. > We > > >>> can > > >>> port the current PIP issue template to a proposal template as Rust > RFCs > > >>> to > > >>> highlight it. > > >>> > > >>> > We can just add a link that points to the PIPs dir to the > > contribution > > >>> guide > > >>> or README. > > >>> > > >>> Rust RFCs hold in a separate repo so that they can use the PR number > as > > >>> the > > >>> proposal number to prevent duplicates. It's a bit overhead for Pulsar > > to > > >>> hold a separate repo. So I'd prefer to hold proposals in the same > repo > > >>> under the dev/proposals folder and resolve the PR number duplicates > > issue > > >>> as described above. Although, it can still be a bit awkward. But at > > least > > >>> we can quickly notice duplicate numbers and resolve them. Using the > PR > > >>> number as the proposal number keeps it unique, but the number will be > > >>> discontinuous. Especially if we're proposing in the main repo, the > > number > > >>> will grow quickly. > > >>> > > >>> > Should we track the status of PIPs as a project? > > >>> > > >>> In this direction, we can associate a proposal with a tracking issue > > and > > >>> manipulate the proposal status represented by their tracking issue. > It > > >>> doesn't mean we keep the current issue discussion process. You can > > regard > > >>> it as an umbrella ticket for the proposal. See > > >>> https://github.com/pingcap/tidb/issues/26022 as an example. > > >>> > > >>> In this direction, we should always ensure that there're several eyes > > on > > >>> the project. Otherwise, we can easily end up with an out-of-sync > > project. > > >>> > > >>> To @Rajan @Penghui > > >>> > > >>> It seems the confusion comes from we have to merge one PR first to > > >>> prevent > > >>> duplicate numbers. If it's a certain concern, see also my comment > above > > >>> using the PR number as the proposal, or even host a separate proposal > > >>> repo > > >>> as rust-lang/rfcs does and keep the number growing normally. I can > > >>> provide > > >>> experience to maintain this sort of resource. > > >>> > > >>> > > >>> Best, > > >>> tison. > > >>> > > >> > > >
