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

从Lu申请maintainer被拒看什么是社区

Jia.Liu@hellogcc

今天下雨,回不去,随便写点儿盲人摸象的个人观点,解解闷,自娱自乐总行吧。

关于技术方面的东西,限于我的工作岗位,我能开放的不多,但是我已经把一些能够和大家分享的拿了出来,而且还会继续和大家分享。技术这玩意儿,你偷着藏着掖着,他也不会生出一窝小的来,反而会过时,无用。就像20年前吧(好古老的历史哦),gcc-2.95的时候,某玩意儿说gcc不行,我们比gcc强多了,我们要取代gcc。结果,20年过去了(一代人啊!一代人的青春啊!),我们gcc依然是世界的主流!为什么?因为我们是真正的开源项目!我们有一个真正的开源社区!我们是真正开放的社区!我们是真正公平的社区!

Lu说自己参与binutils和gcc开发20年了,想申请Linux/x86的maintainer。
iant说,不行,你是一个好的开发者,但是你从不review别人的patch,maintainer是对社区有责任的,你没有做到。
Lu说,我申请是因为DT_INIT_ARRAY问题一直得不到解决。
Jan说,这个问题存在很久了,我们在解决。(非常官方的回答哦。)

拒绝Lu可是需要勇气的啊,毕竟参与20年的老人了,而且还“代表”某特。但是,社区不在乎某个公司,某一个人,社区就是社区!是大家的社区!

让我们邪恶的猜想一下,Lu是因为看到很多maintainer的patch不怎么review就进去了,想自己的patch好进。
你可以说我没有根据瞎说,自己可以去check一下binutils的changelog,他的patch都是经过review并接受的么?
好在google的人开始申请binutils和gdb的帐号了,我们期待这两个社区变得越来越规范吧,为了全社区的利益,为了大家的利益。只有规范的社区才能带来更多的好处,如果你希望社区是有几个人控制的,那么我只能怀疑你动机不良,想作为“人治”的一分子,祸害社区的发展了。

这就是典型的权力欲望,只想享受权利,不想承担责任。没有意识到,一个人权力越大,责任也就越大。所以,他越远当不了蜘蛛侠。

OK,不扯了,什么才是社区?什么才叫社区!

gcc社区才是社区!所有的代码都是通过patch的形式,通过了maintainer的review才能进去的!不会因为某种原因走后门的,不会因为你跟某个maintainer关系好,他就接受你的patch,不会因为你是某个公司的,你就能左右patch是否被接受。

社区,是一个开放的,任何人都可以参与,只要你愿意,你真心给社区提交代码,做测试,找bug等等。

社区,是一个公平的,社区负责人(主要是maintainer),不能只享受权力带来的好处,而不负责任。不能为了一己私利而损害别人的利益,损害社区的利益。

社区,不是小圈子,只有某两个公司和某几个高校还有某个研究所的人才能参与,别人都靠边站。

你弄个伪开源的项目,弄个网站,自己管自己叫社区,那不行的,没有人参与,没有人承认你的。

社区是什么?是一个奉献和索取的平衡体,你只有奉献了你的精力,不仅仅是代码哦,还有文档,还有帮助他人成长。才能得到社区成员的尊重,经济利益就不用说了,哪个global都不缺钱的。
但是!社区的前提是公平开放的!RMS那老头子玩儿了一辈子,最后不做技术了,一直想制定一套相对公平开放的规则,为什么?
一个社区要发展壮大,不可能只为极个别的人服务的,社区要为全社区,甚至社区外的人都带来好处才行。
还有非常关键的一点就是开放!开放!开放!社区不是封闭的,封闭了就成了小圈子了,你一个小圈子最多伪装成一个社区,请不要侮辱“社区”这个字眼了,你们已经把“研究”和“专家”的字眼给侮辱了。
谢谢合作!

那么,最后,我们想想,自己是什么样的人呢?自己有资格参与社区开发么?自己的灵魂肮脏到不配参与社区么?自己是一个为了满足自己的权力欲望而祸害社区的人么?
gcc社区为什么这么红火?一天光patch就几十个。是因为gcc社区的制度?还是因为gcc社区的人?

一个人的能力和他的品德并没有直接关系的。

最后,我充分相信,我们大家都是高尚的人,纯粹的人,有道德的人,脱离了低级趣味的人,有益于社区的人。

开始加入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代码。

change:
这里以emacs为例,编写代码要注意gnu的编码规范。写代码前,自己好好读两遍。

对于其他编辑器,比如vim和eclipse,用户可以自行设置。只要符合下边的一些要求就可以了

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

这里有一个比较详细的,http://sourceware.org/gdb/wiki/JoelsCodingStyleCheatSheet

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

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

生成patch以后,一般是在patch的头部加入changelog,用mklog.pl
。这个时候不用修改源代码的changlog。

发送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用的不多,所以解释不是很准确]

在邮件中简单介绍你的修改的目的和概要,如果需要,保证这个修改没有引入regression。

有的时候,可能为了实现一个功能,修改是分很多部分的,比如第一部分是为了增加这样的功能,对现有代码的重构,第二部分是实现新功能的代码,第三部分是测试用例,第四部分是文档。如果作为一个patch发出去,别人review起来比较难受,也很难理解你的意图,这个时候,就要在一个邮件thread里边,把patch分多个发出去。具体操作如下,在发patch之前,自己先想好,如何把自己的修改合理的拆分到若干个patch里边去,然后第一封信写清楚你这一系列patch的目的,和大体实现,不要attach任何patch,比如
[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也比较容易。

如果还不明白,看看别人是怎样写patch的。不过还不明白,可以在hellogcc讨论。

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了 🙂
gcc和gdb的wiki上都有一页关于编写测试用例的。建议好好读一读。如果之前对dejagnu和tcl/expect不是很清楚的人,建议去了解一下dejagnu。
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也不是不可能的事情。