打印

加入开发组为什么就那么难?

加入开发组为什么就那么难?

有很多初学者都想参与进来,但是却不知道从哪里下手,比如维护一个软件需要什么知识,写安装程序需要什么知识,就算现在不会也让我们知道知道,为将来学习打基础吗,这样我们的队伍才会越来越强大,参与的人会越来越多!!!还有什么建议大家都写出来!!

TOP

同意!支持 !

TOP

*RPM制作方法;
*软件编译方法;
*patche制作方法;
以上资料都比较容易找到.

当然前提是对C语言要熟悉,至少要懂一些.

软件包维护版块有维护方法说明的.

TOP

新手如何参与?是否可以写一个项目表,可以写得细一写,公布出来,大家申请领取,可以采取申领人和跟班制.一个申领人带一些跟班,或公布申领人的联系方式,希望参与的人与申领人联系.我现在很想参加,但我不知道如何参加,不知道项目具体还需要什么样的人做什么样的事.使我无从下手.

TOP

这显然不适合初学者。

TOP

其实不一定说每个人都要参与开发的,也不一定每个人都要懂得维持。

我们这些新人一开始如何学会使用Linux。这一点在一个软件的发展中是很重要的。

为什么Windows会这样普及,就是因为它很容易上手。人们只要多尝试就可以初步入门了,还可以进行一点日常的操作。时间一长,熟能生巧,平时又无意中得到了不少Windows的维护知识。这样子Windows体系中就有了一群我们日常生活中的维护人员,譬如电脑店里的工作人员。

Linux因为它本身的特点,想让新人很快的上手是不可能的,但是我们为什么不能想办法缩短新人的入门时间呢?!我们有很多方法可以让新人比较系统的得到使用Linux的方法的。比如说,一个用Flash做的帮助。如果我们找到了一个方法能使更多的人把他们上手时间缩短一半,或者1/3也好,这样子Linux不就会有了更多的用户了吗?

现在网上很多教我们学Linux的视频或者文档都是教我们如何输入命令的。不能说这样不好,但是有一个重要的问题就是,这样学,我们可能很快就放弃Linux了。
为什么我们不能先让新人都学会如何用图形界面来进行操作呢?因为世界不是每个人都要维持Linux的,Linux只是一个工具。工具有它的使用者,但维修可以让维修工去做的。

在这里,对ML的发展有一个建议。现在ML在易用性和稳定性已经达到一个水平了,但是ML对于吸收更多的新的Linux新人的工作做得不够。看了看现在ML的帮助都是KDE英文的,不是所有人都看得懂。所以我觉得ML应该在开发的同时,写一个如何Linux文档,方式可以为Flash。那是一个教用户对ML的提供的功能如何实现。说明分两种,一种是简单的,一种是给高级用户的。关键可以让用户懂得如何进行日常的操作

想像一下,如果ML这样做了以后,一个新人安装了ML。他/她进行了一些基本的初始化配置后,他/她看见了ML的“欢迎使用”的界面,这个界面提示了ML能实现的基本功能,还友情提示说,Linux不是一个很难使用的操作系统。如果你有什么不懂,可以查阅我们的帮助。

这样子,新人在使用ML的第一次就有了一个印象,ML有一个帮助系统,以后他/她在使用不懂的时候就会想到先去查阅ML的帮助,而不是上网。新人能够很方便地进行他们所需要的日常操作。

如果ML做到了这个效果,那么一定会吸引更多的新人。有了大量的使用人员,就有了更多的维护人员,就有了更多对ML熟悉的人。这样参加开发ML的人员水平就更高,ML的未来就会更好

TOP

你是个比新手还要新手的人。基本的一些情况都不清楚。

1. kde 的帮助文档翻译应该由 i18n 组织负责,但是计划了这么多年也没搞成,而且 i18n  工作由于系统的故障一直没有修复,目前几乎处于停止状态。

2. magic 开发组人手非常紧张,根本没经历搞翻译。

3. 开发的门槛是非常高的,时至今日,我在这方面也只能算是一个学生,而且我不是学计算机的,所以不懂软件开发,对软件自身的问题我还不能修理、打补钉。组里的其他同事论专业技术都比我强。初学者连系统的目录结构都不清楚,基本的命令行操作都不熟悉,连使用都不灵活,如何能进行开发?

4. magic 的大门是随时对所有人开放的,但是新手来了又能做什么呢?你必须交出一个作品来证明你的实力,无论是一个 linux 下的软件、补丁、界面的改进(比如图标、壁纸、声音主题)、参与某个软件工程的证明,或者对一个软件的打包。这些绝不是一朝一夕能作到的。

5. 图形界面其实和 windows 没什么区别,如果熟悉 win 根本没必要单独去学,除非你从来没有接触过计算机。事实上来这里的人基本都是 windows 老鸟甚至高手。

6. 我在开发培训版已经给出了一个初级的 rpm 打包原理和一个实战错误分析,还有 gcc 编译优化参数的说明,请首先阅读。

7. 更重要的并不是你能不能加入开发组,而是你能不能持之以恒做一件事情。开发工作实际是非常枯燥、非常耗费经历的,如果没有出奇的兴趣和毅力很难坚持。开发组人员并不少,但是活跃的开发者非常少,我们不希望看到你三分中热乎劲就不了了之了。

