标签 GNU 下的文章

lcut 0.3.0版本发布

lcut单元测试框架在我的项目中应用已经有一段时间了,项目组的同事对lcut的使用也是越来越熟悉,这不今天一位同事还提出了一个新需求,需求大致是这样的。

 
在实际项目中,经常遇到这类情况:
 
int bar(…) {
    int ret;
 
    ret = foo(…);
    /* assert ret */
    …
 
    ret = foo(…);
    /* assert ret */
    …
 
    ret = foo(…);
    /* assert ret */
    …
}
 
上述代码中被测函数接口bar的实现中多次调用了某函数foo。这样当我们用mock方式测试bar这个函数时,可能需要多次重复设置foo的返回值以及输出函数的值,就像这样:
 
void tc_test_bar_return_ok(lcut_tc_t *tc, void *data) {
    LCUT_RETV_RETURN(foo, 0);
    LCUT_RETV_RETURN(foo, 0);
    LCUT_RETV_RETURN(foo, 0);
 
    LCUT_ARG_RETURN(foo, 1);
    LCUT_ARG_RETURN(foo, 1);
    LCUT_ARG_RETURN(foo, 1);
 
    LCUT_INT_EQUAL(tc, 0, bar(…));
    …
}
 
我的同事希望lcut能提供一个接口:支持一次调用,设置多次mock obj的返回值或输出参数,使用这样的接口后,上述代码就可以简化为:
 
void tc_test_bar_return_ok(lcut_tc_t *tc, void *data) {
    LCUT_RETV_RETURN_COUNT(foo, 0, 3);
    LCUT_ARG_RETURN_COUNT(foo, 1, 3);
 
    LCUT_INT_EQUAL(tc, 0, bar(…));
}
 
这个需求提的非常好,看起来更像是一种语法糖(syntactic sugar),用于简化代码编写。于是乎下午我就为lcut增加了两个有用的宏:LCUT_RETV_RETURN_COUNT和LCUT_ARG_RETURN_COUNT。
 
正如上面所说,这两个宏可在一次调用中多次设置某个mock obj的返回值和输出参数值,两个宏的原型如下:
 
#define LCUT_RETV_RETURN_COUNT(fcname, value, count) do { \
        lcut_mock_obj_return(#fcname, (void*)value, __FUNCTION__, __LINE__, __FILE__, MOCK_RETV, count); \
    } while(0);
 
#define LCUT_ARG_RETURN_COUNT(fcname, value, count) do { \
        lcut_mock_obj_return(#fcname, (void*)value, __FUNCTION__, __LINE__, __FILE__, MOCK_ARG, count); \
    } while(0);
 
只是比之前提供的LCUT_RETV_RETURN和LCUT_ARG_RETURN多了一个宏参数count。count用于指出对mocked obj进行多少次返回值或输出参数的设置。
 
另外当count传入-1时,其语义为无论mocked object被使用多少次,其返回值或输出参数值都是一样的,即使用LCUT_RETV_RETURN_COUNT或LCUT_ARG_RETURN_COUNT时设置的那个值,直到下一次调用这两个宏进行重新设置时,值才会发生变化。例如上面的例子我们也可以改写为:
 
void tc_test_bar_return_ok(lcut_tc_t *tc, void *data) {
    LCUT_RETV_RETURN_COUNT(foo, 0, -1);
    LCUT_ARG_RETURN_COUNT(foo, 1, -1);
 
    LCUT_INT_EQUAL(tc, 0, bar(…));
}
 
这样无论后续再调用多少次bar函数,foo的返回值总是0,输出参数也总是1。
 
增加了这两个宏后,lcut的版本号也小升了一位,最新版本是lcut-0.3.0-rc1,其中还增加了一个针对lcut mock功能的example – mock_test.c。同时Google Code上的lcut guide也做了更新,对新增的宏的用法进行了简要说明。
 
就这样,lcut 0.3.0版本算是发布了,后续还会经过内部的细致测试,如果没有什么问题,就会去掉rc。

如何加入Linux内核开发社区(7)

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本),原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第七章、第八章以及第九章节的中译文。

 
7、高级主题
 
但愿此时此刻,你已经理解了内核开发过程是如何进行的。但仍然还有很多东西要学习!这一节将涵盖几个主题,这些主题对于那些致力于成为Linux 内核开发过程中固定一员的开发者来说是很有帮助的。
 
