对于不是MOTU(维护Universe和Multiverse软件存储库的人)并且没有“我将在$ date之前申请MOTU”计划的人:
是什么使您和其他与您一样的人无法成为MOTU?是什么让您认为自己无法成为一体?
我指的是社会和技术障碍。
编辑: 我只是说MOTU,因为它是一个相当普通的组,但是“为什么不打包/打补丁并打算最终尝试上载权限?” 是一个更通用的版本。
对于不是MOTU(维护Universe和Multiverse软件存储库的人)并且没有“我将在$ date之前申请MOTU”计划的人:
是什么使您和其他与您一样的人无法成为MOTU?是什么让您认为自己无法成为一体?
我指的是社会和技术障碍。
编辑: 我只是说MOTU,因为它是一个相当普通的组,但是“为什么不打包/打补丁并打算最终尝试上载权限?” 是一个更通用的版本。
Answers:
提供更好的文档。
我参加了与包装和MOTU内容有关的开发人员周的IRC会议(已经两次),发现在这些会议中,您通常对流程有模糊的了解。但是,如果两周后再查看Ubuntu Wiki页面,您将无法再将所有内容整合在一起。这些页面通常是一些已经很详细地了解该过程的人的要点列表。但这还不足以使新手可以理解这些内容。
因此,也许您应该尝试使文档Wiki页面更详细地解释过程,工具和相关人员。甚至带有完整的示例。在IRC会话期间,总是有可重复的示例,也许这些示例对Wiki页面有所帮助。
如今,人们喜欢主动捐款。
20年前,如果有宠物项目,通常会把大量精力投入到宠物项目上。今天,您每天访问数十个Internet页面,并且有很多社交网络或其他社区,您可以在其中贡献Wiki,论坛和其他内容。尽管这导致更多的人做出了贡献,但也导致人们期望进入的门槛较低(请直接单击网站进行编辑),否则他们可能会转向其他社区。
因此,您应该在MOTU过程中寻找障碍。我记得GroundControl项目可以降低启动板托管项目中补丁贡献的障碍。也许您需要类似的新工具,所以新的MOTU候选人不必摆弄许多命令行工具。尽管这些当前的工具可能功能强大,但可能需要大量的精力来学习如何正确使用它们。
我发现的最大障碍是Ubuntu开发人员页面:http://www.ubuntu.com/community/get-involved/developers
这么多次,我已经下定决心要为Ubuntu贡献至少一个补丁……所以我去了网站上的自然位置……最终迷失在大量的文档中。几个小时后,我仍然不知道该写些什么补丁。当我查看Ubuntu的bug时,我经常会找到补丁...许多只是闲置的地方。
就包装而言,我试图弄清楚如何制作它们,这确实令人困惑。我也尝试加入Launch Pad,但是界面比Source Forge复杂得多,我无法在LP上获得自己的代码。对于新用户而言,这非常困难。
成为MOTU是一种责任。
好吧,显然,第一个原因是技术上知识不足,第二个原因是您宁愿做很多事情。但是在您的目标受众中,我认为主要原因是这是一种责任。
如果我为自己编译一个程序包,则没有人会在乎我是否遵守技术和法律政策。没有人会期望我打包一个更新的版本。没有人会要求我修复错误。
如果我将包裹上传到PPA,可能会有几个人在乎。但是期望并不高。我只是消失了,让人们在他们的博客上抱怨该软件包无法用于natty narwhal,这是多么可悲。
如果我成为MOTU,突然之间我将承担重大责任。用户会来找我报告错误,如果我昨天没解决,会抱怨。用户将期望我在上游提供该软件包的新版本。我将不得不向非技术用户解释如何弄清楚他们做错了什么。与在论坛上发帖不同,我不应该忽略我不想回答的问题。其他开发人员可能会追随我,因为我搞砸了某些东西–这可能令人生畏。
我能得到什么呢?
我帮助别人的模糊感。那很重要。但是,如果这是我的主要动机,那么包装软件如何与在煲汤厨房提供帮助或辅导您的失业移民邻居的孩子相提并论呢?
我简历上的要点?嗯,以程序员的身份参加FOSS会受到更多的赞赏。(它为您提供了项目管理和长期维修等方面的经验,这些经验在大学课程中很难教到。)实际上,对于许多不愿参与政治工作的雇主而言,担任DD / MOTU似乎很可疑(您是公开地向FOSS提供政治支持)。
有满足感吗?比起从头开始编写自己的程序要少得多。编程比打包更具创造力。有很大的成就感。吹牛的权利。但是在包装上?这很麻烦。这不是迷人的。
(上面是第三人称“ I”。我认为我给出的原因适用于大多数人,但程度有所不同。就我个人而言,我主要想做的事情很多,而包装缺乏创造力。)
(出于好奇,Ubuntu是否缺乏人力?)
我认为有几个原因。我也认为原因通常是个人原因。
目前的问题之一是整个MOTU系统的变化。我相信,这些更改可能会造成混淆,并且已在技术路线上进行了更多的实施,但是不幸的是,这些更改并未使社区充分参与(也许只是因为它令人困惑)。
我还认为,在某些情况下,成为MOTU的动机并不尽如人意。恕我直言,成为MOTU是责任,而不是特权。它与标题无关,而是与它附带的访问权限有关帮助Ubuntu社区的能力。因此,有可能整个审批流程都可以修改(或扩展)。MOTU通常会提名自己,然后董事会会检查他们是否准备好成为MOTU。也许有可能,相信某人已准备好成为MOTU的同龄人能够提名该人。恕我直言,这更代表了这样一个事实,即提名是为了帮助过程,而不是获得头衔。我知道,仅此一种方法也有问题,因此,我宁愿将其视为替代方法,也是唯一方法。
我还知道过去人们会更加关注KDE时会遇到一些问题。希望已解决了这些问题,但如果将其广为人知也许会很好。
显然,这些只是我注意到的几个问题。人们是不同的,会看到不同的事物,或者受同一事物的影响不同。因此,这些问题可能不会阻止所有人,也不是导致此问题的唯一原因。
我在这里发表了一些想法:http : //blog.mitechie.com/2010/08/24/ubuntu-help-wanted/
我真正想带出的一件事是,我想知道有多少开发人员没有使用轻松插入打包工具的构建系统。我正在做python开发。我的工作围绕着setuptools进行,并且可以分发,是的,我可以拿走我用这些工具构建的东西并将其导出,但是目的是什么?我已经有一些可分配的东西。我想知道使用自己的构建工具/发行方法的脚本语言的兴起是否会导致缺乏经验和渴望,无法将这些东西与debian打包工具以及MOTU级别放在一起。
对我来说,这可能与时间有关。目前,我没有很多时间可以投资。我从错误分类开始,但很快发现事情要复杂一些。而且,您确实需要全神贯注。
然后是错误修复,我知道我会喜欢的。使我无法提供帮助的是,您需要运行开发部门或其他事务。我曾经开始在System Monitor(https://bugzilla.gnome.org/show_bug.cgi?id=611738)中研究我的剪纸,所以我开始使用Ground Control来获取所需的源并进入那里修复错误。但是,由于依赖关系,事实并非如此简单。我知道我应该只在开发版本上工作,并测试该版本是否已修复。但是,只是为了尝试我需要下载许多其他gnome软件包的源代码。地面控制并不容易。您可能应该在工作机器上执行此操作。所以我停在那里。(再次,这会花我太多时间,只是为了开始)
关于包装,我只是不知道需要包装的任何东西。我曾经做过关于包装的教程,发现对于小型应用程序来说并不太困难。但是从来没有出去寻找需要包装的东西的清单,因为我知道可能有一个... :)
所以基本上对我来说只是时间,我想帮忙,但每隔一周左右我就会有几个小时(2个左右)。在这么短的时间内,我似乎无法开始。
当我创建一个程序包时,通常会抓痒,不是因为其他人想要该程序包。Checkinstall足以为我制作一个程序包,然后痒痒挠了,我没有个人动力去手动安装它,并弄清所有依赖项和内容。
因此,我想即使打包分发很容易,但除了打包自己之外,还有很多工作要做。