To ZhaoChun:
We all know that we are discussing the implementation of this feature of the vectorization engine. So let's discuss this issue directly. First of all, the design of the vectorization engine started very early. We established the project[1] and introduced the implementation route, code source and follow-up todo in detail in the proposal[2][3]. So I don't think this is an unorganized feature development and code submission. In addition, just as your company implements its own commercial version based on the open source version of Apache Doris, the use of the code is compliant at the license level, and we are also communicating and discussing with the clickhouse community, so I don’t think this is a reputational detriment. As far as I know, your company first published an article with provocative meaning against the clickhouse community, and used the name DorisDB, which does not comply with the Apache trademark usage specifications, which made people mistaken for the behavior of the Apache Doris community. So I think your company should clarify the matter first and bear the corresponding consequences for the issue of reputation. And as a member of PPMC and the code maintainer of Apache Doris, I think you and your company clearly understand the importance of vectorization engine to Doris. But in the past year, you have implemented the vectorization engine in the commercial version, but have never submitted any relevant code or discussion in the Doris community. If it is just the behavior of the commercial company itself, I think it is understandable. But when the Doris community started to implement the vectorization engine based on its own considerations, you were the first to stand up and object, and you have never participated in the discussion of this project before. Of course, as a committer, you have the right to raise objections, but I have to doubt your motives. [1] https://github.com/apache/incubator-doris/projects/14 [2] https://github.com/apache/incubator-doris/issues/6238 [3] https://github.com/doris-vectorized/doris-vectorized/issues/49 -- 此致！Best Regards 陈明雨 Mingyu Chen Email: chenmin...@apache.org At 2021-07-17 22:51:58, "Zhao Chun" <zh...@apache.org> wrote: >When we make a new feature, we should have our own design as well as >solution. >In the specific implementation process, it can be a continuous iterative >process. >When determining how a big project should be carried out, >we should at least agree on the macro goals, key design ideas, and >milestone before starting the specific work. > >And as for the code implementation level, we should also follow our own >plan to achieve it. >If there is code from other projects that can help us to achieve it >quickly, I think it is possible to learn from it. >For example, we borrowed a fast hash table implementation to help us >implement aggregation faster. > >However, I am against the case of copying a lot of code without any macro >design of our own. >On the one hand, such behavior is incompatible with our existing content, >making the whole project look like a hodgepodge and complicating our whole >system. >On the other hand such behavior can also give our system a bad reputation. > >Thanks, >Zhao Chun > > >陈明雨 <morning...@163.com> 于2021年7月17日周六 下午10:32写道： > >> “In addition, if the amount of copied code is relatively large, it is >> better to obtain the consent of the original open source community without >> violating the open source license.”This is an important thing we need to do. >> >> >> >> -- >> >> 此致！Best Regards >> 陈明雨 Mingyu Chen >> >> Email: >> chenmin...@apache.org >> >> >> >> >> 在 2021-07-17 22:18:30，"陈明雨" <morning...@163.com> 写道： >> >> Translate to English from last mail: >> >> >> ” >> I personally think that the spirit of open source is "spread, improve and >> then spread", so it is normal to directly refer to the code of other >> projects in Doris code. >> But for the sake of respecting other people's work, I think there are more >> things to do. >> >> >> The following sub situations are discussed: >> >> >> 1. Because the implementation of the origin standard library is not >> compatible with Doris's existing scenarios, some modifications are needed. >> >> For example, bitmap_value.h, binary storage format can not meet the >> requirements of Doris, so we can only copy the code into Doris code and >> modify it. >> >> The key point here is that in addition to indicating which version of >> fork's bitmap code is implemented, it is also necessary to describe clearly >> what modifications >> have been made to facilitate later people to understand the code more >> quickly. >> >> >> >> 2. It refers to the implementation or design of other open source >> libraries, which greatly improves the stability / performance / code style >> of Apache Doris. >> >> If it's a code-level reference, it's better to specify the code >> version and indicate the source. >> >> If there are improvements to the original scheme or code, it is better >> to describe the improvement points clearly. >> And for this kind of improvement, it is better to make a PR to the >> original project, of course, this cost may be relatively large. I think >> it's OK to submit the proposal to the original project. >> >> >> In addition, if the amount of copied code is relatively large, it is >> better to obtain the consent of the original open source community without >> violating the open source license. >> >> I believe that any community with open source spirit should be more >> willing to verify and improve its design or solution in a wider range of >> scenarios. >> >> If you just change the class name of the copy and paste, it is a double >> lose situation. >> >> >> >> I hope that the above can become the development specification of Doris >> community and the standard of subsequent code review. >> >> If you have different opinions or suggestions, you are also welcome to >> exchange and discuss. >> >> “ >> >> >> >> -- >> >> 此致！Best Regards >> 陈明雨 Mingyu Chen >> >> Email: >> morning...@163.com; >> morningman....@gmail.com >> >> >> >> >> >> 在 2021-07-17 14:18:44，"王博" <506340...@qq.com.INVALID> 写道： >> >> >我个人认为的开源的精神是“传播改良再传播”，因此在Doris代码中直接引用其他项目的代码属于正常情况。但出于尊重他人劳动成果的考虑，我觉得还有更多事情可以做。 >> >以下分情况讨论： >> >1 由于标准类库实现与Doris现有场景不兼容，需要做一些改造。 >> >比如be代码中的bitmap_value.h，二进制存储格式无法满足Doris场景的要求，因此只能把代码拷贝到Doris的代码中并对其进行改造。 >> >这里的重点是，除了要注明是fork的哪个版本的bitmap代码实现外，还要描述清楚具体做了哪些改造，方便后来的人更快地理解代码。 >> > >> > >> >2 参考了其他开源库的实现或者设计，对Apache Doris的稳定性/性能/代码风格等提升较大。 >> >如果是代码层的引用最好说明代码版本，标明出处。 >> >> >如果对原有方案或者代码有改进，也最好描述清楚改进点。并且这种改进，最理想的情况是给原项目提pr，当然这样开发成本可能比较大。我觉得可以以提案的方式提交到原社区也是可以的。 >> >另外就是如果复制的代码量比较大，在不违反开源协议的前提下，最好是与获得原开源社区的同意。 >> >我相信任何一个有开源精神的社区，应该都会比较乐意自己的设计或者方案在更加广泛的场景下得到验证和改进。 >> >如果仅仅是改了类名的复制粘贴，对大家都是双输的局面。 >> > >> > >> >个人比较期望上述可以成为Doris社区的开发规范，也成为后续代码review的标准。 >> >如果有不同的意见或者建议，也欢迎交流讨论。 >> >> >> >> >> >>
