这个作业的要求是: 第一次作业 (看开源的资料,提五个问题)-CSDN社区
而对于开源小白来说,你可以从自身的技术兴趣出发来选择想要参与的开源方向,如果对数据库感兴趣,那 TDengine 就是一个非常适合上手学习的开源项目,如果是对消息队列感兴趣可以选择Kafka。
对此我有一个疑问:在确定自己感兴趣的方向后,有什么好的方式去寻找一个合适自己的开源项目来参与?
在这段话中,作者为对数据库和消息队列感兴趣的人提供了两个选择,但我更感兴趣的是有没有这样一个好的寻找手段,能够方便“开源小白”去找到这样的合适自己的开源项目。
2.还是在上面那一篇文章中,我读到:
如果你对 C 语言并不熟悉,那我建议你也可以从学习 TDengine 生态应用软件的源代码开始,还可以通过学习 TDengine 的测试脚本来学习如何对基础软件进行测试。
作者为对C语言不熟悉的“开源小白”提供了开始的思路,也就是在参与开源项目前可以做的事。我还想知道:这种方法是否可以延伸到其它语言或方向,或者说想要参与到某一开源项目中,有哪些工作是最好能提前做好的?
3.在
虽然,第一次提交之后,尽管没有结果,依然让我熟悉了这个流程,后续还是尝试提交了一些pr,大部分没被接受,只有两个后续被接受了。
作者在最初几次pr的时候大部分都没被接受。我对此的疑问是:一般而言代码不被接受是出于什么原因?如果pr被拒项目维护者是否会告知拒绝的理由?以及如何让自己的代码更容易被开源项目接受?
从这里可以看出,Linux社区最稀缺的资源是两个:代码审查(Review)和测试(Testing)。我也是那个时候才知道,社区鼓励发小而美的补丁——抛出一大坨令人望而生畏的补丁集,很容易劝退查看者(至少会让人产生“等我有大块空闲时间了再来消化”的想法)。
对此我的疑问是:作为开源项目的维护者,如何高效地审查提交的代码?小而美的补丁固然好,但也不总是那么容易得到的,尤其对于一些并不热门的开源项目来说。
5.在上面那篇文章中,我还读到:
Linux现在的主要贡献都来自各家公司的雇员,这可能是世界上最广泛的一个跨公司合作开源项目。那么,Linux社区如何协调和引导如此众多的公司完成协作,避免冲突?这是个不小的挑战,尤其是其中有不少互为竞争对手的公司,在一些热点问题上可能希望竞争主导权、话语权,以及有利于自身的实现。
协调与引导众多开发者并非易事,我好奇这种工作是否也会体现到开源软件开发的进程中来,或者说开源项目和其它一般项目相比,开发流程的区别主要体现在哪里?