走MOTU /开发者之路的最大障碍是什么?[关闭]


26

对于不是MOTU(维护Universe和Multiverse软件存储库的人)并且没有“我将在$ date之前申请MOTU”计划的人:

是什么使您和其他与您一样的人无法成为MOTU?是什么让您认为自己无法成为一体?

我指的是社会和技术障碍。

编辑: 我只是说MOTU,因为它是一个相当普通的组,但是“为什么不打包/打补丁并打算最终尝试上载权限?” 是一个更通用的版本。


7
对于不知道它是什么的人(例如我),请将MOTU链接到wiki.ubuntu.com/MOTU
Steve Armstrong,2010年

1
我同意链接会有所帮助。但是,鉴于这个问题是关于人们为什么不属于某些特定事物的原因,最好在问题中进行实际解释。
moberley

@moberley:MOTU是可以将软件包上传到Ubuntu档案的Universe(和multiverse)部分的开发人员。
txwikinger 2010年

忘了更新我的Ubuntu的开发和Ubuntu-coredev成员,而不是havint时间去经历的过程又是为什么我不是一个MOTU / coredev了;-)
ℝaphink

1
由于问题样式,已转换为Community Wiki。
Marco Ceppi

Answers:


11

提供更好的文档。

我参加了与包装和MOTU内容有关的开发人员周的IRC会议(已经两次),发现在这些会议中,您通常对流程有模糊的了解。但是,如果两周后再查看Ubuntu Wiki页面,您将无法再将所有内容整合在一起。这些页面通常是一些已经很详细地了解该过程的人的要点列表。但这还不足以使新手可以理解这些内容。

因此,也许您应该尝试使文档Wiki页面更详细地解释过程,工具和相关人员。甚至带有完整的示例。在IRC会话期间,总是有可重复的示例,也许这些示例对Wiki页面有所帮助。


2
我同意维基页面不是很有帮助。刚开始时,我发现Daniel Holbach在YouTube上的视频最有帮助。IRC会话的日志是否已发布到Wiki?
maco 2010年

14

我认为最大的技术障碍是知道如何创建Debian软件包。尽管创建工作包相对简单,但要创建符合Debian和Ubuntu标准的软件包却要困难得多。另外,有关如何创建软件包的指南通常会处理您具有需要编译的源代码的情况。这对于使用解释语言编写的应用程序可能会造成混淆。

最大的社会障碍可能是知道如何将软件包上载到Universe / Multiverse存储库中。只需创建自己的ppa并在那里上传软件包,就容易得多。


11

如今,人们喜欢主动捐款

20年前,如果有宠物项目,通常会把大量精力投入到宠物项目上。今天,您每天访问数十个Internet页面,并且有很多社交网络或其他社区,您可以在其中贡献Wiki,论坛和其他内容。尽管这导致更多的人做出了贡献,但也导致人们期望进入的门槛较低(请直接单击网站进行编辑),否则他们可能会转向其他社区。

因此,您应该在MOTU过程中寻找障碍。我记得GroundControl项目可以降低启动板托管项目中补丁贡献的障碍。也许您需要类似的新工具,所以新的MOTU候选人不必摆弄许多命令行工具。尽管这些当前的工具可能功能强大,但可能需要大量的精力来学习如何正确使用它们。


3
我不知道我是否喜欢不能使用shell维护软件包的人的想法,因为shell脚本是打包的重要组成部分(也就是说,需要编写/修改shell脚本才能制作许多软件包)工作)。
maco 2010年

@maco:您想获得新的参与者吗?如果是这样,您应该接受可能需要更改流程(而不仅仅是涉及流程的人员)的想法。精英思想将排除大部分潜在社区。而且,如果您想花很多精力来入门,那么命令行通常是支持它的非常糟糕的工具。
Bananeweizen

1
这就好比说“需要知道一些C才能编写内核补丁”。您仅需要知道命令行如何工作来编写进入程序包的脚本。即使您有用于制作软件包的GUI,它最终也会带有一堆“在此处键入postinst shell脚本”文本框。
maco 2010年

1
我的评论与技术必要性无关。我会尝试重新措辞(我不是英语母语人士):首先,您要求其他贡献者。之后,我读了您的评论:如果您不能编写shell脚本,您将愚蠢地参与打包。那让我难过。我仍然相信您的假设是错误的。直到Ground Control,每个人都必须了解版本控制系统,才能打补丁LP中的某些项目。GC并没有使版本控制变得更容易,而是与补丁的单个用例相矛盾,并消除了对版本控制系统的任何了解。
Bananeweizen

1
我没有在任何地方说“哑巴”。我说这是必要的技能。对于任何复杂的软件包,您必须编写一个shell脚本。无知(尚未学习某种技能)和智能绝非相同。
maco 2010年

