最近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很有意思的用法。


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


<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


<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行当里边挣扎的人感到绝望,相反,希望我们能看到一些曙光,希望和方向。我看到了,你呢? 🙂



















开始加入gnu toolchain的开发(之二)

xmj@hellogcc 向GNU提交代码,必须要签署FSF版权转让协议(copyright assignment),这意味着你是作为贡献者将这些代码的版权归为FSF所有。这里只介绍了以个人的名义来申请签署协议和进行开发的流程,至于以公司的名义的流程,我不清楚,故没有介绍。申请签署该协议的方法为,填写如下表格,并发送给assign@gnu.org 。下边给出样例答案。 Please email the following information to assign@gnu.org , and we will send you the assignment form for your past and future changes. Please use your full legal name (in ASCII characters) as the subject line of the message. ———————————————————————- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name […]

开始加入gnu toolchain的开发

作者: qiyao@hellogcc

很多刚刚加入gnu toolchain开发的工程师,都会被各种各样的规定,缩写还有交流方式搞得晕头转向。本文就是为了让刚刚进入gnu toolchain的开发的工程师简单介绍一下在这个圈子里边工作的一些特别之处。

1 开发流程
checkout change diff submit approve commit

checkout就不用说了,绝大多数人都知道怎样check out代码。



1 敲击一下tab是两个空格,
2 如果前边有了八个空格,用一个tab替代,
3 一般源程序的宽度不要超过76或者78,
4 changelog的宽度不要超过72,


虽然是给gdb开发者看的,但是基本适合其他gnu toolchain项目。

建议安装whitespace.el,来显示空格和tab,还可以去掉一些trail space。还有在使用git生成patch的时候,使用git diff –check,可以帮助你检查patch。


发送patch,一般gnu toolchain都用单独的邮件列表来讨论patch的。所以,把你的patch按照附件的形式,用纯文本的方式,放送到列表。邮件的题目要简单明了,因为邮件列表的流量很大,而且每个maintainer可能只注意自己需要review的patch,所以标题要让他/她知道,这个是他/她需要review的。比如,有一个patch是对arm的修改,可以这样[patch/arm] XXXXX。多看看别人怎样写的。

还有的时候,邮件标题可以用 [rfc], [rfa]之类的。rfc的意思是request for commit,而rfa的意思是request for
approval/accept。我自己并不经常用这两个,我个人感觉他们的差别在于rfc是提交自己的一个代码或者patch,希望被接受;而rfa是提交的自己的想法或者建议。比如我想建议在gdb中做一个新的feature,program slicing,我可以把我的建议和设计这样发出去 [rfa] New feature in GDB : program slicing

[note: 我个人对rfc和rfa用的不多,所以解释不是很准确]


[patch 0] GDB new feature: program slicing,发送。然后依次恢复这封邮件,分别按照不同的题目,把自己的patch按照顺序发出去,比如
[patch 1] refactor existing GDB infrun to prepare for program slicing
[patch 2] support program slicing in target-independent part
[patch 3/x86] support program slicing on x86
[patch 4] test case and doc

这样的好处就是,负责doc和testcase的maintainer就需要看你的第三个patch就好了。负责x86 maintainer就看你的patch 2。而且以后给comments也比较容易。


commit的时候,加入changelog entry。在emacs里边,比较方便,M-x add-changelog-entry后,选择changlog文件,就会自动加入你的邮件地址和时期,完全符合gnu的规定。如果源代码不是很多,比如gdb,可以用emacs提供的前端pcl-cvs, pcl-git来替代命令行的操作。 M-x cvs-examine: 选择本地的cvs checkout出来的代码,等待一会后,emacs中会有一个cvs summary的buffer,显示本地目录那些改动过的文件。在提交的时候,用m选中那些需要提交的文件,然后按c,就会出现一个新buffer,里边是填写commit log。写完commit log后 C-c C-c,就完成commit了。pcl-cvs和pcl-git还有很多别的用法,可以参考网上的文章。

不要忽略自动测试的部分。个人感觉,gdb里边写的做好的部分就是testsuite了 🙂
regression test:如果你持续在某个toolchain上开发,最好有一个nightly build/test的环境,这里就不介绍持续测试和持续集成了。因为gnu toolchain每天都有来自不同组织处于不同目的对软件进行修改,所以,难免影响到你所希望的功能。如果发现了有regression,可以自己试试修改,这也是做贡献的一种方式。

2 参与开发
gnu toolchain都比较庞大,支持的平台很多,所以刚开始理解代码并且加入到开发是一个十分困难的事情,但是这个也是没有其它什么捷径。造成这些困难的有如下一些因素

历史悠久: 历史悠久对于一个国家或者城市来说,是一个好事情,但是,对于软件来说,这绝对不是什么好事情。



开放的是代码而不是设计: 我们可以看到代码,但是很难看到设计。设计往往存在于代码的注释或者当时邮件列表里边的讨论。

由于开源软件都缺乏文档,所以碰到不会的问题,就要在社区中寻求帮助。目前,社区的交流方式有这样几种,邮件和irc。当然还有第三种,就是参加一年一次的gcc summit,但是这个对大多数人是不适用的。

irc:irc是一种即时聊天软件。我个人觉得,不要期望你能在irc上得到十分好的帮助,除非你和irc的人都很熟了。因为,gnu toolchain的问题,都不是一句两句能说清楚的事情(除非你问gcc 4.6.0什么发布,irc也是一个不错的地方),所以我个人认为irc在获得帮助上没有太大的用处。有一种情况是irc有用的,就是你和某一位或者几位开发人员在邮件列表上已经有过一些交流,剩下一些细节或者yes/no的问题,在irc上问一下,也还不错。

其实在open source 社区中,贡献这个词语出现很多次,但是我们还是没有很多的贡献,至少我是这样。下边这些是为那些想为open source 做些事情的人写的,如果你只是为了用开源软件完成自己的工作或者研究项目,可以跳过这一段。首先澄清一个概念,不是只有global maintainer才可以做贡献,我们这些刚刚开始做的人,也可以。勿以贡献小而不为。我能够想到的,在社区的贡献对你有以下的帮助
1 慢慢被社区所认可和接受,这样对于以后的工作会更有帮助,也有助于下一步的发展
2 短期来讲,有助于别人帮助review你的patch
3 提高在社区的reputation

对于我们刚刚起步的人,可以做那些贡献呢?我们可以到gdb的wiki上看看,上边说了一些需要帮忙的领域,在gdb邮件列表archive里边找找相关的讨论,就能找到一些事情。这样的话,你将来碰到问题,也有人愿意帮助你。所以,尽力去发现开源软件的不足,尽力去改进它,虽然我们很多人在gnu toolchain上开发是我们的工作,但是不要把自己的贡献局限于我们的工作。

总结起来就是,眼光要放远,但是从细节着手。不要把自己的眼光之放在自己的工作的领域,要看得更宽一些,如果有机会在别的部分做一些东西,这样也有助于你有一个大局观。从细节着手,就是说,gnu toolchain的代码都很多,刚开始根本找不到要该的地方。这个时候,就要从一些小的地方开始,比如修一些bug,慢慢的,就会知道更多要改进的地方了。

罗马不是一天建成的。我们也不可能在很短的时间内熟悉这个community,更不要奢望读了这篇blog就可以熟悉这个community的工作方式。我想,只要我们保持热情去贡献,增加交流,在我们中国诞生global maintainer也不是不可能的事情。