7.1、使用Git管理补丁
 
早在2002年,内核就开始使用分布式版本管理工具了,当时Linus首先使用的是一款名为BitKeeper的专有(proprietary) 应用。虽然BitKeeper是有争议的,但它所代表的软件版本管理方法几乎是没有任何争议的。分布式版本控制使得内核开发项目的开发效率获得了加速地提升。如今,有很多种可以替代BitKeeper的工具。不管结果如何,内核项目已经决定了将git作为其版本管理工具的选择。
 
使用git管理补丁可以使开发者的工作更加轻松,特别是当补丁的数量越来越多的情况下。Git也有其不完善的地方并且可能产生某种危险;它是一个年轻而强大的工具,目前其开发者仍然在对其进行改进。本文不会尝试教授读者们如何使用git;其自带的长文档提供了足够的资料。相反,这里着重关注git是如何融入到内核开发过程中去的。那些期望快速学会使用git的开发者可以在下面网址中找到更多信息:
 
http://git-scm.com/
 
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
 
并且可以在互联网上找到各种不同的教程。
 
第一件事就是阅读上述站点所提供的内容,在尝试使用git制作补丁之前充分理解git的工作原理。一个使用git的开发者应该能够从内核主线库获得代码拷贝、查看修改历史记录、向代码树提交改变以及使用分支等。对git重写历史的工具(例如rebase)的理解也是很有用的。Git尤其自己的术语与概念;一个git的新用户应该知道引用(refs)、远程分支(remote branches)、暂存区(index,译注:现在更多称之为stage)、快进合并(fast-forward merge)、推(push)和拉(pull)以及detached heads等。一开始这些可能会让人感到有些望而生畏,但通过一点点学习这些概念掌握起来也不是那么难。
 
使用git生成通过email提交的补丁是一种用来加快git学习速度的非常好的练习。
 
如果你准备创建一个供其他人查看的git源码树,你自然会需要一个服务器,其他人可以从该服务器上拉(pull)代码。如果你拥有一个可以访问互联网的系统,使用git-daemon搭建这个服务器将会相对简单一些。否则,一些出现在互联网上的免费的公共托管站点(例如,Github)可供使用。已被社区认可的开发者可以从kernel.org获得一个帐户,但这些可是来之不易的;更多内容请参见http://kernel.org/faq/ 。
 
正常的git工作流程涉及到许多分支使用。每行代码都可能被分离到一个独立的"主题分支"中并且独立维护。在Git中使用分支的代价非常小,我们没有理由不自由使用它们。并且,无论如何你都不应该在一个你想要其他人从中拉取(pull)代码的分支上进行开发。对公众开放的分支应该谨慎创建;只有当开发分支上的代码完成并具备发布条件时再将代码合并到补丁中,不要在完成之前就合并。
 
Git提供了一些功能强大的工具,它们可以让你重写开发历史。一个令人为难的补丁(可能是破坏了bisection的补丁,又或是有其他明显bug的补丁)可能在适当地方被修复或整体从开发历史中消失。一个补丁序列可以被重写,重写后就好似今天主线上最新的修改似的,即便你已经在这个补丁序列上工作几个月了。改变可以透明地从一个分支转移到另一个分支,等等。明智地的使用git所提供的能力对代码库历史进行修订可以有助于创建出问题更少的整洁的补丁集合。
 
然而,除了着迷于创建一个完美的项目历史之外,过度地使用git提供的能力可能会导致其他问题。重写历史将重写历史所对应的改变,将一个测试过(希望是)的内核树转化为一个未测试过的内核。但是,除此之外,如果没有有关项目历史的共享视图,开发者间的合作将不会那么容易;如果你重写了一段代码历史,并且其他开发者已经将这段代码拉入其个人代码库,你会让这些开发者的工作变得更为困难。因此,这里可以应用一条简单的经验法则:已经被导出到其他库中的历史记录此后一般应被视作不可改变的。
 
这样,一旦你向你的公共代码库服务器推送了一组变更,这些变更就不应该被重写了。如果你尝试推送无法进行快进合并(例如,那些没有共享同一变更历史的改变)的变更,Git会试图强制执行这条规则。对这种检查进行重写是可能的,并且有时重写一个导出源码树可能是必须的。在linux-next中通过在树间移动变更集(changesets)来避免冲突就是一个例子。不过这种行为应该是不常发生的。这也是开发工作要在私有分支上(必要时可以进行历史重写)完成并只是在其处于开发后期时才移到公共分支的原因之一。
 
