往GNU邮件组发邮件要用纯文本格式

昨天遇到gcc使用方面的一个问题,就往gcc-help(gcc-help@gcc.gnu.org)邮件组发了一封求助邮件。但是浏览归档(https://gcc.gnu.org/ml/gcc-help/)找不到我发的邮件,应该是没有发送成功。

今天在hellogcc的IRC里请教了一下,才知道应该用纯文本格式发送。我用的是QQ邮箱,没找到如何设置纯文本发送(后经好心网友发邮件提醒:在邮件编辑区之下的“其他选项”中勾选“纯文本”,就可以了)。于是就改用gmail的邮箱发送,果然一下就成功了。以后记住往GNU组织(包括gcc,gdb等所有的邮件组)发邮件一定要用纯文本格式。

P.S. 关于gmail如何使用纯文本发送邮件,可以参考这个链接:https://support.google.com/mail/answer/2645922?hl=zh-Hans

GNU hacker的一些照片

前几天看lldb的 mail list,看见一个Jason Molenda的人的回复。觉得这个名字好像在哪里见过,于是就翻了翻GDB的changelog,发现他在很多年前,给GDB工作过。最开始在cygnus,后来去了apple。无意中在google中搜索了一下,发现了他的一个网站,里边有很多照片。好多照片都是他们这些gnu hacker在一起的,勾起了我无限的兴趣 (我特别喜欢把mail list里边的人和他们的照片对应起来)。下边我来一一介绍,由近及远,

第一个是关于 Richard Henderson http://molenda.us/photos/rth-ildan-test-2005-12-10/ 照片是关于他练习跆拳道的照片吧。Richard 在我心目中是十分牛了,比现在的GCC Global Maintainer要厉害,他现在好像在做qemu。12年在布拉格,我见过他。很cool的一个人。

第二个是 关于Jason Merrill http://molenda.us/photos/wedding-2000-09-16/。 我就认识这个人,他应该是C++ 还是 libstdc++的maintainer。

第三个是 两次GDB picnic 的照片 (1999年和2000年)。http://molenda.us/photos/gdb-picnic-1999/http://molenda.us/photos/gdb-picnic-2000-08-15/ 里边能找到最早的GDB 开发者。大部分人都陆续离开了GDB,只有两个人仍然留着,Stan 和 Doug。看看大牛的样子,的确是很有意思的事情。

Statistics of GDB Commits

今天下午无意中想看看自己有了多少个commit,然后就用 git log 命令查看,发现速度不错。不知道怎么了,灵机一动,想想看看这些global maintainer有多少commit。就有了如下的pie chart。

我来解释一下这个图是怎么得到的。首先我

git log gdb/ | grep ^commit | wc -l 统计一共gdb有多少次commit。然后把每个global maintainer的名字输入到这样的命令
git log gdb/ –author=”NAME” | grep ^commit | wc -l

统计每个global maintainer的commit数量。然后把这些数据画出来,这个时候想起了google chart api,以前同事用过,觉得很fancy,我就自己copy了一个。

从这个图表里边,能看出很多有意思的事情,

    gdbadmin 有很多commit。这些commit大多来自 daily version bump up,其实没有任何实际意义的。
    来自other的部分占约1/4。这部分人可以认为是对gdb代码不是那么了解的人。
    commit最多的是Andrew Cagney。 此人很牛,以前是Redhat GDB的头,后来去做frysk,然后离开了RedHat。 他那个时候,GDB好像还没有现在的 SC 和 Global Maintainer 机制。就他一个,叫 Head Developer。所以,他的commit最多。
    commit 其次多的是 Mark K.,Daniel J.,Joel B. Michael S.。 Michael 已经去世了,Mark K. 很久很久没有commit了。 Daniel J. 貌似 08 年以后也没有什么commit了。 Joel B. 现在的 Release Manager,最近没有什么patch,最近的两个patch,我觉得也不怎么样。貌似是没有时间。
    现在活跃的global maintainer 都有 400到 800个commit,所以,这个能告诉我们什么呢? 就是我们把这句话反着读,就是,如果有了 400到 800个commit, 基本上就能当global maintainer。

给GDB换一个版本控制工具

最近Phil Muldoon在gdb maillist挖了一个大坑 “GIT and CVS”,我当时看了以后,觉得这样的话题每过一段时间就会有人提起,每次都因为各种各样的问题,就不了了之了。RedHat他们有自己的一个gdb git branch,叫archer,估计他们每次把git上的patch,commit到cvs上都很郁闷,那个thread里边,Jan (GDB global maintainer)说了,他把git上的12 patch commit到cvs,花了他一个半小时,结果还有两个文件忘记添加了。

我个人觉得git很好,要是能换到git,我也高兴。我现在就之用cvs commit,其他的都不用。谁知道,Eli (GDB global maintainer)说git不好用,而且git不是gnu的项目,她在用bzr,还说“如果我们使用git,这很可能让我gdb里边不活跃了”。后来,楼就歪了,成了比较git和bzr了。里边讨论了很多git bzr很有意思的用法。

git和bzr我都用,感觉bzr就是比git慢一点,其他好像没有什么区别。bzr和launchpad集成很好,不过这些gnu都用不上。

大名鼎鼎的Mark K. (GDB global maintainer)会回复了一次,老外果然说话很直接,也是他的风格 “I am a git hater.”  还列出了他的workflow,他那个workflow是最基本的workflow,就是 update/modify/commit。这样的workflow根本不适合,多个patch的改动,而且在网速慢的地方,就更不合适了。

后来,讨论就没有什么实质进展了,因为没有任何的行动。我觉得这个话题就这样结束了,结果,无意中,在昨天晚上的irc上,看到一些更有意思的讨论。贴在这里:

<tromey> nobody wants to do the work, just argue about DVCs
<brobecke> It's OK, though. I think there are disadvantages that are immediately visible as soon as you review a diff, but it's not important enough that I want to pick a fight.
<brobecke> yeah, me too, sometimes.
<tromey> ok
<tromey> it is mostly stop-energy too
<brobecke> case in point, the latest discussion about git and bzr...
<tromey> sometimes I wonder why we put up with it
* brobecke sighs....
<tromey> I still haven't read the latest git thread
* antgreen (~user@c74-230.rim.net) has joined #gdb
<tromey> I didn't want the aggravation
<brobecke> nothing much there, I wouldn't bother.
<brobecke> there were two threads, really:
<brobecke> (1): what are the problems that need fixing for us to switch to a different VCS
<brobecke> (2): what is the best DVCS?
<brobecke> (1) was a useful reminder, but (2) was a waste of time
<SamB> shouldn't there be a "for us" in #2?
<brobecke> SamB: Yes, actually there was (a bit)
<SamB> of course, there's the fact that you are *already using* git...
<brobecke> someone even suggested that people who do the most commits should be the ones deciding 🙂
<dmalcolm> in case it's useful: http://www.python.org/dev/peps/pep-0374/
<SamB> brobecke: as someone who has made few or no commits, I am very much in favour of that plan!

这里没有什么好说的,就是他们开始讨论这个话题。第一句是亮点。介绍一下人物吧, brobecke, GDB global maintainer, Release Manager. tromey, GDB global maintainer。好,接着看他么还说什么了。

<tromey> yeah; but gdb, being a GNU project, has a uniquely bad political atmosphere
<SamB> indeed
<tromey> it is something I contemplate quite frequently these days
<tromey> other fields seem fairer
<SamB> you guys do *very* well, considering
<tromey> several GNU projects make progress according to the rule of "don't tell RMS"
<tromey> this works, but really it ought to be beneath us
<brobecke> If it was just about GDB, I think it would be doable to reach a consensus and just go ahead and do it. But we are intermingled with other projects, and it's costing us big time right now.
<SamB> RMS ought to be saner

不知道这里怎么就开始谴责 GNU和RMS了。

<brobecke> SamB: the problem is that GDB is part of a larger "project" called src.
<brobecke> when you checkout gdb, you actually checkout parts of src.
<SamB> the stupidest name ever
<SamB> but, yeah, I'm vaguely aware of the CVS repository arrangements
<tromey> binutils guys ought to be on board, since one or two threads ago was on the  binutils list
<tromey> this comes up like every 8 months 🙂
* brobecke is setting an alarm, then 🙂
<tromey> anyway all the commit scripts need to be converted
<tromey> and everything tested
<tromey> and all src communities notified or whatever
<tromey> Joseph posted a bullet list in one of the threads, which was, as usual for him, extremely comprehensive
<tromey> definitive one might say
<brobecke> there are also the "nightly" scripts that create the tarballs, which could use a good rewrite anyway

brobecke解释了为啥把gdb从cvs转换到别的vcs那么困难,说的挺有道理的。

<SamB> I still don't understand how bzr even qualifies as a GNU project
<tromey> me neither
<SamB> it doesn't seem to have any of the disadvantages usually associated with that status
<brobecke> why not? (just curious, I never looked at it before)
* brobecke is reading the PEP document dmalcolm pasted
<SamB> they'll take my commits without papers, for example
<andre> would a completely separate repo like archer and nightly sync to cvs be an option?
<SamB> It mainly seems to be used to annoy those working on *actual* GNU projects by suggesting that they should use bzr
<tromey> I thought bzr required copyright assignment to Canonical
<SamB> for purely political reasons
<SamB> tromey: maybe they do!
<tromey> that for me is a critical flaw
<tromey> I can't imagine what RMS was thinking
<brobecke> so, to be part of the GNU project, all it takes is RMS accepting it?
<SamB> anyway, as someone who actually *likes* bzr, I'm glad it is not a *real* GNU project
<tromey> yes, RMS just has to bless it; but one of the good things about RMS is that he is unusually consistent and principled, so you can be assured it has to be free software at least
<tromey> anyway the bzr decision is one of the things that has really soured me on GNU

这里就有一些有意思的事情了。我以前知道bzr是gnu dVCS,但是不知道参与bzr需要给Canonical 签 copyright assignment。这个是一个很奇怪的事情。community的工作,给一个公司签 assignment,的确很奇怪。

<brobecke> did he have any alternative, though?
<brobecke> how does git compare in terms of GNU-dness, do you think?
<tromey> this is the thing for me
<tromey> why does GNU need to bless *any* DVC?
<tromey> choosing bzr does not notably advance the cause of software freedom
<tromey> there are already many free DVCs
<tromey> free by every measure that matters to the FSF
<brobecke> ah, I see.
* dmalcolm mutters incoherent something about "free-as-in-requiring-copyright-assignment-to-a-for-profit-company"
<tromey> what also matters to me is (1) the random authoritarianism of RMS -- it isn't like this was some kind of process like the one Python went to -- and (2) bzr sucks IME; I think GNU should stand for *both* software freedom and technical excellence
<tromey> yes, requiring assignment to a company is amazingly bad, especially considering the crap Shuttleworth says about this sort of thing
<tromey> it has been extremely upsetting to me
<tromey> 🙁
<brobecke> wow, sorry that it's affected you so much. FWIW, I agree that it should strive for excellence as well.
<SamB> dmalcolm: hey, it's trivial to fork if at some point they do something evil...
<dmalcolm> one other point about that PEP document: yes, Python does have a "benevolent dictator for life", but the point of the PEP system is to encourage gathering the expert opinion to bear on a subject, so that a decision can be transparently made, and the BDFL is effectively just rubber-stamping it.  It turns the debate from a mailing list thread-of-doom into a deliverable/artefact
<dmalcolm> (sorry to weigh in; waiting on an upgrade here)
<tromey> I would be ok with it if GNU worked this way
<tromey> but RMS is not that open
<tromey> I suppose even if GNU were like this, it would still be dominated by the Eli Zs and Tom Lords of the world and I would still end up looking for something else
<tromey> Apache is perhaps a better model
<tromey> or Fedora or Debian
<pmuldoon> brobecke, did I suggest that? I can't remember what I said ;)
<brobecke> someone did, not sure who it was.
<pmuldoon> I think I said my experience was not unique in that the only time I use CVS is when I check-in
<pmuldoon> I am sorry about the thread, if it caused problems.  But I feel speaking up is the right thing to do, occasionally, even if it causes headaches ;)
<pmuldoon> brobecke, and I still think there should some bias to the release maintainer, because that maintainer deals with it
<brobecke> pmuldoon: thanks! :-). The releases take 2-3h max twice a year, so the bias should go to heavy contributors.

