> These tags are clear. Is there any existing document for what the
labels represent? If not, we'd better create one.

I think no, maybe we can have a page for Committers under the Community tab
[image: image.png]

Regards,
Penghui


On Mon, Aug 21, 2023 at 2:29 PM Yubiao Feng
<yubiao.f...@streamnative.io.invalid> wrote:

> @Penghui
>
> It feels great, and it's really helpful for the community to sift through
> highlighting PRs
>
> Thanks
> Yubiao
>
>
>
> On Mon, Aug 21, 2023 at 12:28 PM PengHui Li <peng...@apache.org> wrote:
>
> > Sorry, accidentally clicked send button :), please ignore the previous
> > email.
> >
> > Hi all,
> >
> > I would like to start a discussion about adding a new label type
> category/*
> > There are three labels are supposed to be added
> >
> > - category/functionality
> > - category/reliability
> > - category/performance
> >
> > It could be a good improvement to the labeling system that Pulsar has
> > today.
> > Now, Pulsar mainly have four label categories
> >
> > - type/* - type/bug, type/feat ...
> > - component/* - component/authentication, component/broker ...
> > - release/* - release/3.0.2, release/3.1.1 ...
> > - cherry-picked/* - cherry-picked/branch-3.0, cherry-picked/branch-3.1
> ...
> >
> > type/* is mainly distinguish the issues and PRs are for bug reporting,
> bug
> > fix,
> > feature requests, feature support.
> >
> > component/*, you can know the issues and PRs are happened on which
> > component with the component labels, such as an issue with type/bug and
> > component/broker means it's a bug report for the broker component.
> >
> > release/* labels are indicating which version the issue/PR has been fixed
> > or will be fixed depending on if the version is released or not.
> >
> > cherry-picked/* labels are more mainly for Pulsar committers to ensure
> the
> > fixes are cherry-picked to the release branches. The label only can be
> > added
> > after the cherry-picking is done for a corresponding branch. So that the
> > release
> > manager can have a list of PRs that should to be cherry-picked.
> >
> > But, In addition to being able to identify which component that the
> issue,
> > PR
> > is fixed or enhanced. The category labels will provide more information
> > about
> > the fix or enhancement for functionality, reliability, or performance.
> For
> > most
> > cases, the category labels only work with type/bug and type/enhancement.
> >
> > - category/functionality,  some functions are not working, such as
> getting
> > errors.
> > - category/reliability, the function is working for most cases. It does
> not
> > work
> >                                properly in certain specific environments
> or
> > failures. e.g.
> >                                data lost, consumption stuck ...
> > - category/performance, performance issues fix or improvements.
> >
> > Regards,
> > Penghui
> >
> > On Mon, Aug 21, 2023 at 12:22 PM PengHui Li <peng...@apache.org> wrote:
> >
> > > Hi all,
> > >
> > > I would like to start a discussion about adding a new label type
> > category/*
> > > There are three labels are supposed to be added
> > >
> > > - category/functionality
> > > - category/reliability
> > > - category/performance
> > >
> > > It could be a good improvement to the labeling system that Pulsar has
> > > today.
> > > Now, Pulsar mainly have four label categories
> > >
> > > - type/* - type/bug, type/feat ...
> > > - component/* - component/authentication, component/broker ...
> > > - release/* - release/3.0.2, release/3.1.1 ...
> > > - cherry-picked/* - cherry-picked/branch-3.0, cherry-picked/branch-3.1
> > ...
> > >
> > > type/* is mainly distinguish the issues and PRs are for bug reporting,
> > bug
> > > fix,
> > > feature requests, feature support.
> > >
> > > component/*, you can know the issues and PRs are happened on which
> > > component with the component labels, such as an issue with type/bug and
> > > component/broker means it's a bug report for the broker component.
> > >
> > > release/* labels are indicating which version the issue/PR has been
> fixed
> > > or will be fixed depending on if the version is released or not.
> > >
> > > cherry-picked/* labels are more mainly for Pulsar committers to ensure
> > the
> > > fixes are cherry-picked to the release branches. The label only can be
> > > added
> > > after the cherry-picking is done for a corresponding branch. So that
> the
> > > release
> > > manager can have a list of PRs that should to be cherry-picked.
> > >
> > > But, In addition to being able to identify which component that the
> > issue,
> > > PR
> > > is fixed or enhanced. The category labels will provide more information
> > > about
> > > the fix or enhancement for functionality, reliability, or performance.
> > For
> > > most
> > > cases, the category labels only work with type/bug and
> type/enhancement.
> > >
> > > - category/functionality,  some functions are not working such as get
> > > errors.
> > > - category/reliability, the functions is working for most cases. It
> does
> > > not work
> > > properly in certain specific environments or failures
> > >
> > >
> > >
> > >
> >
>

Reply via email to