随着主线版本(或即将到来的其他基于一组变更的源码树)的推进,人们总愿意合并那些树以保持走在开发的最前沿。对于一个私有分支来说,换基(rebasing)可以作为一种跟上另外一棵源码树开发进度的简单方法,但一旦源码树已经对外发布,换基这种方法就不再适合。一旦如此,就必须进行全量合并(full merge)。偶尔的合并很有意义,但过于频繁的合并可能会导致修订历史不必要得混乱。针对这种情况的建议是不要频繁地合并,通常只在特定发布点(例如,一个主线的-rc版本发布时)进行合并操作。如果你对特定的变更感到紧张不安,那么你可以一直在私有分支上进行测试合并。git的"rerere"工具在这种情况下十分有用;它会记住合并时的冲突是如何被解决的,这样你就无需再做一遍这个工作了。
 
关于类似git这样的工具的一个最大的抱怨是:补丁从一棵树到另一棵树的大量的迁移使得许多欠考虑的变更很容易通过评审雷达的盲区而进入内核主线。当内核开发者看到这种事情发生时都会十分不满;搭建一棵包含了未评审或离题补丁的源码树很可能会对以后你的源码树被内核主线合并的资格产生影响。这里引述Linus的一段话:
 
   你可以给我发送补丁,不过对我来说是从你那里拉出一个git补丁。我需要知道你十分清楚你自己正在做什么,并且我需要有能力在无需手工逐个检查每个变更的情况下信任你所做的这些工作。(http://lwn.net/Articles/224135/).
 
为了避免这类情况,请确保一个特定分支里面的所有补丁都紧扣相关主题;一个"驱动程序修复"分支不应该对核心内存管理代码进行修改。并且,更为重要的是,不要使用git树绕过评审过程。不时地将源码树的概要发到相关的邮件列表中,并且当时机合适时,请求将你的源码树中的变更包含到linux-next中。
 
如果当其他人开始向你的源码树发送补丁时,不要忘记评审这些补丁代码。同时,也要保证你维护着正确的作者身份信息;在这方面git的"am"工具做得最好,不过对于那些通过第三方转发给你的补丁,你需要为补丁增加一个"From:"行。
 
当提出"拉出"请求时,请确保提供了所有相关信息:你的源码树的位置,从哪个分支拉出,以及此次拉出将导致哪些改变。在这方面,git的"request-pull"命令很有帮助;这个命令会将请求按照其他开发者所期望的那样进行格式化,并且还会执行检查以确保你记得已经将那些改变提交到公共代码树服务器上了。
 
7.2、评审补丁
 
很多读者肯定会反对将本章标题命名为"高级主题",因为即便是刚入门的内核开发者也应当评审补丁。的确,没有比审查其他人发布的代码更好的方式去学习在内核环境下如何编程了。此外,评审者永远供不应求;通过审查代码,你可以对整个开发过程作出重要的贡献。
 
评审代码可能是一件令人胆怯的事情,特别是对于内核开发新手们,他们对于那些经验丰富的开发者所公开提出的代码质疑很可能会感到紧张不安。不过,即使是经验最为丰富的开发者所编写到的代码也可能有改进的余地。也许对评审者(所有评审者)最好的建议是:用询问而不是批评来表达评审意见。问"在这条路径上这个锁是如何被释放的?"总是会比"这里的锁用错了"收到更好的效果。
 
不同的开发者会从不同的角度去评审代码。一些人主要关注代码风格以及是否代码行伴有结尾空白。其他人会主要关注这个补丁所实现的改变对与内核整体来说是好事还是坏事。然而,还有其他一些人将检查有问题的锁、过度使用栈、潜在的安全问题、在其他地方发现重复代码、是否有充足的文档、对内核性能的不利影响、用户空间ABI变化等。如果能够促使更好的代码进入内核,那么所有类型的评审都是受欢迎的并且是值得花时间做的。
 
8、更多信息
 
Linux内核开发以及相关主题的信息来源有很多。这里面首当其冲的应该是可以在发布的内核源码包中找到的Documentation目录。顶层的HOWTO文件是一个重要的起点;SubmittingPatches和SubmittingDrivers同样是所有内核开发者都应该阅读的重要文档。许多内核内部API都使用kerneldoc机制进行了文档化;"make htmldocs"或"make pdfdocs"可用于生成HTML或PDF格式(但很多Linux发行版中包含的TeX版本运行时遇到内部限制,因此也无法正确地处理这里的文档)的内核文档。
 
各种讨论内核开发细节的网络站点。作者这里将http://lwn.net作为一个内核开发信息来源推荐给大家;许多关于特定内核主题的信息都可以通过LWN内核索引找到:
 
http://lwn.net/Kernel/Index/
 
除此之外,一个对内核开发者有价值的资源是:
 
http://kernelnewbies.org/
 
有关linux-next源码树的资料汇集在:
 
http://linux.f-seidel.de/linux-next/pmwiki/
 
当然,大家不应该忘记http://kernel.org,这里可是内核发布版本信息的最终位置。
 
下面是一些关于内核开发的书籍:
  * Linux Device Drivers(译注:其中译版为《Linux设备驱动程序》), 3rd Edition (Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman). 在线版本在http://lwn.net/Kernel/LDD3/。
 
  * Linux Kernel Development (Robert Love)(译注:其中译版为《Linux内核设计与实现》)。
 
  * Understanding the Linux Kernel (Danial Bovet and Marco Cesati)(译注:其中译版为《深入理解Linux内核》)。
 
但所有这些书籍都有一个共同的不足:在它们上架时往往有些过时,并且它们上架已经有一段时间了。不过,在这些书中我们仍然可以找到很多有价值的资料。
 
Git的文档可以在下面网址上找到:
 
http://www.kernel.org/pub/software/scm/git/docs/
 
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
 
9、结论
 
恭喜每一个读完这篇冗长文档的人。希望本文可以为你对Linux内核的开发过程以及如何加入此过程的理解提供有用的帮助。
 
最后,最重要的是参与。任何开源软件项目只不过是其所有贡献者所做事情的总和。Linux内核项目进展如此迅速,质量如此之好,都是因为有数量可观的开发者的帮助,他们的工作都是为了创建一个更好的内核。Linux内核就是一个由成千上万人为了一个共同的目标而一起奋斗而完成的一个最好的例子。
 
虽然内核项目总是能受益于一个更为庞大的开发者基础,但那里也总是有更多的工作要去做。但同样重要的是,在Linux生态系统中的其他大多数参与者也能从对内核的贡献中受益。让代码进入主线是更高代码质量、更低的维护和发行成本、对内核开发方向的更高层次的影响以及更多其他事情的关键。这是一个所有参与者共赢的局面。发动你的编辑器并加入我们吧;你会受到热烈欢迎。
 
(全文翻译结束)

如何加入Linux内核开发社区(6)

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本),原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第六章节的中译文。