最后,这样一个讨论也没有什么结论。但是,看上去,换一个vcs,还不是那么简单的事情。我还是不明白,GNU为啥选择bzr,我倒不是说bzr不好,就是觉得那样一中copy right assignment的形式,让别的公司很难接受的。我想这个决定应该RMS做的,不知道他老人家怎么想的。

读 “GNU Toolchain for Embedded Development: Build or Buy?“ 有感

这个题目是在有点老套了,让我想起了初中时代,写作文的题目。今天无意中看到了这样一个white paper,Mark Mitchell写的。看了一遍,还是有些思维的跳跃,跟大家分享一下。原文 “GNU Toolchain : Build or Buy?” 需要注册下载。

我在这里也不评论到底是应该build还是应该buy,这个结论也不是我这个文章的重点。我就是想看看从这篇文章里边,我们能知道一些GNU toolchain开发的状况。

这篇文章14页,不长。跳过前边,直接从第四页开始,介绍了Building The Toolchain,这个是一个复杂的过程。自己build 过 toolchain的人都应该有这样的感觉,

    需要了解每个toolchain component的版本。有些版本的某个component可能有bug,或者某两个component在某个两个版本上,不能一起使用,等等。这些问题需要在一开始就知道。
    应用哪些patch?toolchain component可能有问题,所以在某个版本后,才会有相应的patch fix,那么那些patch应该用,用了以后会不会带来新的问题,等等,这些问题也要考虑。
    configure的选项。虽然几乎所有的gnu toolchain component都是遵循 configure make make install的过程,但是每个都有十分复杂的configure 选项。