9

我发现的最大障碍是Ubuntu开发人员页面:http//www.ubuntu.com/community/get-involved/developers

这么多次,我已经下定决心要为Ubuntu贡献至少一个补丁……所以我去了网站上的自然位置……最终迷失在大量的文档中。几个小时后,我仍然不知道该写些什么补丁。当我查看Ubuntu的bug时,我经常会找到补丁...许多只是闲置的地方。

就包装而言,我试图弄清楚如何制作它们,这确实令人困惑。我也尝试加入Launch Pad,但是界面比Source Forge复杂得多,我无法在LP上获得自己的代码。对于新用户而言,这非常困难。


2
是的,启动板设计有问题。在LP上情况并不明显。这很容易,但是您必须寻找很多东西。新用户很快就会迷路。它需要重新设计,使其像GitHub一样更加明显和简单。
Owais Lone 2010年

8

成为MOTU是一种责任

好吧,显然,第一个原因是技术上知识不足,第二个原因是您宁愿做很多事情。但是在您的目标受众中,我认为主要原因是这是一种责任。

如果我为自己编译一个程序包,则没有人会在乎我是否遵守技术和法律政策。没有人会期望我打包一个更新的版本。没有人会要求我修复错误。

如果我将包裹上传到PPA,可能会有几个人在乎。但是期望并不高。我只是消失了,让人们在他们的博客上抱怨该软件包无法用于natty narwhal,这是多么可悲。

如果我成为MOTU,突然之间我将承担重大责任。用户会来找我报告错误,如果我昨天没解决,会抱怨。用户将期望我在上游提供该软件包的新版本。我将不得不向非技术用户解释如何弄清楚他们做错了什么。与在论坛上发帖不同,我不应该忽略我不想回答的问题。其他开发人员可能会追随我,因为我搞砸了某些东西–这可能令人生畏。

我能得到什么呢?

  • 我帮助别人的模糊感。那很重要。但是,如果这是我的主要动机,那么包装软件如何与在煲汤厨房提供帮助或辅导您的失业移民邻居的孩子相提并论呢?

  • 我简历上的要点?嗯,以程序员的身份参加FOSS会受到更多的赞赏。(它为您提供了项目管理和长期维修等方面的经验,这些经验在大学课程中很难教到。)实际上,对于许多不愿参与政治工作的雇主而言,担任DD / MOTU似乎很可疑(您是公开地向FOSS提供政治支持)。

  • 有满足感吗?比起从头开始编写自己的程序要少得多。编程比打包更具创造力。有很大的成就感。吹牛的权利。但是在包装上?这很麻烦。这不是迷人的。

(上面是第三人称“ I”。我认为我给出的原因适用于大多数人,但程度有所不同。就我个人而言,我主要想做的事情很多,而包装缺乏创造力。)

(出于好奇,Ubuntu是否缺乏人力?)


1
是的,它确实。您看过我们的bugtracker吗?
maco 2010年

@maco:在MOTU页面上,我可以轻松地了解什么是MOTU以及如何成为MOTU。我没有看到任何有关“ Ubuntu叔叔需要您!”的信息。我认为Bugtracker不会对休闲用户说太多。例如,许多未公开的bug可能意味着许多报表运行用户,他们没有发布足够的信息来重现该bug。
吉尔(Gilles)“所以,别再邪恶了”,2010年

我必须完全同意吉尔斯。如果我有更多时间致力于开源,那么我有两个我想编程的项目。
哈维尔·里维拉

有很多类似的错误,但是最终由于不活动而被关闭。Launchpad上附有约2000个带有补丁的bug。Cleansweep行动一直在研究和检查修补程序,如果良好,则将其发送到上游,如果不良,则将其拒绝。如果它们很好,并且不应该等待整个发行周期来完成上游发行,则需要将它们打包。虽然很多岁。我们没有跟上他们提交的速度。
maco 2010年

4

语言,我的主要问题是我对英语仍然不够自信,因此,我不容易理解其他开发人员试图告诉我什么


3

是什么阻止我成为MOTU?

尽管Ubuntu是一个非常不错的社区(但尚未引起n00bie问题的困扰),但我认为关于打包过程的文档很少/不完整(即使Debian的New Maintenanceer指南也充满了“该主题不在讨论范围内”)文档”行)。如果您考虑到这一事实,并考虑母语不是英语的人(例如我),那么这个过程将更加困难和顺心。

通过简单,正确的方法来编写文档,对我们所有人来说,所有事情都将变得更加容易,但是拥有技术娴熟的技能来编写该文档的人都忙于这样做。


3

我认为有几个原因。我也认为原因通常是个人原因。

