(2008-11-24) 更好的 Fedora

(Callum Lerwick) 我下面要说的这些，大家过去或多或少都已听我和其他成员说过，但是我认为并非所有人都看到了全景。让我来把它们串起来。

问题：
Fedora 有很多不足，每次更新又常常带来副作用。

解决方案：
我们要做更多更广的测试。

问题：
我们要做更多更广的测试。为什么却没有？就我自己而言，我不去测试每个更新的原因，是如果出现副作用，恢复系统到正常可用的状态实在太难了，报告错误也太难了。如果我都没法应付，何况普通用户呢。

解决方案：
1) 报告错误必须更容易。Bugzilla 过于复杂，太慢，太过神秘。我们必须在其上构建一个简单的界面。报告错误应该只需要几次点击。报告的内容应该自动包含所需的信息，Fedora 版本，软件包版本，体系结构，日志和配置文件(就像 Xorg 团队会想要你的 Xorg.0.log 和 xorg.conf 文件)。查询重复的问题必须更容易。搜集系统范围的调用堆栈信息，存入数据库，让 bugzilla 可以引用它们。系统范围的 kerneloops (这个已经在做了吗？)

2) 恢复到“正常”的状态必须更容易。我们需要“系统还原”。我知道这让你们想起了什么，可是我们的 RPM 系统更高级，是中心化的，是系统范围的软件包管理程序，而且我们没有所谓的“系统注册表”，那么“系统还原”是完全可行的。我们需要以软件包为单位的“系统还原”。

3) yum 必须不再更新第二步中被回滚的软件包，直到第一步中被报告的问题得到修复。

4) 如果系统彻底不能用了，/boot 分区需要有一份应急的镜像。所有上述功能必须在应急的系统中可用。

5) 如何修复问题？必须可以容易地从 updates-testing 仓库甚至直接从 bodhi 安装更新。如果每次都盲目地测试 updates-testing 仓库的每个更新，这又有多少用处呢？大多数用户不会这样，而敢于冒险的人可能早就换用 rawhide 了。我们需要让用户更容易地试验某个版本的更新。在很多错误报告中经常要求用户试着安装某个版本的更新，用户需要做到点击错误报告中的一个链接，更新就装好了。必须很容易地找到更新和为什么需要更新的原因。不要忘记第二步。

懂了我的意思吗？

注意我仅仅在描述用户界面，最终用户的体验。具体的实现是围绕这些的，我将在另一封邮件中描述。技术设施提供了功能，而不是借口。我不想听到“我们不能这样做，因为这样那样的缘故，技术上很困难”。我不要听“太难”的话。工程师的天职是解决困难的问题，这是我们要做的。我想听到“要这样做，我们必须做 x y z”。我能听进去的唯一的反对意见，是“你这个笨蛋，你的想法太差了，我们有更好的办法”。

让我们在 wiki 上继续这个话题。

原文见 My roadmap for a better Fedora

So, many pieces of this have been blabbed about by me and others
recently and in the past, but I think a lot of people aren’t seeing the
big picture. I think it’s time I fit it all together.

Problem: Fedora is buggy, and updates are rife with regressions.

Solution: We need more and wider testing.

Problem: We need more and wider testing. Why don’t we get more testing?
Thw reason *I* don’t go out of my way to test updates, is if there’s a
regression, it’s such a pain in the ass to get the system back to a
known good state and keep it that way, and report a bug. If it’s a pain
in the ass for me, it’s impossible for Aunt Tillie.

Solution:

1) Make it easy to report bugs. Bugzilla is complex, slow, and
inscrutable. We need to put a simpler layer on top of it. Reporting a
bug should require just a few clicks. It should automatically include
all the information needed for the bug report, the distro version,
package version, arch, and things such as how the Xorg team demands your
xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
traces system wide and enter them in a database, which bugzilla can
reference and from which bugzilla bugs can be derived. A system wide
kerneloops. (I know this has been talked about, what’s the status?)

2) Make it simple to roll back to a known good state. We need a “system
restore”. I know what you’re thinking, but our vastly superior,
centralized, system-wide package management (and lack of a whole
seperate “system registry” namespace) allows us to make this actually
work. We need per-package rollback. Period.

3) Make it so yum will refuse to upgrade the package rolled back in step
2 until the bug reported in step 1 is fixed.

4) For when things go really wrong, we need a rescue image in /boot. All
the above functionality must be available inside the rescue environment.

5) So how do bugs get fixed? Make it easy to cherry pick updates from
updates-testing or even direct from bodhi. How useful is it to blindly
follow every update in updates testing? For most users, it’s useless.
Such adventurous people should probably just run rawhide… What we
really need is to make it easy to pick a specific release of an update
to try, such as if a user is directed to in a bug report. A user should
just be able to click on a link given in the bug report and have the
update installed. Available updates and the reasons for them needs to be
more discoverable. Don’t forget step #2.

See how these things build upon and support each other?

Notice here I’m talking purely about user interface, about the end user
experience. The technical infrastructure follows from this, and I’ll
save that discussion for another message. Infrastructure supports
functionality, not the other way around. I don’t want to hear any “Oh
but we can’t do this because blah blah technical objection blah makes
this hard”. I hereby dub this the “Hard problem fallacy”. Engineers
solve hard problems, that’s what we do. I want to hear “To do this we
need to do x y z”. The only objections I will accept are of the form
“You are an idiot and your ideas are stupid. We’re not doing this.”

I should probably put this on the Wiki so it doesn’t get lost…