6、将补丁工作进行到底

此时此刻,你已经遵循了这里到目前为止给出的所有指导原则,并且由于你自己的工程技能,你已经发布一系列完美的补丁。但即使是经验丰富的内核开发者也可能 会犯的一个最大的错误是断定他们的工作已经结束。事实上,发布补丁象征着你的工作已经过渡到了开发过程下一个阶段,很可能还有相当多的工作需要去完成。

很少有补丁可以好到在第一次发布后就没有改进余地了。内核开发过程深知这一事实,并且因此重点关注已发布代码的改进。内核开发社区期望作为补丁代码作者的 你能够与社区一起工作来保证你的代码可以达到内核的质量标准。如果未能很好地参与到这个过程中将很可能导致你的补丁无法进入到内核主线。

6.1、与评审者一起工作

任何一个有意义的补丁都会引来一些评论,这些评论是其他开发者对你的补丁进行代码评审时得出的。对于许多开发者来说,与评审者一起工作可能是整个内核开发过程中最令人胆颤心惊的环节了。但如果你记住一些事情,你的工作可能会变得轻松许多:

  * 如果你对补丁进行了很好地解释,评审者就会理解它的价值以及为何你在创建补丁时遇到了困难。但这些都无法阻止评审者提出一个基础问题:五年或十年后,维护 一个合并了这份代码的内核将会是一个什么样子?你可能被要求进行许多改变–从代码风格改进到大量的代码重写–这些改变都基于这样的一种共识:从现在起 的十年间,Linux将仍然活着并依旧在开发中。

  * 代码评审是一个困难的工作,并且是一个相对费力不讨好的工作;人们会记住谁编写了内核代码,但那些评审代码的人却很少有持久的名声。因此,评审可能会变得 脾气暴躁,特别是当他们看到同一个错误被一再地犯的时候。如果你收到一个看似生气、出言不逊或完全无礼的评审意见,那么要抑制住你本能地回复的冲动。代码 评审只是针对代码,而不是针对人,并且代码评审者从其个人角度来说并非是要攻击你。

  * 同样,代码评审者不会为了推广他们雇主的方案而故意中伤你的方案。内核开发者常常期望能从现在起在内核上工作很多年,但他们深知他们的雇主可能会变化。他们工作的真实目的毫无疑问是为了创造一个他们所能创造的最好的内核;他们不会设法给雇主的竞争对手制造不适。