上边这些无非是告诉我们,build toolchain就是一个十分复杂的事情。但是我们可以看出,这些东西从侧面告诉我们,这些就是一个依靠GNU toolchain生存的公司或者部门的必须知道或者精通的知识和技能。之前和朋友聊过,说,我们什么时候也能开一个toolchain 的公司,我们当时开玩笑说,等有了global maintainer再说吧。其实上边这些就是开toolchain公司的一些必要条件。

文章接下来讲了toolchain validation。里边很多都是介绍GNU toolchain怎么测试的,我这里就跳过了。有意思的部分是“分析和修正test failure”。对于toolchain这样的严格系统软件,很多时候,是一种 “bug-fix-driven development”,每一个release至少要保证没有严重的错误,然后再保证一些性能的提高或者新的特性。所以,在toolchain这个行当里边,“修bug”比别的行当重要的多。在我之前的工作中,修bug好像是一个很没有技术含量的事情,可能因为那些bug也没有什么技术含量。GNU toolchain的工作,很大部分是在修bug,而且我现在认为,修bug是进步最快的一种方式。

好,回到toolchain validation,在测试中发现了fail,就需要fix。文章中给出了一个最“乐观”的方式,定位出问题的component,理解代码,发问题到list,自己修正,把patch发送到list。但是,实际上,这样的方式对大多数人,行不通的。就“理解代码”这样个事情,就很复杂,toolchain的代码量那么大,而且之间还有一些交互,理解代码是很难的事情。 总之,能够自如的使用那个最“乐观”的方式,是自如的加入GNU toolchain开发的一个必要条件吧。

希望这样一个文章不会让我们这样在toolchain行当里边挣扎的人感到绝望,相反,希望我们能看到一些曙光,希望和方向。我看到了,你呢? 🙂