目前的问题之一是整个MOTU系统的变化。我相信,这些更改可能会造成混淆,并且已在技术路线上进行了更多的实施,但是不幸的是,这些更改并未使社区充分参与(也许只是因为它令人困惑)。

我还认为,在某些情况下,成为MOTU的动机并不尽如人意。恕我直言,成为MOTU是责任,而不是特权。它与标题无关,而是与它附带的访问权限有关帮助Ubuntu社区的能力。因此,有可能整个审批流程都可以修改(或扩展)。MOTU通常会提名自己,然后董事会会检查他们是否准备好成为MOTU。也许有可能,相信某人已准备好成为MOTU的同龄人能够提名该人。恕我直言,这更代表了这样一个事实,即提名是为了帮助过程,而不是获得头衔。我知道,仅此一种方法也有问题,因此,我宁愿将其视为替代方法,也是唯一方法。

我还知道过去人们会更加关注KDE时会遇到一些问题。希望已解决了这些问题,但如果将其广为人知也许会很好。

显然,这些只是我注意到的几个问题。人们是不同的,会看到不同的事物,或者受同一事物的影响不同。因此,这些问题可能不会阻止所有人,也不是导致此问题的唯一原因。


发起人应该在告诉人们他们准备好的软件包时告诉他们,“嘿,也许您现在应该申请”,但是我不知道这种情况发生的频率。我建议向我所指导的一个人申请,但他将重点转移到其他发展领域。
maco 2010年

当保荐人告诉某人提出申请,或者该人由保荐人提名时,仍然是不同的。
txwikinger 2010年

嗯 发起人不提名人,发起人主张被提名人的自我提名。
lfaraone 2010年

lfaraone:txwikinger建议赞助者应该能够提名人。它曾经发生过一次。一些人去为莎拉·霍布斯创建了一个Wiki页面,并通过电子邮件发送给结核病并提供了推荐信,因此,在明确支持的时候,她出现在IRC会议上,采取了最后一步。
maco 2010年

2
@Ifaraone:我建议有些好人不会自我提名自己,因此我们会失去他们。最后,成为MOTU的好人对Ubuntu来说是一个胜利,也许我们应该考虑一下。
txwikinger 2010年

2

我在这里发表了一些想法:http : //blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

我真正想带出的一件事是,我想知道有多少开发人员没有使用轻松插入打包工具的构建系统。我正在做python开发。我的工作围绕着setuptools进行,并且可以分发,是的,我可以拿走我用这些工具构建的东西并将其导出,但是目的是什么?我已经有一些可分配的东西。我想知道使用自己的构建工具/发行方法的脚本语言的兴起是否会导致缺乏经验和渴望,无法将这些东西与debian打包工具以及MOTU级别放在一起。


2

对我来说,这可能与时间有关。目前,我没有很多时间可以投资。我从错误分类开始,但很快发现事情要复杂一些。而且,您确实需要全神贯注。

然后是错误修复,我知道我会喜欢的。使我无法提供帮助的是,您需要运行开发部门或其他事务。我曾经开始在System Monitor(https://bugzilla.gnome.org/show_bug.cgi?id=611738)中研究我的剪纸,所以我开始使用Ground Control来获取所需的源并进入那里修复错误。但是,由于依赖关系,事实并非如此简单。我知道我应该只在开发版本上工作,并测试该版本是否已修复。但是,只是为了尝试我需要下载许多其他gnome软件包的源代码。地面控制并不容易。您可能应该在工作机器上执行此操作。所以我停在那里。(再次,这会花我太多时间,只是为了开始)

关于包装,我只是不知道需要包装的任何东西。我曾经做过关于包装的教程,发现对于小型应用程序来说并不太困难。但是从来没有出去寻找需要包装的东西的清单,因为我知道可能有一个... :)

所以基本上对我来说只是时间,我想帮忙,但每隔一周左右我就会有几个小时(2个左右)。在这么短的时间内,我似乎无法开始。


您不需要依赖项的来源,仅需要常规deb。为什么不设置要使用的开发版本的VM?然后,您不必设置程序(尽管,自2007年2月以来,我几乎一直在运行devel发行版……在我开始做任何与打包/修复Ubuntu错误有关的事情之前一年)。设置好环境后,绝对有可能每周2小时修复一次错误。关于要打包的东西的列表:Launchpad上有一个需要打包的标签。打包现有补丁也非常有用!
maco 2010年

1

当我创建一个程序包时,通常会抓痒,不是因为其他人想要该程序包。Checkinstall足以为我制作一个程序包,然后痒痒挠了,我没有个人动力去手动安装它,并弄清所有依赖项和内容。

因此,我想即使打包分发很容易,但除了打包自己之外,还有很多工作要做。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.