所有这一切归结起来就是,当评审者发送评论给你时,你需要关注这些技术意见。不要让他们的表达方式或你的傲慢阻碍这个过程的发生。当你收到针对你的补丁的 评审意见时,花些时间去理解评审者所表达的意思。如果可能的话,修正那些评审者请求你修正的问题。并且回应评审者:对他们的评审表示感谢,并且说明你将如 何回答他们的问题。

请注意,你无需同意每个评审者建议的改变。如果你认为评审者误解了你的代码,那么解释你的代码的真实意图给评审者。如果你对某个建议的改变存在技术上的异 议的话,解释你的异议并证明你的问题解决方案。如果你的解释有道理,评审者会接受它们的。但如果你的解释被证明没有说服力,特别是如果其他开发者开始认同 那个评审者的意见时,花些时间重新考虑一下吧。你很容易被你自己的问题解决方案所蒙蔽,甚至你可能没有意识到一些事情从根本上就是错误的,或者也许你根本 没有解决那个问题。

一个致命的错误是忽略那些评审意见并期望他们能消失。他们不会消失。如果你重新发布的代码没有处理之前收到的评审意见,你很可能会发现你的补丁将无处可去。

谈到重新发布代码:请记住评审者是不会记住你上一轮发布的代码的所有细节的。因此一个好的方法是提醒评审者之前提出的问题以及你是如何处理这些问题的;补 丁的变更日志(changelog)是一个用来记录这类信息的很好的地方。评审者不应该非得通过搜索邮件列表的归档才能重新了解到他们上一次所提出的意 见;如果你一开始就帮助他们重新了解上次的问题,那么在他们重新评审你的代码时将会有一个更为好的心情。   

如果你已经努力尝试做对每件事,但事情依旧无法进行下去怎么办?大多数技术上的异议都可以通过交流讨论解决,但有时候,有人不得不作出决定。如果你的确认 为这个决定不应该由你来作出,那么你总是可以尝试向更高一级的开发者寻求帮助。对于本文来说,更高一级的人可能是Andrew Morton。Andrew在内核开发社区十分受尊敬;他常常可以将那些看上去堵塞地毫无希望的情况疏通开来。要记住,他当然也可能不同意你的看法。

6.2、接下来会发生什么

如果一个补丁加入到内核被认为是件好事,且一旦大多数评审意见都已经被解决掉了,接下来的一步通常是进入一个子系统维护者的源码树中。加入的方式因不同子 系统而异;每个维护者都有其自己的工作方式。尤其是,可能有不止一个源码树–可能一个专用于为下一个合并窗口的准备的补丁,另一个用与更长期的工作。

对于那些没有适用的子系统源码树(例如内存管理补丁)的补丁来说,默认的源码树常常最终是-mm树。那些对多个子系统有影响的补丁也可能最终提交到-mm树中。

合入子系统源码树后的补丁将会拥有一个更高级别的可见性。现在工作在那颗源码树上的其他开发者将会默认得到这个补丁。子系统树通常也为-mm和 linux-next两个源码树提供补丁,这将使补丁的内容对整个开发社区可见。此时,你很有很可能从一批新的评审者那里获得更多的评审问题;你需要答复 这些问题,就像之前的那轮一样。

