谁负责修复漏洞？

开源项目中出现过几次这样的情况：

1. 我注意到我们的部署中存在一个错误，并找出了一个快速的补丁程序。（例如，仅注释掉我们实际上不需要的代码。）
2. 我花了一些额外的精力来找出真正的错误，提出一个补丁，然后通过Git pull请求或类似的方式提交它。
3. 我的拉取请求被拒绝。补丁可能是不完善的（例如，本来不应该包含的行），也许违反了编码风格，也许还有其他影响。也许我在Git中做错了-拉取请求应该已经重新设置了基础。维护人员提供有关如何改进补丁程序的反馈，并要求我重新提交它。

在这一点上，我对应该走多远感到困惑。就我而言，我没有问题：我已在步骤1中修复了该问题。我已经报告了该问题，甚至还采取了措施将其修复。但是我不认为这是“我的”请求请求，因此我不认为应该负责改善补丁。

让我烦恼的一种特殊情况是，在讨论了我的补丁程序的失败之后，我们在邮件列表中就正确的补丁程序达成了共识（即，它的行为方式，有时包括每行阐明的代码）。然后，我仍然有责任实际生成并提交补丁。

在这些情况下是否有标准礼节？他们如何解决？我的反应异常吗？您需要多长时间才能接受错误修复？

（请注意，当我说“开放源代码项目”时，其中一些很小，但可能不是业余爱好-只是几个组织使用的小型软件项目，这些组织将开发人员的资源投入到他们的工作中。是“修复补丁并重新提交”，请理解我对雇主有​​责任从事对他们有利的工作。花时间修复不影响我们的错误是错误的……）

就我而言，如果您发现一个错误或有一个增强请求，不是该项目的贡献者，并且已通过适当的渠道提交了缺陷报告，那么您就可以完成。在回馈社区方面，任何正在使用开源项目并发现缺陷的人都应报告该缺陷。

尝试找到解决方案，设计解决方案并实施它对项目来说是一个好处。如果您已完成此操作，则最好通过请求请求或将文件增量与缺陷报告或增强请求一起发送给开发团队以使其有所帮助的方式来提交它。但是，他们没有义务接受您对项目的贡献。

对我来说，期望用户贡献补丁是错误的。参加关于一个问题的讨论是相当容易的，但是要想出一个解决方案却要花费大量的时间。任何项目都不应期望非贡献者成为仅解决单个问题的贡献者。

继续进行，直到您愿意忍受为止。修复您的补丁并与主干之间的世界共享它是很好的，但是如果维护者不想要它，则耸耸肩。您可以在某个地方发布您的问题及其补丁以进行处理，以便同一船上的其他人可以搜索解决方案。

而且您也不是没有问题。您的补丁程序将不在下次升级中。因此，无论何时获取新版本，您都必须重新修补，并希望它能起作用或按摩到位。因此，从长远来看，进入主项目将为您和您的公司节省时间。

这对您来说很痛苦，但是您正在为社区做贡献。我当然感谢所有贡献者所做的工作。这不像优质软件只是神奇地起源于大众。必须有人来做。（那么谁很棒？你很棒）。如果您不满意，请向社区宣布，尽管您赞赏有关应如何处理的讨论，但您实在太忙了。我的意思是，他们打算怎么办？减薪？

有一个原则使开源文化更容易理解：工作的人决定要做什么。与开发人员的日常工作相比，这是它的吸引力之一。您的待办事项列表上的＃1优先级可能是＃50。如果您不解决您的拉取请求，最终它可能会trick到顶部，他们会照顾好它。但是，如果您对他们足够简单，那么他们现在会照顾好它。

他们要求您解决请求请求的另一个原因是宽宏大量。他们希望您因自己的贡献而获得荣誉，尽管金额可能很小。如果您进行修复，则您的姓名为提交的作者字段中的名字。大多数人为自己的贡献感到骄傲，希望能看到它，因此维护者的默认作法是让他们这样做。

就您对雇主的责任而言，如果您的企业依赖于此准则，则不会给他们带来损害。雇主知道工人花时间精磨工具的好处。

AFAIK的开放源代码方式是，修复漏洞的责任留给了足够关心漏洞的人来处理负担，以确保漏洞得到修复。根据情况的不同，我已经做了很多事情，从简单地忽略问题到进行斗争（提供补丁程序并进行争论，以使它们被接受）以确保已解决。

一切都很好，只是不要让管理项目的人期望您做错事（即，让他们希望您可以通过讨论选项正确解决问题，然后什么也不做），他们可能意识到的问题比他们多可以应付自己，并会尽力为您做出经常性的贡献。

原始错误可能只会影响您，因此通过采取使补丁程序符合要求的一切工作来吸引您的提交非常符合您的利益。否则，您拉出的下一个版本（因为需要其他修复程序）将丢失您的修复程序。

您不想保留每次拉出项目的新副本时都需要应用的补丁列表，这太麻烦了。花费一些额外的时间，将其永久修复，这样您就不必再次处理它。

对于开源开发人员而言，存在两种类型的问题：

• （a）没有补丁的问题
• （b）补丁引起的问题

我认为大多数开源软件包维护者/开发人员都喜欢帮助非核心贡献者加快补丁发布的想法。

但是，他们的主要目标是最大程度地减少b型问题的数量。这就是为什么标准设置得很高的原因。

有人克服了它。他们成为贡献者，甚至可能成为核心贡献者。其他人放弃。开源具有某种达尔文式的性质-优胜劣汰。

我鼓励您继续努力，将自己的贡献吐出来，让团队接受。完成一些贡献后，他们会进一步信任您，但是您仍应确保您的贡献无懈可击。

最终结果是完全值得的。就像可以说“我要编码吗？是的……您每天都在运行我写的东西”。