logo标签列表

如何让更多的人参与改进Ubuntu的X.org？

xorgpackagingcommunitygraphics
在Ubuntu中，X是堆栈中更为关键的部分之一。因此，我们收到了大量关于X的问题和错误报告，可能是我们能够处理的人力的100倍。
Canonical正在招聘额外的工程师来处理X，这将有所帮助，但仍然有许多事情超出了Canonical的能力范围，因此我认为让强大的社区参与改进Ubuntu中的X非常重要，特别是在回答、分类和（希望）解决所有这些大量的错误报告方面。
然而，很难找到愿意从事X工作或者说服那些没有考虑过从事X工作的人们投入时间。您如何建议鼓励那些可能没有考虑过从事X工作的人们参与其中？
3我建议将这个条目设为社区维基。 - Marco Ceppi
想要开始帮助别人的人可以在哪里找到容易入门的机会？ - txwikinger
至少你没有问如何让更多人参与XFree86 ;) - Stefan Lasiewski
1我们在http://wiki.ubuntu.com/X里有一堆文档，可以帮助那些想要在X上提供帮助的人。涵盖了基本的X问题，描述了一些X错误处理流程等等。由于这是一个维基百科，所以也欢迎大家添加内容进去。 - Bryce
5个回答
X之所以没有得到很多工作，是因为它需要对GPU、内存等的工作原理有巨大的了解，同时还要熟悉X.org代码库和在某种程度上了解内核编程。这不是一件简单的事情，从社区的角度来看，那些对X或X驱动感兴趣的人可能已经在做了。目前，除了个人兴趣外，开发者没有动力去开发Xorg。
社区拥有而X.org开发者可能没有的东西，就是对各种硬件的访问权限。有人愿意花时间撰写“好”的错误报告、测试驱动程序和Xorg堆栈的部分内容，在发布之前进行测试，这可能比任何其他事情都更有助于工程师们。
目前有一个我用来在我的稳定系统上测试驱动程序的Xorg edgers仓库。测试完成后，回滚单个软件包非常容易。然而，我们唯一能够进行测试的另一种方式是自己构建X，或者安装从上游构建的edgers仓库。据我所知，这将完全替换X。这意味着测试X只能采取全面或不采取的方法。
有一种方法可以同时拥有两个版本的X（并且相对容易地选择），这样测试人员不仅可以测试X，而且还可以回到一个正常工作的Xorg，以便提交错误报告。
3其实，我们需要的并不是更多的错误报告（我们已经有大量了），而是有人能够查看所有人发送给Ubuntu的报告，将好的与坏的进行区分，并在可能的情况下帮助用户。事实上，我们很容易找到很多人来进行测试；其中很多人不知道如何编写“好”的错误报告，但通过一些分类工作，它们可以得到改进（并转移到上游进一步处理）。 - Bryce
1也许我们应该为X服务器设立一个“拥抱虫子”的日子？ - txwikinger

作为一个对X感兴趣的开发者，我想谈谈我的问题：

  1. 我只能接触到少数几款显卡，而且我怀疑大多数人也只有一款。因此，对于绝大多数的错误，我无法做太多处理，因为它们总是出现在“其他的显卡”上。

  2. 与大多数软件包不同，我不能轻松地为新的驱动程序版本创建测试环境；虚拟机有自己的X驱动程序。

  3. 我不能轻松地更新到最新的驱动程序，进行测试，然后恢复到之前的版本。这样做会阻碍实验（因为如果出了问题，我可能就完全废了）；它还会妨碍回归测试。

  4. 上次我查看时，成功应用补丁、编译和运行X非常困难，会干扰软件包管理器，还需要对内核模块进行补丁，基本上是一个不可逆转的步骤。

  5. 现在，X驱动程序将其代码分散在内核、Mesa、udev（用于设置和默认值）和用户空间驱动程序之间。这意味着补丁也会被分割...

所以，我想答案是让应用和恢复更改成为软件包管理器处理的事情，并且在系统出现问题时容易恢复。

另外，应该考虑像DKMS这样的系统来处理X驱动程序；如果我可以轻松地修补/编译/测试/卸载，例如，触摸屏的输入驱动，而无需重新构建整个庞大的系统（带有完全无法使用X的威胁），那么你将会得到更多的非正式贡献，并激励我去解决与该硬件相关的错误和测试补丁。

我认为你说得对，这些都是潜在志愿者可能认为是他们无法参与X项目的原因。然而，有很多事情并不需要“打开引擎盖”，一个人可以做很多事情来提供帮助 - 整理错误报告，回答用户的问题，追踪好的补丁以便包含在Ubuntu中。这些事情并不真正面临这些特定的问题。 - Bryce
1我对X比内核更害怕。我可以轻松地启动一个旧的内核。 - maco
1我从不害怕 :o 你可以轻松地设置一个双启动环境，可以在其中测试内核补丁和不稳定的Xorg服务器。它甚至不需要那么大，因为你不需要大部分图形界面工具来进行简单操作，而在编译时，你可以处于正常环境中，并chroot到不稳定的系统中。 - LassePoulsen
嗯，就像任何事情一样，让人们更容易地了解它是很重要的。所以从我记得的bug triage开始时，并没有太多来自社区的帮助。然后当一些wiki页面解释了常规的bug处理流程和一些bug日活动吸引了更多社区成员参与进来。此外，如果你能为社区提供一个定期的活动并给那些尝试的人提供帮助，你会获得一些兴趣。
如果你需要这个活动方面的帮助，你可以给我发邮件，我会帮助组织。
所以我的建议是创建一个包含问题和指令的wiki页面，以获取良好的bug triage信息，并吸引更多人参与其中。
对于开发而言，这是一个大问题。Xorg和Kernel的修复bug和实现功能需要较低水平的编程技能。因此，你需要针对特定的程序员群体，并激发他们的兴趣。我在这方面没有什么建议，除了多问一些人并看看谁经常出现在#ubuntu-x频道，并询问他们是否能提供帮助。
未来是否有计划实施Wayland？那么让人们致力于此岂不更好？ - Ingo
补充jbowtie所说的，作为一个Bug处理者，我发现X个bug非常具有挑战性，因为X是一个非常复杂的问题。这在故障排除维基页面的复杂性中得到了体现。肯定会有帮助的是为BugSquad成员设立一种导师计划，以更好地学习如何处理X个bug。也许可以围绕它举办一个Bug拥抱日？或者在#ubuntu-classroom进行实践培训课程？
导师计划其实是一个非常好的主意。我们已经讨论过一些相关的想法，但到目前为止，挑战在于找到愿意尝试的人。 - Bryce
到目前为止，我已经为X做了两次繁忙的故障处理日。几乎没有人出现来进行问题分类，我们也没有从中获得任何新成员。 - Bryce

当许多用户使用替换部分图形堆栈的专有驱动程序，并期望X.org团队解决内核升级/ X.org升级导致其驱动程序安装失败时，改进X.org变得困难。

关于"我没有所有可用的卡"的讨论也是合理的。

如果你不是一个好的程序员，图形编程相当困难。调试可能会非常痛苦，特别是如果你看不到发生了什么。

从开发者的角度来看，我同意你对专有驱动程序的痛苦的看法。但在Ubuntu发行版层面上，我们主要关注的是驱动程序的“打包”，这是开源的，并且可以从社区参与中受益并得到改进。 - Bryce
拥有多种图形卡似乎很重要，但根据我的经验，它虽然有用但并非关键。我发现最有用的是拥有2台计算机——一台用于日常稳定使用，另一台则可用于破解、调试、ssh等操作。 - Bryce