8. 我们没有能力和经历做类似《开天辟地》、《万事无悠》、《畅通无阻》之类的教学软件,那是非常大的工程。企业做它要考虑销量,windows 用户这么多,这种软件销售都不很火,会有企业做 linux 下的教学软件吗?况且发行版多如牛毛,开发者各自的出发点不同,面向的用户群不同,可谓千奇百怪,谁只要有能力,就可以按照自己的意愿制作一套发行版,教学软件怎么能涵盖这么大面积?

TOP

首先要说明一点,我不是要求ML做什么翻译的,自己也没有想立即加入开发的意思。因为我知道我还没这个能力。

我是学习计算机的,不过这并没说明什么。事实上学计算机的能力不一定就强,我们可能什么都不是。我们知道开发系统不容易,并不是一下子就能进去的。说实话,我们也没有那么多精力时间进行Linux的开发。因为我们学习自己的课程已经吃不开了。曾经问过应该如何入门,如何加入开发,这也是想知道是怎么运作的。像我这样比新手还新手的人应该有一个自我发展的计划。

我用ML是因为我觉得它的中文很不错,运行速度还可以。更重要的是我不想再用Windows了。因为Linux是免费的。我的目的是使用,要Linux可以做很多,就连制作一个新操作系统在Linux上也可以很容易地实现。但是我在使用发现一个问题,我知道ML有一些比较好用的功能,可不知道如何去使用,像自动更新那样。

没有说ML应该去做《开天辟地》、《万事无悠》、《畅通无阻》之类的教学软件,想都没想过,只是建议ML做一个帮助,做一个功能说明。一个软件配一个详细的使用文档,这是软件开发的一个基本常识。可能是我没表达清楚,让KDE认为是做一个教学软件了。

再强调一下,我上一次的帖子想表达的意思是如果ML有很多的使用人员,理所当然就会有很多的维护人员;维护经验丰富的人多就有更多的人想加入开发了;开发人多了,做核心的人也多了。这是一个金字塔!这也是常理

KDE不是说了ML的开发人员不足吗?从长远来说,ML的使用人员是越多越好的。其实整个Linux系统都是这种情况。没有很好基础,高楼怎么建起来呢?


人欲盡淨,觀萬物,各復歸其根,精之至也。
  • 不要重复自己(Don't Repeat Yourself )。
  • 约定优于配置(Convention Over Configuration )。

TOP

说实在的,我想公社应该建立图书档案室,一些好的文章收集成册,进行分类汇总,这个并不太难,并划区给一些爱好者去修订唯护。这样一些资料不会失去效用,不至于跟不上时代。现在的LINUX热不如以前,很多资料在抄袭中失效,成为网络垃圾。
给人工具永不如教会人制做工具更有意义,ML去汉化资料我觉得没必要,跟不上外国技术的变动和更新。而且,一个开发者必需对英文有基本的阅读能力。我认为资料是最重要的,不管是英文的还是中文资料,汉不汉化并不重要,重要的是归类整理,把它变成有理有序的档案,可以查询,可以学习。论坛也会因此少些无用索取式的问题,多些讨论,我想公社是有这个能力的。

TOP

linuxsir 在这方面做得很好。

TOP

这几天仔细地把开发版的精华贴和置顶贴看了一遍,想想自己两个月的话挺可笑的,

还是 KDE 说得对,这显然不适合初学者。

不过想加入开发组也不是很难的,是我们的想法错了!

首先我们应该好好地把开发版的置顶贴看一遍。学学怎么做RPM包的,怎么优化,怎么打补丁。这些我们都应该知道。

然后就是好好地用用 ML,看看有什么BUG,看看哪些 BUG 自己能解决的,把你的解决方法发到这里来,最好附带你修改过的补丁。有好的解决方法,相信 Kanker & KDE 会采用你的。

打补丁是一个开始,Kanker 他们采用了你的方法也是你加入开发组的一个开始。

呵呵,不过,我到现在还没有加入开发组的能力 还得好好学学。把现在的想法分享给那些跟我两个月前那样一样激情的朋友。 大家一起努力吧   


人欲盡淨,觀萬物,各復歸其根,精之至也。
  • 不要重复自己(Don't Repeat Yourself )。
  • 约定优于配置(Convention Over Configuration )。

TOP

制作rpm包也不难撒
大部分的成型的软件,源码包中都有写好的spec
要做的事情就是参考ML下其他rpm的spec,修改一下就可以了
然后rpmbuild一下就OK
呵呵
挺简单的
开发计划:   llk_linux-2.2版 已经发布,欢迎主页:http://llk-linux.sourceforge.net

TOP

要学打包,来加入我们的讨论组吧

http://groups.google.com/group/packagers
g o o d

TOP

制作 RPM 包确实是不难的。打包的难处在于那些依赖性,很多时候挺烦的。还有还要解决那些因为别的包而产生的特殊问题。

现在我的兴趣是给现有的包抓 BUG,这样好玩啊


人欲盡淨,觀萬物,各復歸其根,精之至也。
  • 不要重复自己(Don't Repeat Yourself )。
  • 约定优于配置(Convention Over Configuration )。

TOP

Weiwei加油   我要追三顺!

TOP