Analysis of impact of most recent Log4j CVE, CVE-2021-45046 to Pulsar
There's a new CVE, CVE-2021-45046 in Log4j < 2.16.0
details:
https://blogs.apache.org/foundation/entry/apache-log4j-cves
Summary:
Pulsar isn't impacted with CVE-2021-44228 when the default log4j
configuration is used.
However, remember that Pulsar is impacted by the actual Log4Shell CVE and
Pulsar users should patch immediately. Patching instructions in the blog
post https://pulsar.apache.org/blog/2021/12/11/Log4j-CVE/ .
You can patch previous Docker images to upgrade to Log4j 2.16.0 with the
solution in
https://github.com/lhotari/pulsar-docker-images-patch-CVE-2021-44228 . That
could be used to address both CVEs for old Pulsar releases. If you are
running old Pulsar versions, please note that Pulsar <2.6.4 or 2.7.0
contain a severe Pulsar specific CVE
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22160 .
Detailed analysis of impact of CVE-2021-45046 to Pulsar:
Description of CVE-2021-45046,
https://logging.apache.org/log4j/2.x/security.html#cve-2021-45046
> It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0
> was incomplete in certain non-default configurations. This could allows
> attackers with control over Thread Context Map (MDC) input data when the
> logging configuration uses a non-default Pattern Layout with either a
> Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map
> pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI
> Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0
> restricts JNDI LDAP lookups to localhost by default. Note that previous
> mitigations involving configuration such as to set the system property
> log4j2.noFormatMsgLookup to true do NOT mitigate this specific
> vulnerability.
In Pulsar Log4J configuration (conf/log4j2.yaml), context lookup or thread
context map patterns are: $${ctx:function} , $${ctx:instance} and
%X{instance} .
These are only used in Pulsar when running Functions in Thread runtime.
The user could impact the function name, but ${ are not valid characters
for any names in Pulsar. Therefore, Pulsar isn't impacted with
CVE-2021-44228 when the default log4j configuration is used.
Source code references:
This is where the thread context map is set in Pulsar Function instances:
https://github.com/apache/pulsar/blob/7bf14b5ac049d71c7ff74bbe758cb41aaffeb0af/pulsar-functions/instance/src/main/java/org/apache/pulsar/functions/instance/JavaInstanceRunnable.java#L179-L182
Pulsar name validation pattern:
https://github.com/apache/pulsar/blob/7bf14b5ac049d71c7ff74bbe758cb41aaffeb0af/pulsar-common/src/main/java/org/apache/pulsar/common/naming/NamedEntity.java#L31-L34
BR,
Lari
Re: [PIP-78] Reduce redundant producers from partitioned producer
Enrico, Thank you for your clarification. > I would add a configuration parameter to allow the client to use this > feature. > So: > - feature enabled -> everything works like in your patch > - feature disabled -> the broker ignores *partial_producer_supported *and > runs as before Okay. That makes sense to me. If you have no more concerns, I'll fix the change to address your comments. Regards, -- Yuri Mizushima yumiz...@yahoo-corp.jp On 2021/12/14 19:01, "Enrico Olivelli" wrote: sorry for the late reply, I missed this message. Il giorno mar 7 dic 2021 alle ore 05:56 Yuri Mizushima < yumiz...@yahoo-corp.jp> ha scritto: > Enrico, > Thank you for your comment. > > > IIUC with this change the client will control which metrics are reported > by > > the broker ? > > From the protocol perspective, yes. > However, the main point of this change is not to "control" metrics by the > client side, > but to make the broker aggregate partitioned topic's producer metrics > explicitly. > > Do you suggest adding a broker config that > configures whether partitioned producer stats are aggregated by > producerName instead of > introducing a backward compatibility key (i.e., > partial_producer_supported) on the client-side? > Not exactly. I would add a configuration parameter to allow the client to use this feature. So: - feature enabled -> everything works like in your patch - feature disabled -> the broker ignores *partial_producer_supported *and runs as before This way if you want to let the client aggregate the stats you can do it but by default clients are not able to interact with the metrics format. In multi-tenancy environments, like in large clusters shared by many teams, you do not want that the client is able to change the way the broker reports its metrics or in general that the client is able to alter the monitoring systems. Enrico > > It is simple. However, I think we can't enable the config until all > clients are updated. > > What do you think? > Regards, > -- > Yuri Mizushima > yumiz...@yahoo-corp.jp > > > On 2021/12/02 17:37, "Enrico Olivelli" wrote: > > Yuri, > IIUC with this change the client will control which metrics are > reported by > the broker ? > > I am not sure it is a good idea, because metrics are usually managed > by the > owners of the brokers, who sometimes are not the same who run the > clients. > > Also, I am not sure if this way it is possible for the client to force > the > Broker to create many metrics and create some kind of damage. > > Would it be better to add a Broker configuration flag to turn on this > feature ? I mean to allow the client to select the type of metrics ? > > > Enrico > > > Il giorno gio 2 dic 2021 alle ore 03:00 Yuri Mizushima < > yumiz...@yahoo-corp.jp> ha scritto: > > > Do you have any comments? > > If there are no comments by Dec. 7, I will close the discussion and > rebase > > the PR commit to current master. > > > > Regards, > > > > -- > > Yuri Mizushima > > yumiz...@yahoo-corp.jp > > > > > > On 2021/11/16 15:46, "Yuri Mizushima" > wrote: > > > > Dear Pulsar community, > > > > I have created a new PR > > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fpulsar%2Fpull%2F12401&data=04%7C01%7Cyumizush%40yahoo-corp.jp%7C14ab44acc2be4e8cd90e08d9bee8bf9b%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637750729124731851%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=POhcguG9KtlOMqyrdZtiLD9KKBGYDBfbDiq8g88cKAo%3D&reserved=0 > > for stats aggregation, > > but I didn't discuss about the wire protocol change. I hope we > will > > discuss it here. > > > > Currently, partitioned producer can't aggregate by any key such > as > > cnx, producerId, producerName, and so on. > > I think we need to add any aggregation system. > > Therefore, added new aggregation policy as producerName (with > client > > side implementation). > > > > New protocol field partial_producer_supported is not used for > stats > > aggregation. It is used for backward compatibility. > > > > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fpulsar%2Fpull%2F12401%2Ffiles%23diff-f29399fed32e0916cf28452ba71078a3ae5ed77bbaef9f52a925165d8ee66cfdR489&data=04%7C01%7Cyumizush%40yahoo-corp.jp%7C14ab44acc2be4e8cd90e08d9bee8bf9b
Re: [VOTE] Apache Pulsar 2.8.2 candidate 1
-1, I verified the packages, but the signatures are invalid. It looks like the https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.8.2-candidate-1/apache-pulsar-2.8.2-bin.tar.gz.asc file is from December 1st. I checked this in the SVN staging repository history ( https://dist.apache.org/repos/dist/dev/pulsar) . The command I used: svn log https://dist.apache.org/repos/dist/dev/pulsar -v |less It seems that signatures and hashes were added in "r51152 | linlin | 2021-12-01 06:03:42 +0200 (Wed, 01 Dec 2021)". The newer change "r51361 | linlin | 2021-12-13 15:19:12 +0200 (Mon, 13 Dec 2021)" didn't update the signatures and hashes. Lin Lin, please check. -Lari On Tue, Dec 14, 2021 at 5:26 AM linlin wrote: > This is the first release candidate for Apache Pulsar, version 2.8.2. > > It fixes the following issues: > > https://github.com/apache/pulsar/issues?q=label%3Acherry-picked%2Fbranch-2.8+is%3Aclosed+label%3Arelease%2F2.8.2 > > *** Please download, test and vote on this release. This vote will stay > open > for at least 72 hours *** > > Note that we are voting upon the source (tag), binaries are provided for > convenience. > > Source and binary files: > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.8.2-candidate-1/ > > SHA-512 checksums: > > f51e93d5caa7ea4ec2616e096ca75dd71bccb475632ee5ff35d713b8f5112689d17315a1cd9350dd8f8f0bdc2e059be5fb179b2b8b3b39aae77e466103294683 > apache-pulsar-2.8.2-bin.tar.gz > > 8540641e76fb541f9dbfaff263946ed19a585266e5de011e78188d78ec4e1c828e8893eb2e783a1ebad866f5513efffd93396b7abd77c347f34ab689badf4fad > apache-pulsar-2.8.2-src.tar.gz > > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachepulsar-1108/ > > The tag to be voted upon: > v2.8.2-candidate-1 > https://github.com/apache/pulsar/releases/tag/v2.8.2-candidate-1 > > Pulsar's KEYS file containing PGP keys we use to sign the release: > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > Please download the source package, and follow the README to build > and run the Pulsar standalone service. > > Lin Lin >
Re: [VOTE] Apache Pulsar 2.8.2 candidate 1
On 2021/12/14 03:25:45 linlin wrote: > This is the first release candidate for Apache Pulsar, version 2.8.2. > > It fixes the following issues: > https://github.com/apache/pulsar/issues?q=label%3Acherry-picked%2Fbranch-2.8+is%3Aclosed+label%3Arelease%2F2.8.2 > > *** Please download, test and vote on this release. This vote will stay open > for at least 72 hours *** > > Note that we are voting upon the source (tag), binaries are provided for > convenience. > > Source and binary files: > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.8.2-candidate-1/ > > SHA-512 checksums: > f51e93d5caa7ea4ec2616e096ca75dd71bccb475632ee5ff35d713b8f5112689d17315a1cd9350dd8f8f0bdc2e059be5fb179b2b8b3b39aae77e466103294683 > apache-pulsar-2.8.2-bin.tar.gz > 8540641e76fb541f9dbfaff263946ed19a585266e5de011e78188d78ec4e1c828e8893eb2e783a1ebad866f5513efffd93396b7abd77c347f34ab689badf4fad > apache-pulsar-2.8.2-src.tar.gz > > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachepulsar-1108/ > > The tag to be voted upon: > v2.8.2-candidate-1 > https://github.com/apache/pulsar/releases/tag/v2.8.2-candidate-1 > > Pulsar's KEYS file containing PGP keys we use to sign the release: > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > Please download the source package, and follow the README to build > and run the Pulsar standalone service. > > Lin Lin > Sorry, I will check it again and start a new vote
Re: CheckStyle Rule Change
Maybe this has been discussed elsewhere, but if possible, we should
add a rule that to block any future log4shell type attack area.
In human terms, the rule should be:
Disallow any {log,logger,LOG}.* with a non-const first argument.
-Ivan
On Wed, Dec 15, 2021 at 7:15 AM Enrico Olivelli wrote:
>
> Il Mer 15 Dic 2021, 06:38 ZhangJian He ha scritto:
>
> > Hello everyone, I have added checkstyle on pulsar-metadata, and
> > UnusedImports check on test code. If your PR is involved in these two
> > situations. Please pull the master code. Thanks
> >
>
>
> Got it
>
> Thanks
> Enrico
>
> >
> > Thanks
> > ZhangJian He
> >
Re: CheckStyle Rule Change
Ignore this, looked further and it actually does double resolution. sheesh
On Wed, Dec 15, 2021 at 10:14 AM Ivan Kelly wrote:
>
> Maybe this has been discussed elsewhere, but if possible, we should
> add a rule that to block any future log4shell type attack area.
> In human terms, the rule should be:
> Disallow any {log,logger,LOG}.* with a non-const first argument.
>
> -Ivan
>
> On Wed, Dec 15, 2021 at 7:15 AM Enrico Olivelli wrote:
> >
> > Il Mer 15 Dic 2021, 06:38 ZhangJian He ha scritto:
> >
> > > Hello everyone, I have added checkstyle on pulsar-metadata, and
> > > UnusedImports check on test code. If your PR is involved in these two
> > > situations. Please pull the master code. Thanks
> > >
> >
> >
> > Got it
> >
> > Thanks
> > Enrico
> >
> > >
> > > Thanks
> > > ZhangJian He
> > >
Re: [DISCUSSION] PIP-117: Change Pulsar standalone defaults
+1 (non-binding) Out of the scope of this PIP, a follow up data migration tool could be added to help migration from old settings without data loss. --- Haiting On 2021/12/15 01:04:21 Hang Chen wrote: > +1 > > Thanks, > Hang > > PengHui Li 于2021年12月15日周三 07:52写道： > > > > +1 > > > > Penghui > > > > On Wed, Dec 15, 2021 at 1:18 AM Matteo Merli wrote: > > > > > https://github.com/apache/pulsar/issues/13302 > > > > > > Copying here for quoting convenience > > > > > > > > > > > > > > > > > > ## Motivation > > > > > > Pulsar standalone is the "Pulsar in a box" version of a Pulsar cluster, > > > where > > > all the components are started within the context of a single JVM process. > > > > > > Users are using the standalone as a way to get quickly started with Pulsar > > > or > > > in all the cases where it makes sense to have a single node deployment. > > > > > > Right now, the standalone is starting by default with many components, > > > several of > > > which are quite complex, since they are designed to be deployed in a > > > distributed > > > fashion. > > > > > > ## Goal > > > > > > Simplify the components of Pulsar standalone to achieve: > > > > > > 1. Reduce complexity > > > 2. Reduce startup time > > > 3. Reduce memory and CPU footprint of running standalone > > > > > > ## Proposed changes > > > > > > The proposal here is to change some of the default implementations that > > > are > > > used for the Pulsar standalone. > > > > > > 1. **Metadata Store implementation** --> > > > Change from ZooKeeper to RocksDB > > > > > > 2. **Pulsar functions package backend** --> > > > Change from using DistributedLog to using local filesystem, storing > > > the > > > jars directly in the data folder instead of uploading them into BK. > > > > > > 3. **Pulsar functions state store implementation** --> > > > Change the state store to be backed by a MetadataStore based backed, > > > with the RocksDB implementation. > > > > > > 4. **Table Service** --> > > > Do not start BK table service by default > > > > > > ## Compatibility considerations > > > > > > In order to avoid compatibility issues where users have existing Pulsar > > > standalone services that they want to upgrade without conflicts, we will > > > follow the principle of keeping the old defaults where there is existing > > > data on the disk. > > > > > > We will add a file, serving the purpose as a flag, in the > > > `data/standalone` > > > directory, for example `new-2.10-defaults`. > > > > > > If the file is present, or if the data directory is completely missing, we > > > will adopt the new set of default configuration settings. > > > > > > If the file is not there, we will continue to use existing defaults and we > > > will > > > not break the upgrade operation. > > > > > > > > > > > > > > > > > > -- > > > Matteo Merli > > > > > > >
Re: [DISCUSSION] PIP-120: Enable client memory limit by default
+1 (non-binding)
Haiting
On 2021/12/14 19:20:02 Matteo Merli wrote:
> https://github.com/apache/pulsar/issues/13306
>
>
> Pasted below for quoting convenience.
>
>
>
>
> ## Motivation
>
> In Pulsar 2.8, we have introduced a setting to control the amount of memory
> used by a client instance.
>
> ```java
> interface ClientBuilder {
> ClientBuilder memoryLimit(long memoryLimit, SizeUnit unit);
> }
> ```
>
> By default, in 2.8 and 2.9 this setting is set to 0, meaning no limit is being
> enforced.
>
> I think it's a good time for 2.10 to enable this setting by default and,
> correspondingly, to disable by default the producer queue size limit.
>
> This will simplify a lot the configuration that a producer application will
> have to come up with, when publishing with many topic/partitions or
> when messages
> are bigger than expected.
>
> ## Proposed changes
>
> In 2.10 release, for the `ClientBuilder`, change
> * `memoryLimit`: 0 -> 64 MB
>
> For the `ProducerBuilder`, changes
> * `maxPendingMessages`: 1000 -> 0
>
> 64MB is picked because it's a small enough memory size that will guarantee
> a very high producer throughput, irrespective of the individual messages size.
>
>
>
> --
> Matteo Merli
>
>
Re: PIP 116: Create Pulsar Writing Style Guide
+1, Great stuff. I am wondering if there is some tool to check it automatically? like code-style check. Thanks, Haiting On 2021/12/15 03:17:45 Yu wrote: > Hi Pulsar enthusiasts, > > > As you may notice, there are more and more documentation contributions > nowadays, which is great! > > > Similar to coding style guides, in the field of technical writing, a > writing style guide is a must to improve users' experience and eliminate > writers' workload. > > > To improve the doc quality, I create our style guide — *Pulsar Writing > Style Guide* [1] > > > # Definition > > > Pulsar Writing Style Guide contains a set of standards for writing and > designing content. > > > It helps maintain a consistent style, voice, and tone across Pulsar > documentation. > > > This guide is inspired by some existing style guides. It references *IBM > Style Guide*, *Chicago Manual of Style*, and other books for more > exhaustive guidance. > > > # Benefits > > > Pulsar Writing Style Guide can improve the content quality and bring many > benefits to users and writers like: > > > For users: > > - Make documentation easier to read > > - Reduce users’ cognitive load > > - Increase users' confidence in the content’s authority > > > For information developers: > > - Resolve arguments and support our needs to create readable, usable, and > minimalist information > > - Save time and trouble by providing a single reference for writing about > common topics, features, and more > > - Help write documentation in a clearer way and keep a consistent tone of > voice and style > > > >> > > > This guide is not a one-shot job, the current version is an initial draft. > I'll make continuous efforts on that. > > > I believe that the Pulsar community will welcome this addition to our > resources and profit from the instructions. > > > Feel free to comment, thanks. > > > [1] > https://docs.google.com/document/d/1lc5j4RtuLIzlEYCBo97AC8-U_3Erzs_lxpkDuseU0n4/edit# >
Re: [DISCUSSION] PIP-117: Change Pulsar standalone defaults
+1 @Haiting Pulsar Standalone is usually used for local development, I am not sure you need a migration tool. You can still keep the configuration to use previously (standalone.conf) Enrico Il giorno mer 15 dic 2021 alle ore 10:56 Haiting Jiang < jianghait...@apache.org> ha scritto: > +1 (non-binding) > > Out of the scope of this PIP, a follow up data migration tool could be > added to help migration from old settings without data loss. > > --- > Haiting > > On 2021/12/15 01:04:21 Hang Chen wrote: > > +1 > > > > Thanks, > > Hang > > > > PengHui Li 于2021年12月15日周三 07:52写道： > > > > > > +1 > > > > > > Penghui > > > > > > On Wed, Dec 15, 2021 at 1:18 AM Matteo Merli > wrote: > > > > > > > https://github.com/apache/pulsar/issues/13302 > > > > > > > > Copying here for quoting convenience > > > > > > > > > > > > > > > > > > > > > > > > ## Motivation > > > > > > > > Pulsar standalone is the "Pulsar in a box" version of a Pulsar > cluster, > > > > where > > > > all the components are started within the context of a single JVM > process. > > > > > > > > Users are using the standalone as a way to get quickly started with > Pulsar > > > > or > > > > in all the cases where it makes sense to have a single node > deployment. > > > > > > > > Right now, the standalone is starting by default with many > components, > > > > several of > > > > which are quite complex, since they are designed to be deployed in a > > > > distributed > > > > fashion. > > > > > > > > ## Goal > > > > > > > > Simplify the components of Pulsar standalone to achieve: > > > > > > > > 1. Reduce complexity > > > > 2. Reduce startup time > > > > 3. Reduce memory and CPU footprint of running standalone > > > > > > > > ## Proposed changes > > > > > > > > The proposal here is to change some of the default implementations > that are > > > > used for the Pulsar standalone. > > > > > > > > 1. **Metadata Store implementation** --> > > > > Change from ZooKeeper to RocksDB > > > > > > > > 2. **Pulsar functions package backend** --> > > > > Change from using DistributedLog to using local filesystem, > storing > > > > the > > > > jars directly in the data folder instead of uploading them > into BK. > > > > > > > > 3. **Pulsar functions state store implementation** --> > > > > Change the state store to be backed by a MetadataStore based > backed, > > > > with the RocksDB implementation. > > > > > > > > 4. **Table Service** --> > > > > Do not start BK table service by default > > > > > > > > ## Compatibility considerations > > > > > > > > In order to avoid compatibility issues where users have existing > Pulsar > > > > standalone services that they want to upgrade without conflicts, we > will > > > > follow the principle of keeping the old defaults where there is > existing > > > > data on the disk. > > > > > > > > We will add a file, serving the purpose as a flag, in the > `data/standalone` > > > > directory, for example `new-2.10-defaults`. > > > > > > > > If the file is present, or if the data directory is completely > missing, we > > > > will adopt the new set of default configuration settings. > > > > > > > > If the file is not there, we will continue to use existing defaults > and we > > > > will > > > > not break the upgrade operation. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Matteo Merli > > > > > > > > > > >
Re: Status of Pulsar 2.9.0 and starting 2.9.1
I had prepared the rc1 for 2.9.1 but today I added https://github.com/apache/pulsar/pull/13291 I will create a new RC and send a VOTE, possibly today The first RC will be rc2, in order to not mess up the git repository and the dist area Enrico Il giorno lun 13 dic 2021 alle ore 19:22 Sijie Guo ha scritto: > Thank you for sharing that! > > I think we should separate discussing a process from finishing a release. > In other words, we shouldn't block on a process in order to finish a > release. > > We should use the old process to finish a release while discussing a > process to improve the release notes process. > > - Sijie > > On Mon, Dec 13, 2021 at 10:04 AM Dave Fisher wrote: > > > > > > > > On Dec 13, 2021, at 9:57 AM, Sijie Guo wrote: > > > > > > I am fine with doing 2.9.1. > > > > > > I am trying to understand what happened between released 2.9.0 and > > > announcing it. > > > > > > It usually means there is a gap in the release process. We need to > solve > > > the process. If it is RM's responsibility for announcing the release, > it > > > should happen as soon as the release was cut. If the RM doesn't do it > in > > > time, other committers or PMC members should jump on it to help. I feel > > > something was held up somewhere. But I don't know what is going on > there. > > > > See the thread regarding release notes - > > https://lists.apache.org/thread/sszycc3zjxkdqd9x5f16108qn0x7w5g1 > > > > Regards, > > Dave > > > > > > - Sijie > > > > > > > > > > > > On Mon, Dec 13, 2021 at 9:47 AM Chris Herzog > > > > wrote: > > > > > >> I'm 100% with Dave. 2.9.0 is released (it's up on Maven), if it's not > > >> "announced", that's just a "publicity" effort because the 2.9.0 > release > > is > > >> out there. > > >> > > >> > > >> > > >> On Sun, Dec 12, 2021 at 11:34 PM Dave Fisher > > >> wrote: > > >> > > >>> (1) we have published 2.9.0 at > > >>> https://downloads.apache.org/pulsar/pulsar-2.9.0/ > > >>> > > >>> (2) we have published 2.9.0 artifacts through maven central. They > don’t > > >>> let anyone republish versions. > > >>> > > >>> There are no do overs on versions. We simply cannot redo 2.9.0 at > this > > >>> moment. > > >>> > > >>> All the best, > > >>> Dave > > >>> > > >>> Sent from my iPhone > > >>> > > On Dec 12, 2021, at 8:49 PM, Sijie Guo wrote: > > > > My take is - if we haven't announced 2.9, I would suggest just > > redoing > > >>> the > > 2.9.0 release. > > > > - Sijie > > > > > On Sun, Dec 12, 2021 at 6:35 PM Hang Chen > > >> wrote: > > > > > > I am a little confused about why we should skip 2.9.0 and not > > continue > > > to release 2.9.0 by including the critical bug fixes. In fact, the > > > Pulsar 2.9.0 release is not yet completed. > > > > > > For users, they will worry about whether the Pulsar release process > > is > > > standardized if we skip 2.9.0. They will also worry about the > release > > > quality of Apache Pulsar if we have found the critical bugs before > it > > > is released but not included it into the release version. For > Pulsar > > > 2.9.0, it couldn't be deployed into the production environment due > to > > > the critical bug https://github.com/apache/pulsar/pull/12993 > > > > > > Regards, > > > Hang > > > > > > Dave Fisher 于2021年12月13日周一 09:40写道： > > >> > > >> It can be the case that releases are not announced. For example > with > > > Tomcat a version which fails to pass the vote is skipped. > > >> > > >> Let’s not announce 2.9.0 and go on to 2.9.1. > > >> > > >> Maybe there’s some website fixes to hide 2.9.0. > > >> > > >> > > >> Sent from my iPhone > > >> > > >>> On Dec 12, 2021, at 5:28 PM, PengHui Li > > wrote: > > >>> > > >>> Another point is we have not announced the 2.9.0 release yet. > > >>> > > >>> This will make users feel confused that a new release from the > > >> Pulsar > > >>> community with the > > >>> serious problem(log4j bug) but after the log4j has fixed the > issue > > >> and > > >>> provided the new release. > > >>> > > >>> I think we'd better contain the fix in 2.9.0 and 2.9.0 also has a > > > critical > > >>> bug https://github.com/apache/pulsar/pull/12993 > > >>> which will lead the topic stop to provide services for more than > > >> 5min. > > > It > > >>> looks like, hey, we have a new release here but > > >>> it has critical security issues and known serious bugs which will > > > seriously > > >>> affect the core features. > > >>> > > >>> From the perspective of release, yes, the release vote has > closed. > > >> But > > > I > > >>> believe that users will not care about this matter, > > >>> they only care about the quality of the products we provided. > > >>> > > >>> I would like to hear your views. > > >>> > > >>> Regards, > > >>> Penghui > > >>> > > >>> > >
Does the #13291 should contains in 2.8.2
Hello, @LinLin @lipenghui I want to discuss if #13291 should contains in release 2.8.2. It's a compatible problem since 2.8, and we already commited it to master and branch 2.9 Thanks ZhangJian He
Re: Status of Pulsar 2.9.0 and starting 2.9.1
Hi Enrico, Thanks for your great work! I found 150+ PR labeled as `release/2.9.1`, but doesn't contain in v2.9.1-candidate-1 tag. Does those PRs release in next version? https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.1+-label%3Acherry-picked%2Fbranch-2.9+is%3Aclosed Thanks, Hang Enrico Olivelli 于2021年12月15日周三 19:19写道： > > I had prepared the rc1 for 2.9.1 > > but today I added https://github.com/apache/pulsar/pull/13291 > > I will create a new RC and send a VOTE, possibly today > > The first RC will be rc2, in order to not mess up the git repository and > the dist area > > Enrico > > Il giorno lun 13 dic 2021 alle ore 19:22 Sijie Guo ha > scritto: > > > Thank you for sharing that! > > > > I think we should separate discussing a process from finishing a release. > > In other words, we shouldn't block on a process in order to finish a > > release. > > > > We should use the old process to finish a release while discussing a > > process to improve the release notes process. > > > > - Sijie > > > > On Mon, Dec 13, 2021 at 10:04 AM Dave Fisher wrote: > > > > > > > > > > > > On Dec 13, 2021, at 9:57 AM, Sijie Guo wrote: > > > > > > > > I am fine with doing 2.9.1. > > > > > > > > I am trying to understand what happened between released 2.9.0 and > > > > announcing it. > > > > > > > > It usually means there is a gap in the release process. We need to > > solve > > > > the process. If it is RM's responsibility for announcing the release, > > it > > > > should happen as soon as the release was cut. If the RM doesn't do it > > in > > > > time, other committers or PMC members should jump on it to help. I feel > > > > something was held up somewhere. But I don't know what is going on > > there. > > > > > > See the thread regarding release notes - > > > https://lists.apache.org/thread/sszycc3zjxkdqd9x5f16108qn0x7w5g1 > > > > > > Regards, > > > Dave > > > > > > > > - Sijie > > > > > > > > > > > > > > > > On Mon, Dec 13, 2021 at 9:47 AM Chris Herzog > > > > > > wrote: > > > > > > > >> I'm 100% with Dave. 2.9.0 is released (it's up on Maven), if it's not > > > >> "announced", that's just a "publicity" effort because the 2.9.0 > > release > > > is > > > >> out there. > > > >> > > > >> > > > >> > > > >> On Sun, Dec 12, 2021 at 11:34 PM Dave Fisher > > > >> wrote: > > > >> > > > >>> (1) we have published 2.9.0 at > > > >>> https://downloads.apache.org/pulsar/pulsar-2.9.0/ > > > >>> > > > >>> (2) we have published 2.9.0 artifacts through maven central. They > > don’t > > > >>> let anyone republish versions. > > > >>> > > > >>> There are no do overs on versions. We simply cannot redo 2.9.0 at > > this > > > >>> moment. > > > >>> > > > >>> All the best, > > > >>> Dave > > > >>> > > > >>> Sent from my iPhone > > > >>> > > > On Dec 12, 2021, at 8:49 PM, Sijie Guo wrote: > > > > > > My take is - if we haven't announced 2.9, I would suggest just > > > redoing > > > >>> the > > > 2.9.0 release. > > > > > > - Sijie > > > > > > > On Sun, Dec 12, 2021 at 6:35 PM Hang Chen > > > >> wrote: > > > > > > > > I am a little confused about why we should skip 2.9.0 and not > > > continue > > > > to release 2.9.0 by including the critical bug fixes. In fact, the > > > > Pulsar 2.9.0 release is not yet completed. > > > > > > > > For users, they will worry about whether the Pulsar release process > > > is > > > > standardized if we skip 2.9.0. They will also worry about the > > release > > > > quality of Apache Pulsar if we have found the critical bugs before > > it > > > > is released but not included it into the release version. For > > Pulsar > > > > 2.9.0, it couldn't be deployed into the production environment due > > to > > > > the critical bug https://github.com/apache/pulsar/pull/12993 > > > > > > > > Regards, > > > > Hang > > > > > > > > Dave Fisher 于2021年12月13日周一 09:40写道： > > > >> > > > >> It can be the case that releases are not announced. For example > > with > > > > Tomcat a version which fails to pass the vote is skipped. > > > >> > > > >> Let’s not announce 2.9.0 and go on to 2.9.1. > > > >> > > > >> Maybe there’s some website fixes to hide 2.9.0. > > > >> > > > >> > > > >> Sent from my iPhone > > > >> > > > >>> On Dec 12, 2021, at 5:28 PM, PengHui Li > > > wrote: > > > >>> > > > >>> Another point is we have not announced the 2.9.0 release yet. > > > >>> > > > >>> This will make users feel confused that a new release from the > > > >> Pulsar > > > >>> community with the > > > >>> serious problem(log4j bug) but after the log4j has fixed the > > issue > > > >> and > > > >>> provided the new release. > > > >>> > > > >>> I think we'd better contain the fix in 2.9.0 and 2.9.0 also has a > > > > critical > > > >>> bug https://github.com/apache/pulsar/pull/12993 > > > >>> which will lead the topic stop
Re: Status of Pulsar 2.9.0 and starting 2.9.1
Il giorno mer 15 dic 2021 alle ore 12:52 Hang Chen ha scritto: > Hi Enrico, > Thanks for your great work! I found 150+ PR labeled as > `release/2.9.1`, but doesn't contain in v2.9.1-candidate-1 tag. Does > those PRs release in next version? > > https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.1+-label%3Acherry-picked%2Fbranch-2.9+is%3Aclosed > > In theory the answer is "yes", I am double checking. it is always an hard task Enrico > Thanks, > Hang > > Enrico Olivelli 于2021年12月15日周三 19:19写道： > > > > I had prepared the rc1 for 2.9.1 > > > > but today I added https://github.com/apache/pulsar/pull/13291 > > > > I will create a new RC and send a VOTE, possibly today > > > > The first RC will be rc2, in order to not mess up the git repository and > > the dist area > > > > Enrico > > > > Il giorno lun 13 dic 2021 alle ore 19:22 Sijie Guo > ha > > scritto: > > > > > Thank you for sharing that! > > > > > > I think we should separate discussing a process from finishing a > release. > > > In other words, we shouldn't block on a process in order to finish a > > > release. > > > > > > We should use the old process to finish a release while discussing a > > > process to improve the release notes process. > > > > > > - Sijie > > > > > > On Mon, Dec 13, 2021 at 10:04 AM Dave Fisher wrote: > > > > > > > > > > > > > > > > On Dec 13, 2021, at 9:57 AM, Sijie Guo wrote: > > > > > > > > > > I am fine with doing 2.9.1. > > > > > > > > > > I am trying to understand what happened between released 2.9.0 and > > > > > announcing it. > > > > > > > > > > It usually means there is a gap in the release process. We need to > > > solve > > > > > the process. If it is RM's responsibility for announcing the > release, > > > it > > > > > should happen as soon as the release was cut. If the RM doesn't do > it > > > in > > > > > time, other committers or PMC members should jump on it to help. I > feel > > > > > something was held up somewhere. But I don't know what is going on > > > there. > > > > > > > > See the thread regarding release notes - > > > > https://lists.apache.org/thread/sszycc3zjxkdqd9x5f16108qn0x7w5g1 > > > > > > > > Regards, > > > > Dave > > > > > > > > > > - Sijie > > > > > > > > > > > > > > > > > > > > On Mon, Dec 13, 2021 at 9:47 AM Chris Herzog > > > > > > > > > wrote: > > > > > > > > > >> I'm 100% with Dave. 2.9.0 is released (it's up on Maven), if > it's not > > > > >> "announced", that's just a "publicity" effort because the 2.9.0 > > > release > > > > is > > > > >> out there. > > > > >> > > > > >> > > > > >> > > > > >> On Sun, Dec 12, 2021 at 11:34 PM Dave Fisher < > wave4d...@comcast.net> > > > > >> wrote: > > > > >> > > > > >>> (1) we have published 2.9.0 at > > > > >>> https://downloads.apache.org/pulsar/pulsar-2.9.0/ > > > > >>> > > > > >>> (2) we have published 2.9.0 artifacts through maven central. They > > > don’t > > > > >>> let anyone republish versions. > > > > >>> > > > > >>> There are no do overs on versions. We simply cannot redo 2.9.0 at > > > this > > > > >>> moment. > > > > >>> > > > > >>> All the best, > > > > >>> Dave > > > > >>> > > > > >>> Sent from my iPhone > > > > >>> > > > > On Dec 12, 2021, at 8:49 PM, Sijie Guo > wrote: > > > > > > > > My take is - if we haven't announced 2.9, I would suggest just > > > > redoing > > > > >>> the > > > > 2.9.0 release. > > > > > > > > - Sijie > > > > > > > > > On Sun, Dec 12, 2021 at 6:35 PM Hang Chen > > > > > >> wrote: > > > > > > > > > > I am a little confused about why we should skip 2.9.0 and not > > > > continue > > > > > to release 2.9.0 by including the critical bug fixes. In fact, > the > > > > > Pulsar 2.9.0 release is not yet completed. > > > > > > > > > > For users, they will worry about whether the Pulsar release > process > > > > is > > > > > standardized if we skip 2.9.0. They will also worry about the > > > release > > > > > quality of Apache Pulsar if we have found the critical bugs > before > > > it > > > > > is released but not included it into the release version. For > > > Pulsar > > > > > 2.9.0, it couldn't be deployed into the production environment > due > > > to > > > > > the critical bug https://github.com/apache/pulsar/pull/12993 > > > > > > > > > > Regards, > > > > > Hang > > > > > > > > > > Dave Fisher 于2021年12月13日周一 09:40写道： > > > > >> > > > > >> It can be the case that releases are not announced. For > example > > > with > > > > > Tomcat a version which fails to pass the vote is skipped. > > > > >> > > > > >> Let’s not announce 2.9.0 and go on to 2.9.1. > > > > >> > > > > >> Maybe there’s some website fixes to hide 2.9.0. > > > > >> > > > > >> > > > > >> Sent from my iPhone > > > > >> > > > > >>> On Dec 12, 2021, at 5:28 PM, PengHui Li > > > > wrote: > > > > >>> > > > > >>> Another point is we have not announced the 2.9.0 release >
Re: Status of Pulsar 2.9.0 and starting 2.9.1
Hang, sorry, I wanted to say that I am double checking if people forgot to add "cherry-picked" Enrico Il giorno mer 15 dic 2021 alle ore 13:20 Enrico Olivelli < eolive...@gmail.com> ha scritto: > > > Il giorno mer 15 dic 2021 alle ore 12:52 Hang Chen > ha scritto: > >> Hi Enrico, >> Thanks for your great work! I found 150+ PR labeled as >> `release/2.9.1`, but doesn't contain in v2.9.1-candidate-1 tag. Does >> those PRs release in next version? >> >> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.1+-label%3Acherry-picked%2Fbranch-2.9+is%3Aclosed >> >> > In theory the answer is "yes", > I am double checking. > it is always an hard task > > Enrico > > >> Thanks, >> Hang >> >> Enrico Olivelli 于2021年12月15日周三 19:19写道： >> > >> > I had prepared the rc1 for 2.9.1 >> > >> > but today I added https://github.com/apache/pulsar/pull/13291 >> > >> > I will create a new RC and send a VOTE, possibly today >> > >> > The first RC will be rc2, in order to not mess up the git repository and >> > the dist area >> > >> > Enrico >> > >> > Il giorno lun 13 dic 2021 alle ore 19:22 Sijie Guo >> ha >> > scritto: >> > >> > > Thank you for sharing that! >> > > >> > > I think we should separate discussing a process from finishing a >> release. >> > > In other words, we shouldn't block on a process in order to finish a >> > > release. >> > > >> > > We should use the old process to finish a release while discussing a >> > > process to improve the release notes process. >> > > >> > > - Sijie >> > > >> > > On Mon, Dec 13, 2021 at 10:04 AM Dave Fisher wrote: >> > > >> > > > >> > > > >> > > > > On Dec 13, 2021, at 9:57 AM, Sijie Guo >> wrote: >> > > > > >> > > > > I am fine with doing 2.9.1. >> > > > > >> > > > > I am trying to understand what happened between released 2.9.0 and >> > > > > announcing it. >> > > > > >> > > > > It usually means there is a gap in the release process. We need to >> > > solve >> > > > > the process. If it is RM's responsibility for announcing the >> release, >> > > it >> > > > > should happen as soon as the release was cut. If the RM doesn't >> do it >> > > in >> > > > > time, other committers or PMC members should jump on it to help. >> I feel >> > > > > something was held up somewhere. But I don't know what is going on >> > > there. >> > > > >> > > > See the thread regarding release notes - >> > > > https://lists.apache.org/thread/sszycc3zjxkdqd9x5f16108qn0x7w5g1 >> > > > >> > > > Regards, >> > > > Dave >> > > > > >> > > > > - Sijie >> > > > > >> > > > > >> > > > > >> > > > > On Mon, Dec 13, 2021 at 9:47 AM Chris Herzog >> > > > > >> > > > > wrote: >> > > > > >> > > > >> I'm 100% with Dave. 2.9.0 is released (it's up on Maven), if >> it's not >> > > > >> "announced", that's just a "publicity" effort because the 2.9.0 >> > > release >> > > > is >> > > > >> out there. >> > > > >> >> > > > >> >> > > > >> >> > > > >> On Sun, Dec 12, 2021 at 11:34 PM Dave Fisher < >> wave4d...@comcast.net> >> > > > >> wrote: >> > > > >> >> > > > >>> (1) we have published 2.9.0 at >> > > > >>> https://downloads.apache.org/pulsar/pulsar-2.9.0/ >> > > > >>> >> > > > >>> (2) we have published 2.9.0 artifacts through maven central. >> They >> > > don’t >> > > > >>> let anyone republish versions. >> > > > >>> >> > > > >>> There are no do overs on versions. We simply cannot redo 2.9.0 >> at >> > > this >> > > > >>> moment. >> > > > >>> >> > > > >>> All the best, >> > > > >>> Dave >> > > > >>> >> > > > >>> Sent from my iPhone >> > > > >>> >> > > > On Dec 12, 2021, at 8:49 PM, Sijie Guo >> wrote: >> > > > >> > > > My take is - if we haven't announced 2.9, I would suggest just >> > > > redoing >> > > > >>> the >> > > > 2.9.0 release. >> > > > >> > > > - Sijie >> > > > >> > > > > On Sun, Dec 12, 2021 at 6:35 PM Hang Chen < >> chenh...@apache.org> >> > > > >> wrote: >> > > > > >> > > > > I am a little confused about why we should skip 2.9.0 and not >> > > > continue >> > > > > to release 2.9.0 by including the critical bug fixes. In >> fact, the >> > > > > Pulsar 2.9.0 release is not yet completed. >> > > > > >> > > > > For users, they will worry about whether the Pulsar release >> process >> > > > is >> > > > > standardized if we skip 2.9.0. They will also worry about the >> > > release >> > > > > quality of Apache Pulsar if we have found the critical bugs >> before >> > > it >> > > > > is released but not included it into the release version. For >> > > Pulsar >> > > > > 2.9.0, it couldn't be deployed into the production >> environment due >> > > to >> > > > > the critical bug https://github.com/apache/pulsar/pull/12993 >> > > > > >> > > > > Regards, >> > > > > Hang >> > > > > >> > > > > Dave Fisher 于2021年12月13日周一 09:40写道： >> > > > >> >> > > > >> It can be the case that releases are not announced. For >> example >> > > with >> > > > > Tomcat a version which fails to pass the vote is skipp
Re: Does the #13291 should contains in 2.8.2
We should contain #13291 in 2.8.2. Penghui On Wed, Dec 15, 2021 at 7:19 PM ZhangJian He wrote: > Hello, > @LinLin @lipenghui > > I want to discuss if #13291 should contains in release 2.8.2. > > It's a compatible problem since 2.8, and we already commited it to master > and branch 2.9 > > > Thanks > ZhangJian He >
Re: Does the #13291 should contains in 2.8.2
+1 Enrico Il giorno mer 15 dic 2021 alle ore 14:27 PengHui Li ha scritto: > We should contain #13291 in 2.8.2. > > Penghui > > On Wed, Dec 15, 2021 at 7:19 PM ZhangJian He wrote: > > > Hello, > > @LinLin @lipenghui > > > > I want to discuss if #13291 should contains in release 2.8.2. > > > > It's a compatible problem since 2.8, and we already commited it to master > > and branch 2.9 > > > > > > Thanks > > ZhangJian He > > >
Re: Status of Pulsar 2.9.0 and starting 2.9.1
If there are known critical bugs in 2.9.0, we should be transparent with users (and let them know that it's beta, or at least mention what features are incomplete) if it's going to be announced so trust is not damaged. Although I typically expect x.x.0 releases to be experimental (based on my experience), users without that experience might not realize that it's not yet safe to upgrade production environments to this version. I'd hope that all users would perform the rigorous testing required to discover any bugs that might appear in their production environments, but if some users trust the Apache releases to be stable, that trust can be damaged if we're not careful. Devin Bost (Sent from mobile) From: Enrico Olivelli Sent: Wednesday, December 15, 2021 5:29:53 AM To: Dev Subject: Re: Status of Pulsar 2.9.0 and starting 2.9.1 Hang, sorry, I wanted to say that I am double checking if people forgot to add "cherry-picked" Enrico Il giorno mer 15 dic 2021 alle ore 13:20 Enrico Olivelli < eolive...@gmail.com> ha scritto: > > > Il giorno mer 15 dic 2021 alle ore 12:52 Hang Chen > ha scritto: > >> Hi Enrico, >> Thanks for your great work! I found 150+ PR labeled as >> `release/2.9.1`, but doesn't contain in v2.9.1-candidate-1 tag. Does >> those PRs release in next version? >> >> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.1+-label%3Acherry-picked%2Fbranch-2.9+is%3Aclosed >> >> > In theory the answer is "yes", > I am double checking. > it is always an hard task > > Enrico > > >> Thanks, >> Hang >> >> Enrico Olivelli 于2021年12月15日周三 19:19写道： >> > >> > I had prepared the rc1 for 2.9.1 >> > >> > but today I added https://github.com/apache/pulsar/pull/13291 >> > >> > I will create a new RC and send a VOTE, possibly today >> > >> > The first RC will be rc2, in order to not mess up the git repository and >> > the dist area >> > >> > Enrico >> > >> > Il giorno lun 13 dic 2021 alle ore 19:22 Sijie Guo >> ha >> > scritto: >> > >> > > Thank you for sharing that! >> > > >> > > I think we should separate discussing a process from finishing a >> release. >> > > In other words, we shouldn't block on a process in order to finish a >> > > release. >> > > >> > > We should use the old process to finish a release while discussing a >> > > process to improve the release notes process. >> > > >> > > - Sijie >> > > >> > > On Mon, Dec 13, 2021 at 10:04 AM Dave Fisher wrote: >> > > >> > > > >> > > > >> > > > > On Dec 13, 2021, at 9:57 AM, Sijie Guo >> wrote: >> > > > > >> > > > > I am fine with doing 2.9.1. >> > > > > >> > > > > I am trying to understand what happened between released 2.9.0 and >> > > > > announcing it. >> > > > > >> > > > > It usually means there is a gap in the release process. We need to >> > > solve >> > > > > the process. If it is RM's responsibility for announcing the >> release, >> > > it >> > > > > should happen as soon as the release was cut. If the RM doesn't >> do it >> > > in >> > > > > time, other committers or PMC members should jump on it to help. >> I feel >> > > > > something was held up somewhere. But I don't know what is going on >> > > there. >> > > > >> > > > See the thread regarding release notes - >> > > > https://lists.apache.org/thread/sszycc3zjxkdqd9x5f16108qn0x7w5g1 >> > > > >> > > > Regards, >> > > > Dave >> > > > > >> > > > > - Sijie >> > > > > >> > > > > >> > > > > >> > > > > On Mon, Dec 13, 2021 at 9:47 AM Chris Herzog >> > > > > >> > > > > wrote: >> > > > > >> > > > >> I'm 100% with Dave. 2.9.0 is released (it's up on Maven), if >> it's not >> > > > >> "announced", that's just a "publicity" effort because the 2.9.0 >> > > release >> > > > is >> > > > >> out there. >> > > > >> >> > > > >> >> > > > >> >> > > > >> On Sun, Dec 12, 2021 at 11:34 PM Dave Fisher < >> wave4d...@comcast.net> >> > > > >> wrote: >> > > > >> >> > > > >>> (1) we have published 2.9.0 at >> > > > >>> https://downloads.apache.org/pulsar/pulsar-2.9.0/ >> > > > >>> >> > > > >>> (2) we have published 2.9.0 artifacts through maven central. >> They >> > > don’t >> > > > >>> let anyone republish versions. >> > > > >>> >> > > > >>> There are no do overs on versions. We simply cannot redo 2.9.0 >> at >> > > this >> > > > >>> moment. >> > > > >>> >> > > > >>> All the best, >> > > > >>> Dave >> > > > >>> >> > > > >>> Sent from my iPhone >> > > > >>> >> > > > On Dec 12, 2021, at 8:49 PM, Sijie Guo >> wrote: >> > > > >> > > > My take is - if we haven't announced 2.9, I would suggest just >> > > > redoing >> > > > >>> the >> > > > 2.9.0 release. >> > > > >> > > > - Sijie >> > > > >> > > > > On Sun, Dec 12, 2021 at 6:35 PM Hang Chen < >> chenh...@apache.org> >> > > > >> wrote: >> > > > > >> > > > > I am a little confused about why we should skip 2.9.0 and not >> > > > continue >> > > > > to release 2.9.0 by including the critical bug fixes. In >> fact, the >> > > > > Pulsar 2.9.0 release is no
Re: Status of Pulsar 2.9.0 and starting 2.9.1
Devin, Il giorno mer 15 dic 2021 alle ore 15:32 Devin Bost ha scritto: > If there are known critical bugs in 2.9.0, we should be transparent with > users (and let them know that it's beta, or at least mention what features > are incomplete) if it's going to be announced so trust is not damaged. > Actually we found a regression in 2.9.0 right after closing the VOTE. It also includes the upgrade of log4j2 When we closed the VOTE there was no known reason to say that the release was not stable or that it contained vulnerabilities Enrico > Although I typically expect x.x.0 releases to be experimental (based on my > experience), users without that experience might not realize that it's not > yet safe to upgrade production environments to this version. > > I'd hope that all users would perform the rigorous testing required to > discover any bugs that might appear in their production environments, but > if some users trust the Apache releases to be stable, that trust can be > damaged if we're not careful. > > > Devin Bost > (Sent from mobile) > > > From: Enrico Olivelli > Sent: Wednesday, December 15, 2021 5:29:53 AM > To: Dev > Subject: Re: Status of Pulsar 2.9.0 and starting 2.9.1 > > Hang, > sorry, I wanted to say that I am double checking if people forgot to add > "cherry-picked" > > Enrico > > Il giorno mer 15 dic 2021 alle ore 13:20 Enrico Olivelli < > eolive...@gmail.com> ha scritto: > > > > > > > Il giorno mer 15 dic 2021 alle ore 12:52 Hang Chen > > ha scritto: > > > >> Hi Enrico, > >> Thanks for your great work! I found 150+ PR labeled as > >> `release/2.9.1`, but doesn't contain in v2.9.1-candidate-1 tag. Does > >> those PRs release in next version? > >> > >> > https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.1+-label%3Acherry-picked%2Fbranch-2.9+is%3Aclosed > >> > >> > > In theory the answer is "yes", > > I am double checking. > > it is always an hard task > > > > Enrico > > > > > >> Thanks, > >> Hang > >> > >> Enrico Olivelli 于2021年12月15日周三 19:19写道： > >> > > >> > I had prepared the rc1 for 2.9.1 > >> > > >> > but today I added https://github.com/apache/pulsar/pull/13291 > >> > > >> > I will create a new RC and send a VOTE, possibly today > >> > > >> > The first RC will be rc2, in order to not mess up the git repository > and > >> > the dist area > >> > > >> > Enrico > >> > > >> > Il giorno lun 13 dic 2021 alle ore 19:22 Sijie Guo < > guosi...@gmail.com> > >> ha > >> > scritto: > >> > > >> > > Thank you for sharing that! > >> > > > >> > > I think we should separate discussing a process from finishing a > >> release. > >> > > In other words, we shouldn't block on a process in order to finish a > >> > > release. > >> > > > >> > > We should use the old process to finish a release while discussing a > >> > > process to improve the release notes process. > >> > > > >> > > - Sijie > >> > > > >> > > On Mon, Dec 13, 2021 at 10:04 AM Dave Fisher > wrote: > >> > > > >> > > > > >> > > > > >> > > > > On Dec 13, 2021, at 9:57 AM, Sijie Guo > >> wrote: > >> > > > > > >> > > > > I am fine with doing 2.9.1. > >> > > > > > >> > > > > I am trying to understand what happened between released 2.9.0 > and > >> > > > > announcing it. > >> > > > > > >> > > > > It usually means there is a gap in the release process. We need > to > >> > > solve > >> > > > > the process. If it is RM's responsibility for announcing the > >> release, > >> > > it > >> > > > > should happen as soon as the release was cut. If the RM doesn't > >> do it > >> > > in > >> > > > > time, other committers or PMC members should jump on it to help. > >> I feel > >> > > > > something was held up somewhere. But I don't know what is going > on > >> > > there. > >> > > > > >> > > > See the thread regarding release notes - > >> > > > https://lists.apache.org/thread/sszycc3zjxkdqd9x5f16108qn0x7w5g1 > >> > > > > >> > > > Regards, > >> > > > Dave > >> > > > > > >> > > > > - Sijie > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Mon, Dec 13, 2021 at 9:47 AM Chris Herzog > >> >> > > > > >> > > > > wrote: > >> > > > > > >> > > > >> I'm 100% with Dave. 2.9.0 is released (it's up on Maven), if > >> it's not > >> > > > >> "announced", that's just a "publicity" effort because the 2.9.0 > >> > > release > >> > > > is > >> > > > >> out there. > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> On Sun, Dec 12, 2021 at 11:34 PM Dave Fisher < > >> wave4d...@comcast.net> > >> > > > >> wrote: > >> > > > >> > >> > > > >>> (1) we have published 2.9.0 at > >> > > > >>> https://downloads.apache.org/pulsar/pulsar-2.9.0/ > >> > > > >>> > >> > > > >>> (2) we have published 2.9.0 artifacts through maven central. > >> They > >> > > don’t > >> > > > >>> let anyone republish versions. > >> > > > >>> > >> > > > >>> There are no do overs on versions. We simply cannot redo 2.9.0 > >> at > >> > > this > >> > > > >>> moment. > >> > > > >>> > >> > > > >>> All the best, > >> > > > >>> Dave > >> > > > >>> > >
Re: [DISCUSSION] PIP-117: Change Pulsar standalone defaults
+1 I think this is a good idea. The tradeoff here is that testing against a standalone "cluster" is even more different than testing against a distributed Pulsar cluster. I think this is fine, but if we accept this PIP, I think we should update our guidance on the Wiki, which currently recommends running release candidate validation tests against a standalone cluster [0]. - Michael [0] https://github.com/apache/pulsar/wiki/Release-Candidate-Validation#validate-pubsub-and-java-functions On Wed, Dec 15, 2021 at 5:09 AM Enrico Olivelli wrote: > > +1 > > @Haiting > Pulsar Standalone is usually used for local development, I am not sure you > need a migration tool. > You can still keep the configuration to use previously (standalone.conf) > > Enrico > > Il giorno mer 15 dic 2021 alle ore 10:56 Haiting Jiang < > jianghait...@apache.org> ha scritto: > > > +1 (non-binding) > > > > Out of the scope of this PIP, a follow up data migration tool could be > > added to help migration from old settings without data loss. > > > > --- > > Haiting > > > > On 2021/12/15 01:04:21 Hang Chen wrote: > > > +1 > > > > > > Thanks, > > > Hang > > > > > > PengHui Li 于2021年12月15日周三 07:52写道： > > > > > > > > +1 > > > > > > > > Penghui > > > > > > > > On Wed, Dec 15, 2021 at 1:18 AM Matteo Merli > > wrote: > > > > > > > > > https://github.com/apache/pulsar/issues/13302 > > > > > > > > > > Copying here for quoting convenience > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ## Motivation > > > > > > > > > > Pulsar standalone is the "Pulsar in a box" version of a Pulsar > > cluster, > > > > > where > > > > > all the components are started within the context of a single JVM > > process. > > > > > > > > > > Users are using the standalone as a way to get quickly started with > > Pulsar > > > > > or > > > > > in all the cases where it makes sense to have a single node > > deployment. > > > > > > > > > > Right now, the standalone is starting by default with many > > components, > > > > > several of > > > > > which are quite complex, since they are designed to be deployed in a > > > > > distributed > > > > > fashion. > > > > > > > > > > ## Goal > > > > > > > > > > Simplify the components of Pulsar standalone to achieve: > > > > > > > > > > 1. Reduce complexity > > > > > 2. Reduce startup time > > > > > 3. Reduce memory and CPU footprint of running standalone > > > > > > > > > > ## Proposed changes > > > > > > > > > > The proposal here is to change some of the default implementations > > that are > > > > > used for the Pulsar standalone. > > > > > > > > > > 1. **Metadata Store implementation** --> > > > > > Change from ZooKeeper to RocksDB > > > > > > > > > > 2. **Pulsar functions package backend** --> > > > > > Change from using DistributedLog to using local filesystem, > > storing > > > > > the > > > > > jars directly in the data folder instead of uploading them > > into BK. > > > > > > > > > > 3. **Pulsar functions state store implementation** --> > > > > > Change the state store to be backed by a MetadataStore based > > backed, > > > > > with the RocksDB implementation. > > > > > > > > > > 4. **Table Service** --> > > > > > Do not start BK table service by default > > > > > > > > > > ## Compatibility considerations > > > > > > > > > > In order to avoid compatibility issues where users have existing > > Pulsar > > > > > standalone services that they want to upgrade without conflicts, we > > will > > > > > follow the principle of keeping the old defaults where there is > > existing > > > > > data on the disk. > > > > > > > > > > We will add a file, serving the purpose as a flag, in the > > `data/standalone` > > > > > directory, for example `new-2.10-defaults`. > > > > > > > > > > If the file is present, or if the data directory is completely > > missing, we > > > > > will adopt the new set of default configuration settings. > > > > > > > > > > If the file is not there, we will continue to use existing defaults > > and we > > > > > will > > > > > not break the upgrade operation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Matteo Merli > > > > > > > > > > > > > > >
Re: [DISCUSS] Converge authz to operate subscription policies of namespace
Hi Ruguo, Thanks for bringing this to the mailing list. I think we should maintain our current authorization granularity, even if we're not currently using it in the default authorization provider. I see you updated your PR [0] to keep the granularity--I'll provide a review soon. Thanks, Michael [0] https://github.com/apache/pulsar/pull/13157 On Wed, Dec 8, 2021 at 6:08 AM Ruguo Yu wrote: > > Hi Pulsar Community, > > Currently, only super-user and tenant-administrator can set/get/remove the > subscription policies of the namespace. The subscription policies includes: > subscription-expiration-time > subscription-auth-mode > subscription-types-enabled > subscription-dispatch-rate > max-consumers-per-subscription > max-unacked-messages-per-subscription > auto-subscription-creation > Is it possible for the authorization to operate the subscription policies to > converge further? For example, roles that have permission to `consume` > namespaces can also operate above policies, at least to get the subscription > policy is allowed. I look forward to your views. > > In addition, I submitted a draft[0], you can take a look if you are > interested. > > > > Thanks, > > Ruguo Yu > > > > [0] - https://github.com/apache/pulsar/pull/13157 >
Re: PIP 116: Create Pulsar Writing Style Guide
Thanks Yu for this initiative. I made a small correction in the document. Regards, Dave > On Dec 14, 2021, at 7:17 PM, Yu wrote: > > Hi Pulsar enthusiasts, > > > As you may notice, there are more and more documentation contributions > nowadays, which is great! > > > Similar to coding style guides, in the field of technical writing, a > writing style guide is a must to improve users' experience and eliminate > writers' workload. > > > To improve the doc quality, I create our style guide — *Pulsar Writing > Style Guide* [1] > > > # Definition > > > Pulsar Writing Style Guide contains a set of standards for writing and > designing content. > > > It helps maintain a consistent style, voice, and tone across Pulsar > documentation. > > > This guide is inspired by some existing style guides. It references *IBM > Style Guide*, *Chicago Manual of Style*, and other books for more > exhaustive guidance. > > > # Benefits > > > Pulsar Writing Style Guide can improve the content quality and bring many > benefits to users and writers like: > > > For users: > > - Make documentation easier to read > > - Reduce users’ cognitive load > > - Increase users' confidence in the content’s authority > > > For information developers: > > - Resolve arguments and support our needs to create readable, usable, and > minimalist information > > - Save time and trouble by providing a single reference for writing about > common topics, features, and more > > - Help write documentation in a clearer way and keep a consistent tone of > voice and style > > >>> > > > This guide is not a one-shot job, the current version is an initial draft. > I'll make continuous efforts on that. > > > I believe that the Pulsar community will welcome this addition to our > resources and profit from the instructions. > > > Feel free to comment, thanks. > > > [1] > https://docs.google.com/document/d/1lc5j4RtuLIzlEYCBo97AC8-U_3Erzs_lxpkDuseU0n4/edit#
[DISCUSSION] PIP-123: Introduce Pulsar metadata CLI tool
https://github.com/apache/pulsar/issues/13346
Pasted here for quoting convenience
-
## Motivation
For a very long time, we have included a CLI command to start the ZooKeeper
shell utility: `pulsar zookeeper-shell`, which is essentially a repackaging
of the ZooKeeper tool `zkCli.sh`.
This is useful in some cases to either verify the content of metadata or
to perform cleanup and modification tasks for which there is not an available
option through the Pulsar REST APIs.
While it's very useful, there are some drawbacks with the `zookeeper-shell`
as it is today:
1. This is only a ZooKeeper tool (obviously). Since we are adding more
metadata backends, we should have a tool that works across all the
implementations and presents a single consistent interface.
2. ZooKeeper shell is designed to be an interactive shell and it's not very
good when trying to do non-interactive scriptable operations.
3. ZooKeeper is a bit clunky when using it and it requires the user to retype
paths many times. The commands are not very intuitive or documented.
It's not possible to update z-node with multi-lines content.
4. We cannot easily add functionality or improvements into ZooKeeper shell,
since it belongs to a different project and the tool has been stagnating
for many years.
5. In cases where the z-nodes content is binary (Protobuf) or compressed, there
is no easy way to inspect the content from the ZooKeeper shell.
Additionally, we can format and colorize JSON content to make it easier to
read.
6. The paths used for metadata resources are also often using encodings that
make it more difficult to construct on the shell tool.
Part of what is described here is in the `pulsar-managed-ledger-admin` CLI tool,
though that is a Python script that requires additional dependencies that are
not typically installed, it only works with ZooKeeper, and it only targets
accessing the managed ledger metadata.
## Goal
Introduce a new Java CLI tool to access, inspect and modify metadata that solves
all the issues described above.
We would leave the `zookeeper-shell` command for now. In the future, once the
new tool is proven, we can consider removing the `zookeeper-shell` command.
## Proposed changes
Add a new command:
```bash
bin/pulsar metadata
```
with several subcommands:
Get
Examples:
```bash
# General path get
$ pulsar metadata get /my-path
# Topic metadata
$ pulsar metadata get topic my-tenant/my-namespace/my-topic
{
# Managed ledger metadata
}
# Namespace get
$ pulsar metadata get namespace my-tenant/my-namespace
{
# Namespace metadata
}
$ pulsar metadata get ledger 12345
{
# BK ledger metadata
}
```
Delete
Examples:
```bash
# General path delete
$ pulsar metadata delete /my-path
# Topic metadata
$ pulsar metadata delete topic my-tenant/my-namespace/my-topic
```
Scan
Examples:
```bash
$ pulsar metadata scan /my-path
/my-path
/my-path/1
/my-path/2
/my-path/3
/my-path/3/1
$ pulsar metadata scan --values /my-path
/my-path
{value}
/my-path/1
{value}
/my-path/2
{value}
```
Shell
```bash
$ pulsar metadata shell
> get topic my-tenant/my-namespace/my-topic
{
# Managed ledger metadata
}
> delete topic my-tenant/my-namespace/my-topic
> cd /my-path
> ls
1
2
3
> delete 1 # Delete keys with relative paths
```
--
Matteo Merli
[DISCUSS] Add definition to our cherry picking process
Hello Pulsar Community, As far as I can tell, we do not have a publicly defined process for cherry-picking commits to release branches [0]. As a new committer, I'd like to provide my newly gained perspective and ask that we add some guidance to our wiki. Regarding cherry picking, I see two patterns in Pulsar: 1. Some committers cherry pick commits when they merge a PR. 2. Some committers leave PRs to be cherry picked right before tagging the dot release. The release manager is expected to cherry pick these commits. Anecdotally, pattern 2 is more common. I am concerned that pattern 2 creates a lot of extra work for the release manager, leaves the community with little time to build and test release branches before tagging release candidates, and leaves us unable to quickly respond to security issues. If we switch to pattern 1, merging PRs may become more time consuming. However, it lightens the load on release managers and makes the project more nimble. Further, resolving conflicts should be easier, as the committer already has the PR's context, which could reduce the risk of regressions. For example, the 2.7.4 release is delayed because of pattern 2. Penghui and I cherry picked many commits over the recent days because branch-2.7 was not up to date. Now, the tests aren't passing for the branch, and since we shouldn't cut a release until the tests pass, we haven't released the patch for the Log4Shell CVE. Another solution is to remove the expectation that the release manager cherry picks commits. The downside here is that we will possibly miss important bug fixes that would improve dot release stability. I propose that we try to use pattern 1 (or something close to it) for our process. Thanks, Michael [0] https://github.com/apache/pulsar/wiki/Committer-Guide
Re: [DISCUSS] Add definition to our cherry picking process
What are the benefits of cherry picking vs committing to the oldest relevant branch and merging forwards? Git is designed around merge since that preserves the commit sha which allows it to be tracked across branches. And a merge based workflow avoids the problem here by design. On Wed, Dec 15, 2021 at 1:54 PM Michael Marshall wrote: > Hello Pulsar Community, > > As far as I can tell, we do not have a publicly defined process for > cherry-picking commits to release branches [0]. As a new committer, > I'd like to provide my newly gained perspective and ask that we add > some guidance to our wiki. > > Regarding cherry picking, I see two patterns in Pulsar: > 1. Some committers cherry pick commits when they merge a PR. > 2. Some committers leave PRs to be cherry picked right before tagging > the dot release. The release manager is expected to cherry pick these > commits. > > Anecdotally, pattern 2 is more common. > > I am concerned that pattern 2 creates a lot of extra work for the > release manager, leaves the community with little time to build and > test release branches before tagging release candidates, and leaves us > unable to quickly respond to security issues. > > If we switch to pattern 1, merging PRs may become more time consuming. > However, it lightens the load on release managers and makes the > project more nimble. Further, resolving conflicts should be easier, as > the committer already has the PR's context, which could reduce the > risk of regressions. > > For example, the 2.7.4 release is delayed because of pattern 2. > Penghui and I cherry picked many commits over the recent days because > branch-2.7 was not up to date. Now, the tests aren't passing for the > branch, and since we shouldn't cut a release until the tests pass, we > haven't released the patch for the Log4Shell CVE. > > Another solution is to remove the expectation that the release manager > cherry picks commits. The downside here is that we will possibly miss > important bug fixes that would improve dot release stability. > > I propose that we try to use pattern 1 (or something close to it) for > our process. > > Thanks, > Michael > > [0] https://github.com/apache/pulsar/wiki/Committer-Guide > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
Re: [DISCUSS] How to handle stale PRs
I am +1 for closing PRs that are over a year old. Does anyone else in the community have thoughts on these old PRs? Getting consensus and creating a process here could help make our committers more efficient. - Michael On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote: > > Agreed. > > I don't think I understand tison's objection to closing very stale PRs > automatically -- if it's gone that long without attention the situation > isn't likely to change. And the submitter can always reopen it if it's > still relevant. > > On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: > > > I think that any Pulsar committer ought to close any PR that is more than > > one year old. That would clear about 75 from the backlog. The OP should be > > informed and if they are still interested then they can discuss it here. > > > > So when a stale PR is closed we should suggest that the OP subscribe to > > and email dev@pulsar.apache.org to discuss the PR. > > > > All the Best, > > Dave > > . > > > On Dec 3, 2021, at 9:17 AM, tison wrote: > > > > > > From my experience, any process won't work. The only way is to inspire > > more > > > reviewers act on PRs. > > > > > > Instead of talking about how to do it, reviewing one PR now can help the > > > case. > > > Also, it's reasonable to close inactive PR if there is a successor. But > > do > > > not let > > > a bot do it, which will create many corner (bad) cases. > > > > > > Best, > > > tison. > > > > > > > > > Michael Marshall 于2021年12月4日周六 00:57写道： > > > > > >> Hi Pulsar Community, > > >> > > >> I am excited to start contributing as a committer! I have a question > > >> about our process for closing stale PRs. > > >> > > >> We have ~300 open PRs right now. Do we have any guidelines on closing > > >> stale PRs? Of course we don't want to ignore important bug fixes, but > > >> we also don't want to clutter our repo with open PRs that won't get > > merged. > > >> > > >> For example, I reviewed this PR [0] about 3 months ago. The > > >> contributor has not yet responded to my feedback and it doesn't seem > > >> to fix an actual bug, so I think it is a candidate for closure. Here > > >> is another example [1]. I closed this one because it had merge > > >> conflicts with a commit that fixed the same underlying issue. > > >> > > >> Note that our committer guidelines [2] do not provide guidance on this > > >> subject. > > >> > > >> [0] - https://github.com/apache/pulsar/pull/11237 > > >> [1] - https://github.com/apache/pulsar/pull/11162 > > >> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide > > >> > > >> Thanks, > > >> Michael > > >> > > > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced
Re: [DISCUSS] How to handle stale PRs
I'm not convinced by having a blanket policy here. In several cases, these PRs carried some very valuable ideas that still needed some work to get merged. By using blanket close, we'd be losing all that context and we should not do that. What would actually be helpful, is help in reviewing these old PRs to identify what is either already rejected or superseded by other changes and what just needs some help to get completed. Just declaring PR bankrupticity alone won't solve the problem of why more PRs are created than reviewers can review. Matteo -- Matteo Merli On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall wrote: > > I am +1 for closing PRs that are over a year old. > > Does anyone else in the community have thoughts on these old PRs? > Getting consensus and creating a process here could help make our > committers more efficient. > > - Michael > > > On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote: > > > > Agreed. > > > > I don't think I understand tison's objection to closing very stale PRs > > automatically -- if it's gone that long without attention the situation > > isn't likely to change. And the submitter can always reopen it if it's > > still relevant. > > > > On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: > > > > > I think that any Pulsar committer ought to close any PR that is more than > > > one year old. That would clear about 75 from the backlog. The OP should be > > > informed and if they are still interested then they can discuss it here. > > > > > > So when a stale PR is closed we should suggest that the OP subscribe to > > > and email dev@pulsar.apache.org to discuss the PR. > > > > > > All the Best, > > > Dave > > > . > > > > On Dec 3, 2021, at 9:17 AM, tison wrote: > > > > > > > > From my experience, any process won't work. The only way is to inspire > > > more > > > > reviewers act on PRs. > > > > > > > > Instead of talking about how to do it, reviewing one PR now can help the > > > > case. > > > > Also, it's reasonable to close inactive PR if there is a successor. But > > > do > > > > not let > > > > a bot do it, which will create many corner (bad) cases. > > > > > > > > Best, > > > > tison. > > > > > > > > > > > > Michael Marshall 于2021年12月4日周六 00:57写道： > > > > > > > >> Hi Pulsar Community, > > > >> > > > >> I am excited to start contributing as a committer! I have a question > > > >> about our process for closing stale PRs. > > > >> > > > >> We have ~300 open PRs right now. Do we have any guidelines on closing > > > >> stale PRs? Of course we don't want to ignore important bug fixes, but > > > >> we also don't want to clutter our repo with open PRs that won't get > > > merged. > > > >> > > > >> For example, I reviewed this PR [0] about 3 months ago. The > > > >> contributor has not yet responded to my feedback and it doesn't seem > > > >> to fix an actual bug, so I think it is a candidate for closure. Here > > > >> is another example [1]. I closed this one because it had merge > > > >> conflicts with a commit that fixed the same underlying issue. > > > >> > > > >> Note that our committer guidelines [2] do not provide guidance on this > > > >> subject. > > > >> > > > >> [0] - https://github.com/apache/pulsar/pull/11237 > > > >> [1] - https://github.com/apache/pulsar/pull/11162 > > > >> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide > > > >> > > > >> Thanks, > > > >> Michael > > > >> > > > > > > > > > > -- > > Jonathan Ellis > > co-founder, http://www.datastax.com > > @spyced
Re: [DISCUSS] Add definition to our cherry picking process
Jonathan, Il Mer 15 Dic 2021, 21:11 Jonathan Ellis ha scritto: > What are the benefits of cherry picking vs committing to the oldest > relevant branch and merging forwards? We (and most of the ASF projects I am involved in) ask contributors to target the master branch for the patches. How can we do what you suggest? Asking people to send PRs against the oldest branch relevant to the patch? Probably the contributor is not aware of the other branches. Can you please explain more your idea? Enrico Git is designed around merge since > that preserves the commit sha which allows it to be tracked across > branches. And a merge based workflow avoids the problem here by design. > > On Wed, Dec 15, 2021 at 1:54 PM Michael Marshall > wrote: > > > Hello Pulsar Community, > > > > As far as I can tell, we do not have a publicly defined process for > > cherry-picking commits to release branches [0]. As a new committer, > > I'd like to provide my newly gained perspective and ask that we add > > some guidance to our wiki. > > > > Regarding cherry picking, I see two patterns in Pulsar: > > 1. Some committers cherry pick commits when they merge a PR. > > 2. Some committers leave PRs to be cherry picked right before tagging > > the dot release. The release manager is expected to cherry pick these > > commits. > > > > Anecdotally, pattern 2 is more common. > > > > I am concerned that pattern 2 creates a lot of extra work for the > > release manager, leaves the community with little time to build and > > test release branches before tagging release candidates, and leaves us > > unable to quickly respond to security issues. > > > > If we switch to pattern 1, merging PRs may become more time consuming. > > However, it lightens the load on release managers and makes the > > project more nimble. Further, resolving conflicts should be easier, as > > the committer already has the PR's context, which could reduce the > > risk of regressions. > > > > For example, the 2.7.4 release is delayed because of pattern 2. > > Penghui and I cherry picked many commits over the recent days because > > branch-2.7 was not up to date. Now, the tests aren't passing for the > > branch, and since we shouldn't cut a release until the tests pass, we > > haven't released the patch for the Log4Shell CVE. > > > > Another solution is to remove the expectation that the release manager > > cherry picks commits. The downside here is that we will possibly miss > > important bug fixes that would improve dot release stability. > > > > I propose that we try to use pattern 1 (or something close to it) for > > our process. > > > > Thanks, > > Michael > > > > [0] https://github.com/apache/pulsar/wiki/Committer-Guide > > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced >
Re: [DISCUSS] How to handle stale PRs
> I'm not convinced by having a blanket policy here. I'm fine with stopping short of an automated policy. However, I think it'd be helpful to provide committers, especially new committers, with conditions that make a PR eligible to be closed. Since committers act on behalf of the PMC, documentation can give them confidence that they are acting correctly. Once we have guidance, I am happy to add it to the Committer Guide on the wiki [0]. For example, we could say that a committer can close a PR when: 1. The PR's intended change is superseded by another change. In this case, the committer should provide a reference to the other PR. 2. The PR's intended change has been rejected by the community. In this case, the rejection must first be discussed on the mailing list. 3. The PR does not appear to fix an issue and the contributor has not responded to a request for clarification within some time frame (maybe a month?). In this case, the committer should note that the PR can be reopened if/when the contributor is available to move the PR forward. My goal in starting this thread was to clarify when I can close PRs. Matteo, your comment raises an additional question for me. What are Apache's rules for completing someone else's contribution? If someone opens a PR to fix a bug, but it is incomplete and they become unresponsive, how can we move their contribution forward? These are the PRs we don't want to close. Thanks, Michael [0] https://github.com/apache/pulsar/wiki/Committer-Guide On Wed, Dec 15, 2021 at 3:12 PM Matteo Merli wrote: > > I'm not convinced by having a blanket policy here. > > In several cases, these PRs carried some very valuable ideas that > still needed some work to get merged. By using blanket close, we'd be > losing all that context and we should not do that. > > What would actually be helpful, is help in reviewing these old PRs to > identify what is either already rejected or superseded by other > changes and what just needs some help to get completed. > > Just declaring PR bankrupticity alone won't solve the problem of why > more PRs are created than reviewers can review. > > > Matteo > > -- > Matteo Merli > > > On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall wrote: > > > > I am +1 for closing PRs that are over a year old. > > > > Does anyone else in the community have thoughts on these old PRs? > > Getting consensus and creating a process here could help make our > > committers more efficient. > > > > - Michael > > > > > > On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote: > > > > > > Agreed. > > > > > > I don't think I understand tison's objection to closing very stale PRs > > > automatically -- if it's gone that long without attention the situation > > > isn't likely to change. And the submitter can always reopen it if it's > > > still relevant. > > > > > > On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: > > > > > > > I think that any Pulsar committer ought to close any PR that is more > > > > than > > > > one year old. That would clear about 75 from the backlog. The OP should > > > > be > > > > informed and if they are still interested then they can discuss it here. > > > > > > > > So when a stale PR is closed we should suggest that the OP subscribe to > > > > and email dev@pulsar.apache.org to discuss the PR. > > > > > > > > All the Best, > > > > Dave > > > > . > > > > > On Dec 3, 2021, at 9:17 AM, tison wrote: > > > > > > > > > > From my experience, any process won't work. The only way is to inspire > > > > more > > > > > reviewers act on PRs. > > > > > > > > > > Instead of talking about how to do it, reviewing one PR now can help > > > > > the > > > > > case. > > > > > Also, it's reasonable to close inactive PR if there is a successor. > > > > > But > > > > do > > > > > not let > > > > > a bot do it, which will create many corner (bad) cases. > > > > > > > > > > Best, > > > > > tison. > > > > > > > > > > > > > > > Michael Marshall 于2021年12月4日周六 00:57写道： > > > > > > > > > >> Hi Pulsar Community, > > > > >> > > > > >> I am excited to start contributing as a committer! I have a question > > > > >> about our process for closing stale PRs. > > > > >> > > > > >> We have ~300 open PRs right now. Do we have any guidelines on closing > > > > >> stale PRs? Of course we don't want to ignore important bug fixes, but > > > > >> we also don't want to clutter our repo with open PRs that won't get > > > > merged. > > > > >> > > > > >> For example, I reviewed this PR [0] about 3 months ago. The > > > > >> contributor has not yet responded to my feedback and it doesn't seem > > > > >> to fix an actual bug, so I think it is a candidate for closure. Here > > > > >> is another example [1]. I closed this one because it had merge > > > > >> conflicts with a commit that fixed the same underlying issue. > > > > >> > > > > >> Note that our committer guidelines [2] do not provide guidance on > > > > >> this > > > > >> subject. > > > > >> > > > > >> [0] - https://github.com/apache/pulsar
Re: [DISCUSS] How to handle stale PRs
I think that there should be a label added to any old PR that a contributor wants to keep open. I think “status/hold” would be a good label name. That will keep others who wish to review old PRs and close them from wasting their time. I looked at the labels and I wonder about those that are “triage/week-N” Do these have a consistent use case? And if so, what is it? > On Dec 15, 2021, at 1:11 PM, Matteo Merli wrote: > > I'm not convinced by having a blanket policy here. > > In several cases, these PRs carried some very valuable ideas that > still needed some work to get merged. By using blanket close, we'd be > losing all that context and we should not do that. > > What would actually be helpful, is help in reviewing these old PRs to > identify what is either already rejected or superseded by other > changes and what just needs some help to get completed. > > Just declaring PR bankrupticity alone won't solve the problem of why > more PRs are created than reviewers can review. > > > Matteo > > -- > Matteo Merli > > > On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall wrote: >> >> I am +1 for closing PRs that are over a year old. >> >> Does anyone else in the community have thoughts on these old PRs? >> Getting consensus and creating a process here could help make our >> committers more efficient. >> >> - Michael >> >> >> On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote: >>> >>> Agreed. >>> >>> I don't think I understand tison's objection to closing very stale PRs >>> automatically -- if it's gone that long without attention the situation >>> isn't likely to change. And the submitter can always reopen it if it's >>> still relevant. >>> >>> On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: >>> I think that any Pulsar committer ought to close any PR that is more than one year old. That would clear about 75 from the backlog. The OP should be informed and if they are still interested then they can discuss it here. So when a stale PR is closed we should suggest that the OP subscribe to and email dev@pulsar.apache.org to discuss the PR. All the Best, Dave . > On Dec 3, 2021, at 9:17 AM, tison wrote: > > From my experience, any process won't work. The only way is to inspire more > reviewers act on PRs. > > Instead of talking about how to do it, reviewing one PR now can help the > case. > Also, it's reasonable to close inactive PR if there is a successor. But do > not let > a bot do it, which will create many corner (bad) cases. > > Best, > tison. > > > Michael Marshall 于2021年12月4日周六 00:57写道： > >> Hi Pulsar Community, >> >> I am excited to start contributing as a committer! I have a question >> about our process for closing stale PRs. >> >> We have ~300 open PRs right now. Do we have any guidelines on closing >> stale PRs? Of course we don't want to ignore important bug fixes, but >> we also don't want to clutter our repo with open PRs that won't get merged. >> >> For example, I reviewed this PR [0] about 3 months ago. The >> contributor has not yet responded to my feedback and it doesn't seem >> to fix an actual bug, so I think it is a candidate for closure. Here >> is another example [1]. I closed this one because it had merge >> conflicts with a commit that fixed the same underlying issue. >> >> Note that our committer guidelines [2] do not provide guidance on this >> subject. >> >> [0] - https://github.com/apache/pulsar/pull/11237 >> [1] - https://github.com/apache/pulsar/pull/11162 >> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide >> >> Thanks, >> Michael >> >>> >>> -- >>> Jonathan Ellis >>> co-founder, http://www.datastax.com >>> @spyced
Re: [DISCUSS] How to handle stale PRs
> On Dec 15, 2021, at 1:11 PM, Matteo Merli wrote: > > I'm not convinced by having a blanket policy here. > > In several cases, these PRs carried some very valuable ideas that > still needed some work to get merged. By using blanket close, we'd be > losing all that context and we should not do that. Is #3267 Support set publish time on broker side one of those very valuable ideas that was later rejected, likely for performance reasons? > > What would actually be helpful, is help in reviewing these old PRs to > identify what is either already rejected or superseded by other > changes and what just needs some help to get completed. > > Just declaring PR bankrupticity alone won't solve the problem of why > more PRs are created than reviewers can review. > > > Matteo > > -- > Matteo Merli > > > On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall wrote: >> >> I am +1 for closing PRs that are over a year old. >> >> Does anyone else in the community have thoughts on these old PRs? >> Getting consensus and creating a process here could help make our >> committers more efficient. >> >> - Michael >> >> >> On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote: >>> >>> Agreed. >>> >>> I don't think I understand tison's objection to closing very stale PRs >>> automatically -- if it's gone that long without attention the situation >>> isn't likely to change. And the submitter can always reopen it if it's >>> still relevant. >>> >>> On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: >>> I think that any Pulsar committer ought to close any PR that is more than one year old. That would clear about 75 from the backlog. The OP should be informed and if they are still interested then they can discuss it here. So when a stale PR is closed we should suggest that the OP subscribe to and email dev@pulsar.apache.org to discuss the PR. All the Best, Dave . > On Dec 3, 2021, at 9:17 AM, tison wrote: > > From my experience, any process won't work. The only way is to inspire more > reviewers act on PRs. > > Instead of talking about how to do it, reviewing one PR now can help the > case. > Also, it's reasonable to close inactive PR if there is a successor. But do > not let > a bot do it, which will create many corner (bad) cases. > > Best, > tison. > > > Michael Marshall 于2021年12月4日周六 00:57写道： > >> Hi Pulsar Community, >> >> I am excited to start contributing as a committer! I have a question >> about our process for closing stale PRs. >> >> We have ~300 open PRs right now. Do we have any guidelines on closing >> stale PRs? Of course we don't want to ignore important bug fixes, but >> we also don't want to clutter our repo with open PRs that won't get merged. >> >> For example, I reviewed this PR [0] about 3 months ago. The >> contributor has not yet responded to my feedback and it doesn't seem >> to fix an actual bug, so I think it is a candidate for closure. Here >> is another example [1]. I closed this one because it had merge >> conflicts with a commit that fixed the same underlying issue. >> >> Note that our committer guidelines [2] do not provide guidance on this >> subject. >> >> [0] - https://github.com/apache/pulsar/pull/11237 >> [1] - https://github.com/apache/pulsar/pull/11162 >> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide >> >> Thanks, >> Michael >> >>> >>> -- >>> Jonathan Ellis >>> co-founder, http://www.datastax.com >>> @spyced
Re: [DISCUSS] Add definition to our cherry picking process
First, it's often not an issue -- new contributors typically start with small patches that the reviewer or committer can easily rebase to the appropriate branch, and by the time they're working on more invasive fixes (we don't have any of those, right? :) they get used to how it works. But when the merge is NOT trivial then the reviewer will ask the contributor to post separate patches against the newer branches, this reduces the burden on the reviewer (or the release manager!) to do all the merging and it is less error prone for the original author to perform a tricky merge. Recent example from Cassandra where reviewer Joey Lynch asked contributor NV Harikrishna to do this: https://issues.apache.org/jira/browse/CASSANDRA-14898 On Wed, Dec 15, 2021 at 3:21 PM Enrico Olivelli wrote: > Jonathan, > > Il Mer 15 Dic 2021, 21:11 Jonathan Ellis ha scritto: > > > What are the benefits of cherry picking vs committing to the oldest > > relevant branch and merging forwards? > > > We (and most of the ASF projects I am involved in) ask contributors to > target the master branch for the patches. > > How can we do what you suggest? > Asking people to send PRs against the oldest branch relevant to the patch? > > Probably the contributor is not aware of the other branches. > > Can you please explain more your idea? > > Enrico > > Git is designed around merge since > > that preserves the commit sha which allows it to be tracked across > > branches. And a merge based workflow avoids the problem here by design. > > > > On Wed, Dec 15, 2021 at 1:54 PM Michael Marshall > > wrote: > > > > > Hello Pulsar Community, > > > > > > As far as I can tell, we do not have a publicly defined process for > > > cherry-picking commits to release branches [0]. As a new committer, > > > I'd like to provide my newly gained perspective and ask that we add > > > some guidance to our wiki. > > > > > > Regarding cherry picking, I see two patterns in Pulsar: > > > 1. Some committers cherry pick commits when they merge a PR. > > > 2. Some committers leave PRs to be cherry picked right before tagging > > > the dot release. The release manager is expected to cherry pick these > > > commits. > > > > > > Anecdotally, pattern 2 is more common. > > > > > > I am concerned that pattern 2 creates a lot of extra work for the > > > release manager, leaves the community with little time to build and > > > test release branches before tagging release candidates, and leaves us > > > unable to quickly respond to security issues. > > > > > > If we switch to pattern 1, merging PRs may become more time consuming. > > > However, it lightens the load on release managers and makes the > > > project more nimble. Further, resolving conflicts should be easier, as > > > the committer already has the PR's context, which could reduce the > > > risk of regressions. > > > > > > For example, the 2.7.4 release is delayed because of pattern 2. > > > Penghui and I cherry picked many commits over the recent days because > > > branch-2.7 was not up to date. Now, the tests aren't passing for the > > > branch, and since we shouldn't cut a release until the tests pass, we > > > haven't released the patch for the Log4Shell CVE. > > > > > > Another solution is to remove the expectation that the release manager > > > cherry picks commits. The downside here is that we will possibly miss > > > important bug fixes that would improve dot release stability. > > > > > > I propose that we try to use pattern 1 (or something close to it) for > > > our process. > > > > > > Thanks, > > > Michael > > > > > > [0] https://github.com/apache/pulsar/wiki/Committer-Guide > > > > > > > > > -- > > Jonathan Ellis > > co-founder, http://www.datastax.com > > @spyced > > > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
Re: [DISCUSS] How to handle stale PRs
One problem with the current state is that PRs and even higher level ideas have a shelf life. Declaring PR bankruptcy does in fact solve this problem. The other problem is that from a new contributor's perspective it's impossible to tell which issues are relevant and which are clutter that we haven't gotten around to closing out. For this, declaring PR bankruptcy isn't as good as somehow having the capacity to review and respond to everything, but it's still better than the status quo. And since no large-scale OSS project that I'm aware of has figured out how to review and respond to everything sustainably, I'd settle for an imperfect solution over a perfect one that probably doesn't exist. On Wed, Dec 15, 2021 at 3:12 PM Matteo Merli wrote: > I'm not convinced by having a blanket policy here. > > In several cases, these PRs carried some very valuable ideas that > still needed some work to get merged. By using blanket close, we'd be > losing all that context and we should not do that. > > What would actually be helpful, is help in reviewing these old PRs to > identify what is either already rejected or superseded by other > changes and what just needs some help to get completed. > > Just declaring PR bankrupticity alone won't solve the problem of why > more PRs are created than reviewers can review. > > > Matteo > > -- > Matteo Merli > > > On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall > wrote: > > > > I am +1 for closing PRs that are over a year old. > > > > Does anyone else in the community have thoughts on these old PRs? > > Getting consensus and creating a process here could help make our > > committers more efficient. > > > > - Michael > > > > > > On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote: > > > > > > Agreed. > > > > > > I don't think I understand tison's objection to closing very stale PRs > > > automatically -- if it's gone that long without attention the situation > > > isn't likely to change. And the submitter can always reopen it if it's > > > still relevant. > > > > > > On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: > > > > > > > I think that any Pulsar committer ought to close any PR that is more > than > > > > one year old. That would clear about 75 from the backlog. The OP > should be > > > > informed and if they are still interested then they can discuss it > here. > > > > > > > > So when a stale PR is closed we should suggest that the OP subscribe > to > > > > and email dev@pulsar.apache.org to discuss the PR. > > > > > > > > All the Best, > > > > Dave > > > > . > > > > > On Dec 3, 2021, at 9:17 AM, tison wrote: > > > > > > > > > > From my experience, any process won't work. The only way is to > inspire > > > > more > > > > > reviewers act on PRs. > > > > > > > > > > Instead of talking about how to do it, reviewing one PR now can > help the > > > > > case. > > > > > Also, it's reasonable to close inactive PR if there is a > successor. But > > > > do > > > > > not let > > > > > a bot do it, which will create many corner (bad) cases. > > > > > > > > > > Best, > > > > > tison. > > > > > > > > > > > > > > > Michael Marshall 于2021年12月4日周六 00:57写道： > > > > > > > > > >> Hi Pulsar Community, > > > > >> > > > > >> I am excited to start contributing as a committer! I have a > question > > > > >> about our process for closing stale PRs. > > > > >> > > > > >> We have ~300 open PRs right now. Do we have any guidelines on > closing > > > > >> stale PRs? Of course we don't want to ignore important bug fixes, > but > > > > >> we also don't want to clutter our repo with open PRs that won't > get > > > > merged. > > > > >> > > > > >> For example, I reviewed this PR [0] about 3 months ago. The > > > > >> contributor has not yet responded to my feedback and it doesn't > seem > > > > >> to fix an actual bug, so I think it is a candidate for closure. > Here > > > > >> is another example [1]. I closed this one because it had merge > > > > >> conflicts with a commit that fixed the same underlying issue. > > > > >> > > > > >> Note that our committer guidelines [2] do not provide guidance on > this > > > > >> subject. > > > > >> > > > > >> [0] - https://github.com/apache/pulsar/pull/11237 > > > > >> [1] - https://github.com/apache/pulsar/pull/11162 > > > > >> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide > > > > >> > > > > >> Thanks, > > > > >> Michael > > > > >> > > > > > > > > > > > > > > -- > > > Jonathan Ellis > > > co-founder, http://www.datastax.com > > > @spyced > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
Re: [DISCUSS] How to handle stale PRs
I’d like to point out that if we label auto-closed PRs properly it is easy enough to find them in the GitHub UI. > On Dec 15, 2021, at 3:05 PM, Jonathan Ellis wrote: > > One problem with the current state is that PRs and even higher level ideas > have a shelf life. Declaring PR bankruptcy does in fact solve this problem. > > The other problem is that from a new contributor's perspective it's > impossible to tell which issues are relevant and which are clutter that we > haven't gotten around to closing out. > > For this, declaring PR bankruptcy isn't as good as somehow having the > capacity to review and respond to everything, but it's still better than > the status quo. And since no large-scale OSS project that I'm aware of has > figured out how to review and respond to everything sustainably, I'd settle > for an imperfect solution over a perfect one that probably doesn't exist. > > > On Wed, Dec 15, 2021 at 3:12 PM Matteo Merli wrote: > >> I'm not convinced by having a blanket policy here. >> >> In several cases, these PRs carried some very valuable ideas that >> still needed some work to get merged. By using blanket close, we'd be >> losing all that context and we should not do that. >> >> What would actually be helpful, is help in reviewing these old PRs to >> identify what is either already rejected or superseded by other >> changes and what just needs some help to get completed. >> >> Just declaring PR bankrupticity alone won't solve the problem of why >> more PRs are created than reviewers can review. >> >> >> Matteo >> >> -- >> Matteo Merli >> >> >> On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall >> wrote: >>> >>> I am +1 for closing PRs that are over a year old. >>> >>> Does anyone else in the community have thoughts on these old PRs? >>> Getting consensus and creating a process here could help make our >>> committers more efficient. >>> >>> - Michael >>> >>> >>> On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis wrote: Agreed. I don't think I understand tison's objection to closing very stale PRs automatically -- if it's gone that long without attention the situation isn't likely to change. And the submitter can always reopen it if it's still relevant. On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: > I think that any Pulsar committer ought to close any PR that is more >> than > one year old. That would clear about 75 from the backlog. The OP >> should be > informed and if they are still interested then they can discuss it >> here. > > So when a stale PR is closed we should suggest that the OP subscribe >> to > and email dev@pulsar.apache.org to discuss the PR. > > All the Best, > Dave > . >> On Dec 3, 2021, at 9:17 AM, tison wrote: >> >> From my experience, any process won't work. The only way is to >> inspire > more >> reviewers act on PRs. >> >> Instead of talking about how to do it, reviewing one PR now can >> help the >> case. >> Also, it's reasonable to close inactive PR if there is a >> successor. But > do >> not let >> a bot do it, which will create many corner (bad) cases. >> >> Best, >> tison. >> >> >> Michael Marshall 于2021年12月4日周六 00:57写道： >> >>> Hi Pulsar Community, >>> >>> I am excited to start contributing as a committer! I have a >> question >>> about our process for closing stale PRs. >>> >>> We have ~300 open PRs right now. Do we have any guidelines on >> closing >>> stale PRs? Of course we don't want to ignore important bug fixes, >> but >>> we also don't want to clutter our repo with open PRs that won't >> get > merged. >>> >>> For example, I reviewed this PR [0] about 3 months ago. The >>> contributor has not yet responded to my feedback and it doesn't >> seem >>> to fix an actual bug, so I think it is a candidate for closure. >> Here >>> is another example [1]. I closed this one because it had merge >>> conflicts with a commit that fixed the same underlying issue. >>> >>> Note that our committer guidelines [2] do not provide guidance on >> this >>> subject. >>> >>> [0] - https://github.com/apache/pulsar/pull/11237 >>> [1] - https://github.com/apache/pulsar/pull/11162 >>> [2] - https://github.com/apache/pulsar/wiki/Committer-Guide >>> >>> Thanks, >>> Michael >>> > > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced >> > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced
Re: [DISCUSS] How to handle stale PRs
It isn't even an issue related to OSS - every long lived project suffers from this same issue. Whether it's a long lingering defect report or a fix that never got integrated in a timely manner, time wounds all heels. Careful considered review is perfection which can't be hit; if it could be done, the situation would never have occured in the first place. Having a time-to-live is pragmatic, not perfect, but pragmatic. As Jonathan mentioned, if ideas or changes linger too long, they often are superceded or replaced with more applicable alternatives or might not have been that important in the first place. It's a shame because each languishing PR represents some amount of work from someone (sometimes a non-trivial amount) but there really isn't a more practical alternative IMO. On Wed, Dec 15, 2021 at 5:05 PM Jonathan Ellis wrote: > One problem with the current state is that PRs and even higher level ideas > have a shelf life. Declaring PR bankruptcy does in fact solve this > problem. > > The other problem is that from a new contributor's perspective it's > impossible to tell which issues are relevant and which are clutter that we > haven't gotten around to closing out. > > For this, declaring PR bankruptcy isn't as good as somehow having the > capacity to review and respond to everything, but it's still better than > the status quo. And since no large-scale OSS project that I'm aware of has > figured out how to review and respond to everything sustainably, I'd settle > for an imperfect solution over a perfect one that probably doesn't exist. > > > On Wed, Dec 15, 2021 at 3:12 PM Matteo Merli > wrote: > > > I'm not convinced by having a blanket policy here. > > > > In several cases, these PRs carried some very valuable ideas that > > still needed some work to get merged. By using blanket close, we'd be > > losing all that context and we should not do that. > > > > What would actually be helpful, is help in reviewing these old PRs to > > identify what is either already rejected or superseded by other > > changes and what just needs some help to get completed. > > > > Just declaring PR bankrupticity alone won't solve the problem of why > > more PRs are created than reviewers can review. > > > > > > Matteo > > > > -- > > Matteo Merli > > > > > > On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall > > wrote: > > > > > > I am +1 for closing PRs that are over a year old. > > > > > > Does anyone else in the community have thoughts on these old PRs? > > > Getting consensus and creating a process here could help make our > > > committers more efficient. > > > > > > - Michael > > > > > > > > > On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis > wrote: > > > > > > > > Agreed. > > > > > > > > I don't think I understand tison's objection to closing very stale > PRs > > > > automatically -- if it's gone that long without attention the > situation > > > > isn't likely to change. And the submitter can always reopen it if > it's > > > > still relevant. > > > > > > > > On Fri, Dec 3, 2021 at 1:17 PM Dave Fisher wrote: > > > > > > > > > I think that any Pulsar committer ought to close any PR that is > more > > than > > > > > one year old. That would clear about 75 from the backlog. The OP > > should be > > > > > informed and if they are still interested then they can discuss it > > here. > > > > > > > > > > So when a stale PR is closed we should suggest that the OP > subscribe > > to > > > > > and email dev@pulsar.apache.org to discuss the PR. > > > > > > > > > > All the Best, > > > > > Dave > > > > > . > > > > > > On Dec 3, 2021, at 9:17 AM, tison wrote: > > > > > > > > > > > > From my experience, any process won't work. The only way is to > > inspire > > > > > more > > > > > > reviewers act on PRs. > > > > > > > > > > > > Instead of talking about how to do it, reviewing one PR now can > > help the > > > > > > case. > > > > > > Also, it's reasonable to close inactive PR if there is a > > successor. But > > > > > do > > > > > > not let > > > > > > a bot do it, which will create many corner (bad) cases. > > > > > > > > > > > > Best, > > > > > > tison. > > > > > > > > > > > > > > > > > > Michael Marshall 于2021年12月4日周六 00:57写道： > > > > > > > > > > > >> Hi Pulsar Community, > > > > > >> > > > > > >> I am excited to start contributing as a committer! I have a > > question > > > > > >> about our process for closing stale PRs. > > > > > >> > > > > > >> We have ~300 open PRs right now. Do we have any guidelines on > > closing > > > > > >> stale PRs? Of course we don't want to ignore important bug > fixes, > > but > > > > > >> we also don't want to clutter our repo with open PRs that won't > > get > > > > > merged. > > > > > >> > > > > > >> For example, I reviewed this PR [0] about 3 months ago. The > > > > > >> contributor has not yet responded to my feedback and it doesn't > > seem > > > > > >> to fix an actual bug, so I think it is a candidate for closure. > > Here > > > > > >> is another example [1]. I closed this one b
Re: [DISCUSS] How to handle stale PRs
> Is #3267 Support set publish time on broker side one of those very valuable > ideas that was later rejected, likely for performance reasons? No, this was one that was superseded by other changes. > One problem with the current state is that PRs and even higher level ideas > have a shelf life. Declaring PR bankruptcy does in fact solve this problem. I don't believe that is true in all cases and I absolutely don't believe that it is not possible to keep up with the PRs, when the reviewing workload is well balanced. I'm seeing a lot of opinions here, but at the end of the day the people doing the hard work of reviewing are always the same few ones. > Once we have guidance, I am happy to add it to the Committer Guide on the wiki [0]. Michael, I agree 100% with that. We should write clear guidelines to describe when it makes sense to close, leave for the record, call for "help" to continue working on and so on. That will help committers and contributors. > Matteo, your comment raises an additional question for me. What are > Apache's rules for completing someone else's contribution? If someone > opens a PR to fix a bug, but it is incomplete and they become > unresponsive, how can we move their contribution forward? These are > the PRs we don't want to close. I don't think there is any problem in completing someone else's PR, provided that: * The original author is non-responsive or has no time to work on it at the moment (otherwise it would be kind of rude). * We give the right credit to the original author (github has good support for multiple authorship of a commit) Continuing with a PR is not very different from merging the WIP and fixing it later in a second commit, from a legal perspective. IANAL, though *AFAIU*, when a contributor is opening a PR is already assigning the IP to the ASF. A committer will merge that code (after due diligence that it doesn't contain inadmissible code), but the code is already "donated to the ASF" at the moment of the PR. -- Matteo Merli On Wed, Dec 15, 2021 at 3:14 PM Chris Herzog wrote: > > It isn't even an issue related to OSS - every long lived project suffers > from this same issue. Whether it's a long lingering defect report or a fix > that never got integrated in a timely manner, time wounds all heels. > > Careful considered review is perfection which can't be hit; if it could be > done, the situation would never have occured in the first place. Having a > time-to-live is pragmatic, not perfect, but pragmatic. > > As Jonathan mentioned, if ideas or changes linger too long, they often are > superceded or replaced with more applicable alternatives or might not have > been that important in the first place. It's a shame because each > languishing PR represents some amount of work from someone (sometimes a > non-trivial amount) but there really isn't a more practical alternative IMO. > > > > On Wed, Dec 15, 2021 at 5:05 PM Jonathan Ellis wrote: > > > One problem with the current state is that PRs and even higher level ideas > > have a shelf life. Declaring PR bankruptcy does in fact solve this > > problem. > > > > The other problem is that from a new contributor's perspective it's > > impossible to tell which issues are relevant and which are clutter that we > > haven't gotten around to closing out. > > > > For this, declaring PR bankruptcy isn't as good as somehow having the > > capacity to review and respond to everything, but it's still better than > > the status quo. And since no large-scale OSS project that I'm aware of has > > figured out how to review and respond to everything sustainably, I'd settle > > for an imperfect solution over a perfect one that probably doesn't exist. > > > > > > On Wed, Dec 15, 2021 at 3:12 PM Matteo Merli > > wrote: > > > > > I'm not convinced by having a blanket policy here. > > > > > > In several cases, these PRs carried some very valuable ideas that > > > still needed some work to get merged. By using blanket close, we'd be > > > losing all that context and we should not do that. > > > > > > What would actually be helpful, is help in reviewing these old PRs to > > > identify what is either already rejected or superseded by other > > > changes and what just needs some help to get completed. > > > > > > Just declaring PR bankrupticity alone won't solve the problem of why > > > more PRs are created than reviewers can review. > > > > > > > > > Matteo > > > > > > -- > > > Matteo Merli > > > > > > > > > On Wed, Dec 15, 2021 at 1:05 PM Michael Marshall > > > wrote: > > > > > > > > I am +1 for closing PRs that are over a year old. > > > > > > > > Does anyone else in the community have thoughts on these old PRs? > > > > Getting consensus and creating a process here could help make our > > > > committers more efficient. > > > > > > > > - Michael > > > > > > > > > > > > On Fri, Dec 3, 2021 at 1:25 PM Jonathan Ellis > > wrote: > > > > > > > > > > Agreed. > > > > > > > > > > I don't think I understand tison's objectio
Re: [DISCUSS] How to handle stale PRs
> On Dec 15, 2021, at 4:06 PM, Matteo Merli wrote: > >> Is #3267 Support set publish time on broker side one of those very valuable >> ideas that was later rejected, likely for performance reasons? > > No, this was one that was superseded by other changes. Then I’ll close it. > >> One problem with the current state is that PRs and even higher level ideas >> have a shelf life. Declaring PR bankruptcy does in fact solve this problem. > > I don't believe that is true in all cases and I absolutely don't > believe that it is not possible to keep up with the PRs, when the > reviewing workload is well balanced. > > I'm seeing a lot of opinions here, but at the end of the day the > people doing the hard work of reviewing are always the same few ones. (1) These are opinions about how to do the work. If you want someone to JFDI it then I’m happy to start closing and labeling as I suggested. (2) There is a kind of deference being shown to those individuals based on who the contributor selects for review. I wish there was a way for a contributor to ask the dev list for a review. > >> Once we have guidance, I am happy to add it to the Committer Guide on > the wiki [0]. > > Michael, I agree 100% with that. We should write clear guidelines to > describe when it makes sense to close, leave for the record, call for > "help" to continue working on and so on. That will help committers and > contributors. > >> Matteo, your comment raises an additional question for me. What are >> Apache's rules for completing someone else's contribution? If someone >> opens a PR to fix a bug, but it is incomplete and they become >> unresponsive, how can we move their contribution forward? These are >> the PRs we don't want to close. > > I don't think there is any problem in completing someone else's PR, > provided that: > * The original author is non-responsive or has no time to work on it > at the moment (otherwise it would be kind of rude). > * We give the right credit to the original author (github has good > support for multiple authorship of a commit) > > Continuing with a PR is not very different from merging the WIP and > fixing it later in a second commit, from a legal perspective. > > IANAL, though *AFAIU*, when a contributor is opening a PR is already > assigning the IP to the ASF. A committer will merge that code (after > due diligence that it doesn't contain inadmissible code), but the code > is already "donated to the ASF" at the moment of the PR. +1. Regards, Dave > > > -- > Matteo Merli > > > > On Wed, Dec 15, 2021 at 3:14 PM Chris Herzog > wrote: >> >> It isn't even an issue related to OSS - every long lived project suffers >> from this same issue. Whether it's a long lingering defect report or a fix >> that never got integrated in a timely manner, time wounds all heels. >> >> Careful considered review is perfection which can't be hit; if it could be >> done, the situation would never have occured in the first place. Having a >> time-to-live is pragmatic, not perfect, but pragmatic. >> >> As Jonathan mentioned, if ideas or changes linger too long, they often are >> superceded or replaced with more applicable alternatives or might not have >> been that important in the first place. It's a shame because each >> languishing PR represents some amount of work from someone (sometimes a >> non-trivial amount) but there really isn't a more practical alternative IMO. >> >> >> >> On Wed, Dec 15, 2021 at 5:05 PM Jonathan Ellis wrote: >> >>> One problem with the current state is that PRs and even higher level ideas >>> have a shelf life. Declaring PR bankruptcy does in fact solve this >>> problem. >>> >>> The other problem is that from a new contributor's perspective it's >>> impossible to tell which issues are relevant and which are clutter that we >>> haven't gotten around to closing out. >>> >>> For this, declaring PR bankruptcy isn't as good as somehow having the >>> capacity to review and respond to everything, but it's still better than >>> the status quo. And since no large-scale OSS project that I'm aware of has >>> figured out how to review and respond to everything sustainably, I'd settle >>> for an imperfect solution over a perfect one that probably doesn't exist. >>> >>> >>> On Wed, Dec 15, 2021 at 3:12 PM Matteo Merli >>> wrote: >>> I'm not convinced by having a blanket policy here. In several cases, these PRs carried some very valuable ideas that still needed some work to get merged. By using blanket close, we'd be losing all that context and we should not do that. What would actually be helpful, is help in reviewing these old PRs to identify what is either already rejected or superseded by other changes and what just needs some help to get completed. Just declaring PR bankrupticity alone won't solve the problem of why more PRs are created than reviewers can review. Matteo -- >>>
Re: [VOTE] Pulsar Node.js Client Release 1.5.0 Candidate 1
+1 (binding) * check the license headers * build the source and run producer/consumer * verify checksum and signatures == Hiroyuki Sakai Yahoo Japan Corp. E-mail: hsa...@yahoo-corp.jp From: Masahiro Sakamoto Sent: Tuesday, December 14, 2021 17:55 To: dev@pulsar.apache.org Subject: [VOTE] Pulsar Node.js Client Release 1.5.0 Candidate 1 Hi everyone, Please review and vote on the release candidate #1 for the version 1.5.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) This is the first release candidate for Apache Pulsar Node.js client, version 1.5.0. It fixes the following issues: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fpulsar-client-node%2Fmilestone%2F7%3Fclosed%3D1&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C228460548f654cc2358e08d9bedf8c0a%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637750690187071958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=l5erf4AyIdnXqXTP%2B%2FEOyePQD%2FtTfxeTxnd7yLA%2FxSo%3D&reserved=0 Please download the source files and review this release candidate: - Review release notes - Download the source package (verify shasum and asc) and follow the README.md to build and run the Pulsar Node.js client. The vote will be open for at least 72 hours. It is adopted by majority approval, with at least 3 PMC affirmative votes. Source files: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fpulsar%2Fpulsar-client-node%2Fpulsar-client-node-1.5.0-candidate-1%2F&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C228460548f654cc2358e08d9bedf8c0a%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637750690187071958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WAX42CoKhaMbUv3nmyK%2FSGCnm5LlRiGBW1XStJ9mzZI%3D&reserved=0 Pulsar's KEYS file containing PGP keys we use to sign the release: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fpulsar%2FKEYS&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C228460548f654cc2358e08d9bedf8c0a%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637750690187071958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1NNW8t4M7NsgMo6FHK9%2FydD2FwObWeG3IaXWSm%2FU9jo%3D&reserved=0 SHA-512 checksum: 5c05c5368fb822165dde5c3aa758d600eca4452e1cc160f9b53311e27436e4cd52fbc55ca6382bb56019e4b0a3a6a409f73eec7c19844fb60715e41348fd8c09 pulsar-client-node-1.5.0.tar.gz The tag to be voted upon: v1.5.0-rc.1 https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fpulsar-client-node%2Freleases%2Ftag%2Fv1.5.0-rc.1&data=04%7C01%7Chsakai%40yahoo-corp.jp%7C228460548f654cc2358e08d9bedf8c0a%7Ca208d369cd4e4f87b11998eaf31df2c3%7C1%7C0%7C637750690187071958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hs8Z%2BBw%2BmXnO5RYc2AwFgPnrwC%2BWVyS4VKJ4IpArTq8%3D&reserved=0 Masahiro Sakamoto Yahoo Japan Corp. E-mail: massa...@yahoo-corp.jp
Re: [DISCUSSION] PIP-118: Do not restart brokers when ZooKeeper session expires
+1 Great PIP. Long expected. Small question about new parameter "zookeeperSessionExpiredPolicy", now we have Etcd implementation for metadata store, is it better to use "metadataStoreExpiredPolicy" ? On 2021/12/14 18:03:20 Matteo Merli wrote: > https://github.com/apache/pulsar/issues/13304 > > > Pasted below for quoting convenience. > > --- > > > ## Motivation > > After all the work done for PIP-45 that was already included in 2.8 and 2.9 > releases, it enabled the concept of re-acquirable resource locks and leader > election. > > Another important change was to avoid doing any deferrable metadata operation > when we know that we are not currently connected to the metadata service. > > Finally, that enabled stabilization in 2.9 the configuration setting that > allows > brokers to continue operating in a safe mode when the session with ZooKeeper > expires. > > The way it works is that, when we lose a ZooKeeper session, the data plane > will > continue to work undisturbed, relying on the BookKeeper fencing to avoid any > inconsistencies. > > New topics are not able to get started, but existing topics will see no > impact. > > The original intention for shutting down the brokers was to ensure that we > would automatically go back to a consistent state, with respect to which > resources are "owned" in ZooKeeper by a given broker. > > With the re-acquirable resource locks, that problem was solved and thoroughly > tested to be robust. > > ## Proposed changes > > In 2.10 release, for the setting: > > ```properties > # There are two policies to apply when a broker metadata session > expires: session expired happens, "shutdown" or "reconnect". > # With "shutdown", the broker will be restarted. > # With "reconnect", the broker will keep serving the topics, while > attempting to recreate a new session. > zookeeperSessionExpiredPolicy=shutdown > ``` > > Change its default value to `reconnect`. > > > -- > Matteo Merli > >
Re: [DISCUSSION] PIP-118: Do not restart brokers when ZooKeeper session expires
On Wed, Dec 15, 2021 at 5:47 PM Haiting Jiang wrote: > Small question about new parameter "zookeeperSessionExpiredPolicy", now we > have Etcd implementation for metadata store, is it better to use > "metadataStoreExpiredPolicy" ? Good point, we should also use this occasion to deprecate the `zookeeperSessionExpiredPolicy` key (and moving it to the end of the config files, in the deprecated section) and add the setting.
Re: [DISCUSSION] PIP-117: Change Pulsar standalone defaults
Hi Enrico, This migration tool is a better-to-have and mostly about metadata store part. Some of our user use Standalone in a long running test environment, with this migration tool they do not need to recreate all the topics and subscriptions manually and take these benefits with new default settings. And furthermore, since we have different kinds of metadata store implementations, metadata migration is a potential requirement. Just some brief thoughts yet. I think we can start a new DISCUSSION on this. Thanks, Haiting On 2021/12/15 11:09:22 Enrico Olivelli wrote: > +1 > > @Haiting > Pulsar Standalone is usually used for local development, I am not sure you > need a migration tool. > You can still keep the configuration to use previously (standalone.conf) > > Enrico > > Il giorno mer 15 dic 2021 alle ore 10:56 Haiting Jiang < > jianghait...@apache.org> ha scritto: > > > +1 (non-binding) > > > > Out of the scope of this PIP, a follow up data migration tool could be > > added to help migration from old settings without data loss. > > > > --- > > Haiting > > > > On 2021/12/15 01:04:21 Hang Chen wrote: > > > +1 > > > > > > Thanks, > > > Hang > > > > > > PengHui Li 于2021年12月15日周三 07:52写道： > > > > > > > > +1 > > > > > > > > Penghui > > > > > > > > On Wed, Dec 15, 2021 at 1:18 AM Matteo Merli > > wrote: > > > > > > > > > https://github.com/apache/pulsar/issues/13302 > > > > > > > > > > Copying here for quoting convenience > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ## Motivation > > > > > > > > > > Pulsar standalone is the "Pulsar in a box" version of a Pulsar > > cluster, > > > > > where > > > > > all the components are started within the context of a single JVM > > process. > > > > > > > > > > Users are using the standalone as a way to get quickly started with > > Pulsar > > > > > or > > > > > in all the cases where it makes sense to have a single node > > deployment. > > > > > > > > > > Right now, the standalone is starting by default with many > > components, > > > > > several of > > > > > which are quite complex, since they are designed to be deployed in a > > > > > distributed > > > > > fashion. > > > > > > > > > > ## Goal > > > > > > > > > > Simplify the components of Pulsar standalone to achieve: > > > > > > > > > > 1. Reduce complexity > > > > > 2. Reduce startup time > > > > > 3. Reduce memory and CPU footprint of running standalone > > > > > > > > > > ## Proposed changes > > > > > > > > > > The proposal here is to change some of the default implementations > > that are > > > > > used for the Pulsar standalone. > > > > > > > > > > 1. **Metadata Store implementation** --> > > > > > Change from ZooKeeper to RocksDB > > > > > > > > > > 2. **Pulsar functions package backend** --> > > > > > Change from using DistributedLog to using local filesystem, > > storing > > > > > the > > > > > jars directly in the data folder instead of uploading them > > into BK. > > > > > > > > > > 3. **Pulsar functions state store implementation** --> > > > > > Change the state store to be backed by a MetadataStore based > > backed, > > > > > with the RocksDB implementation. > > > > > > > > > > 4. **Table Service** --> > > > > > Do not start BK table service by default > > > > > > > > > > ## Compatibility considerations > > > > > > > > > > In order to avoid compatibility issues where users have existing > > Pulsar > > > > > standalone services that they want to upgrade without conflicts, we > > will > > > > > follow the principle of keeping the old defaults where there is > > existing > > > > > data on the disk. > > > > > > > > > > We will add a file, serving the purpose as a flag, in the > > `data/standalone` > > > > > directory, for example `new-2.10-defaults`. > > > > > > > > > > If the file is present, or if the data directory is completely > > missing, we > > > > > will adopt the new set of default configuration settings. > > > > > > > > > > If the file is not there, we will continue to use existing defaults > > and we > > > > > will > > > > > not break the upgrade operation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Matteo Merli > > > > > > > > > > > > > > > >
Re: PIP 116: Create Pulsar Writing Style Guide
Hi Haiting, There are no automatic tools to check **all** writing style issues, but they can help check some. Steps see https://docs.google.com/document/d/1Qw7LHQdXWBW9t2-r-A7QdFDBwmZh6ytB4guwMoXHqc0/edit Hi Dave, Thanks! I've incorporated your comments. On Thu, Dec 16, 2021 at 2:34 AM Dave Fisher wrote: > Thanks Yu for this initiative. > > I made a small correction in the document. > > Regards, > Dave > > > On Dec 14, 2021, at 7:17 PM, Yu wrote: > > > > Hi Pulsar enthusiasts, > > > > > > As you may notice, there are more and more documentation contributions > > nowadays, which is great! > > > > > > Similar to coding style guides, in the field of technical writing, a > > writing style guide is a must to improve users' experience and eliminate > > writers' workload. > > > > > > To improve the doc quality, I create our style guide — *Pulsar Writing > > Style Guide* [1] > > > > > > # Definition > > > > > > Pulsar Writing Style Guide contains a set of standards for writing and > > designing content. > > > > > > It helps maintain a consistent style, voice, and tone across Pulsar > > documentation. > > > > > > This guide is inspired by some existing style guides. It references *IBM > > Style Guide*, *Chicago Manual of Style*, and other books for more > > exhaustive guidance. > > > > > > # Benefits > > > > > > Pulsar Writing Style Guide can improve the content quality and bring many > > benefits to users and writers like: > > > > > > For users: > > > > - Make documentation easier to read > > > > - Reduce users’ cognitive load > > > > - Increase users' confidence in the content’s authority > > > > > > For information developers: > > > > - Resolve arguments and support our needs to create readable, usable, and > > minimalist information > > > > - Save time and trouble by providing a single reference for writing about > > common topics, features, and more > > > > - Help write documentation in a clearer way and keep a consistent tone of > > voice and style > > > > > >>> > > > > > > This guide is not a one-shot job, the current version is an initial > draft. > > I'll make continuous efforts on that. > > > > > > I believe that the Pulsar community will welcome this addition to our > > resources and profit from the instructions. > > > > > > Feel free to comment, thanks. > > > > > > [1] > > > https://docs.google.com/document/d/1lc5j4RtuLIzlEYCBo97AC8-U_3Erzs_lxpkDuseU0n4/edit# > >
[GitHub] [pulsar-dotpulsar] usaguerrilla closed pull request #93: Feature/microbatching parallel consumer
usaguerrilla closed pull request #93: URL: https://github.com/apache/pulsar-dotpulsar/pull/93 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
