Zongyang, Thank you for reaching out to Pulsar community.
In general, PIP is used for proposing new features, improvements and user impact changes. However I don't think Pulsar community has defined any strict rules for people submitting PIP. The general rule for PIP is for people in the community to communicate what are the "big" changes are coming into Pulsar release. We'd love to collect feedback from the community to improve the PIP process. Other comments inline. On Tue, Aug 7, 2018 at 12:29 AM Xiao Zongyang <xiaozongyang_b...@qq.com> wrote: > Hi Pulsar Community! > > > Zongyang, here! > > > I'm now reading PIP(Pulsar Improvement Proposal) on github. And I am a > little confused about how PIP works and what are the principles of PIP. > > > Disscused in more details, the actual problems are: > > > 1. Do we need a State of PIP named released, which means the proposal has > been implemented but is coming in next release? > Ideally we should have a field in the PIP about what release this PIP has been shipped. I have tried to update those PIPs with correct release labelled. > 2. What is the boundary between providing a proposal of changes and not? > Do we have some principles to obey? > - New features - Improvements - Protocol changes (adding new proto commands) - API changes I think protocol and API changes have to be a PIP, since the change has huge-enough impact to all the users of Pulsar. However for others, I don't think there is a strict rule for it. Although we recommend people to write PIP for new features and improvements. Baseline is if you think your change requires some discussions from community, it is a PIP. Otherwise it can go with regular pull requests. > 3. What is the lifecycle of a PIP? How does the process of PIP works? > What will we do for transforming the PIP from one State to the next? > We don't have any official vote process for PIP. We are kind of treating a feature is accepted if there is no objection in the community after PIP is sent out. You know engineers are just lazy :) > 4. The KIP(Kafka Improvement Proposal) has a section "Compatibility, > Deprecation, and Migration Plan" when describes the effect of existing > users. It seems that we don't include that section, what are the > considerations behind this? > Yes. If a PIP impacts users, it has to document "Compatibility and Migration Plan". We don't have a template for people to follow. But when a PIP is sent out and if this feature requires considering compatibility and migration plans, people in the community will request it. As I said, we are still improving our process. If you have any idea on helping us improving the process, feel free to contribute at this area. for example, maybe you can help us drafting a process for PIP or a template for PIP.= Hope this helps. > > Thank you guys to answering my questions! > > > Best Regards Zongyang