此时还有可能发生的是与其他开发者所完成的工作的冲突,这取决于你的补丁的性质。最坏的情况下,严重的冲突可能导致一些工作被放在次要的位置,而剩下的补 丁可能最终成型并被合并到内核中。其他时间,冲突解决将涉及到与其他开发者一起工作并且可能涉及在源码树间移动补丁以保证所有事情都能按规则地应用。这种 工作很可能是一种痛苦,但你应该知足了:在linux-next树出现之前,这些冲突往往只是在合并窗口打开期间出现,你必须尽快处理掉这些冲突。而现 在,在合并窗口打开之前开发者可以从容不迫地解决这些冲突。

某天,如果一切顺利,你登录主机并且会看到你的补丁已经被合并到内核主线了。恭喜恭喜!但是,一旦庆祝结束(并且你已经将你自己加入到MAINTAINERS文件),记住一个重要的事实是值得的,那就是:工作依旧没有结束。合并到内核主线将带来其自己的挑战。

首先,你的补丁的可见性已经再一次增加了。你可能会收到新的一轮评审意见,这些意见来自于那些之前不曾知道你的补丁的开发者们。你很可能忽略这些意见,因 为已经没有关于代码合并的问题了。但抵制住这种诱惑;对于那些提出问题或建议的开发者来说,你仍然需要保持处于积极相应的状态。

但更为重要的是:合并到内核主线后你的代码将被更多的测试人员获得。即使你贡献的是一个尚不可用的硬件的驱动程序,你会惊讶于有这么多人将你的代码构建到他们的内核当中。并且当然,哪里有测试人员,哪里就会有bug报告产生。

最坏的bug报告类型是regression。如果你的补丁导致了一个regression,你就会发现有许多双令人不舒服的眼睛在注视着 你;regression需要被尽早修复。如果你不情愿或没有能力修复这个regression(并且没有人为你做这件事),那么在内核稳定期,你的补丁 几乎可以肯定会被移除。因无法修复regression而导致补丁被从内核拉出(pull),除了否定了之前你为补丁进入主线而做的所有工作之外,还很可 能大大增加你的后续工作被合并的难度。

在处理完若干regressions之后,可能还有另外一些普通bug需要处理。内核稳定期是修正这些bug以及确保你首次出现在某内核主线版本的代码尽 可能的稳定可靠的最好时机。因此,请回答bug报告,并尽可能地修正问题。内核稳定期就是为此而设立的;一旦旧补丁中所有问题都被处理完毕,你就能够开始 创建一些绝妙的新补丁了。

不要忘了其他里程碑也可能创建bug报告:下一个主线稳定版发布、当一些重要的发行版生产商得到了包含你的补丁的内核版本等等。继续响应这些报告事关你在 工作中的自豪感。然而,如果感到动力不足,这点也是值得考虑一下的:开发社区会记住那些在合并代码后对他们自己的代码失去兴趣的开发者。下次你再发布一个 补丁,他们会在你过后不会继续维护它的假定下对该补丁进行评估。

6.3、其他可能发生的事情

有一天,你会打开你的邮件客户端程序并看到某人给你邮寄了一份针对你的代码的补丁。归根结底,这是将你的代码公开发布的好处之一。如果你认同这个补丁,你 可以将它转发给子系统维护者(确认包含一个恰当的From:行以保证其归属是正确的,并且增加一个你自己的signoff),或以一个Acked-by: 回应并让原始发布者发送给上面的维护者。

如果你不认同这个补丁,那么发送一个礼貌的回应并解释你不认同的原因。如果可能的话,告诉作者需要做哪些改动你才会接受该补丁。对于那些被代码作者和维护 者抵制的补丁来说,合并是有一定阻力的,不过也就仅此而已。如果你对某杰出的工作的阻止被认为是没有必要的,那么那些补丁最终还是会绕过你并进入主线。在 Linux内核中,没有人拥有代码的绝对否决权,也许除了Linus。

在极少的情况下,你可能会看到完全不同的情况:另外一个开发者针对你的问题发布了一个不同的解决方法。那一刻,两个补丁中的一个将无法被合并,并且"我的 是第一个"不被认为是一个令人信服的技术参数。如果某个其他人的补丁代替了你的并进入到了主线,那真的只有一种回应的方式了:为你的问题被解决掉而高兴并 继续你的工作。将某人的工作以这种方式丢在一边可能是伤人感情和令人泄气的,但是在忘记了谁的补丁被真正合并了之后,开发社区会记住你的回应。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多