感谢Harald Leithner!
Joomla的存在离不开其志愿者的奉献。在这篇文章中,我们想表达我们对Harald Leithner的感激和敬意,他长期担任Joomla 3.9.x系列的发布负责人。多年来,Harald在项目中的角色多样,他还担任了2019-20年度的生产部门协调员。但让我们深入了解发布负责人的日常工作,通过直接采访Harald来了解。
您能描述一下发布负责人的“发布日”通常是什么样的吗?
通常的发布日开始于一周前,收集发布版本的最后一个RTC(准备提交)PR(拉取请求)。根据PR的复杂程度,我对合并的每个PR至少进行一次代码审查。之后,我会检查是否有悬而未决的问题/拉取请求设定在即将到来的发布里程碑。如果应该进入发布的PR缺少测试或存在一些开放讨论,我会尽力解决问题。这意味着我会尝试找到一个测试者或自己进行测试。如果对PR没有共识,我会与其他维护者商议如何处理PR,并在我们说可以的情况下将其合并。完成这部分工作后,我会创建发布候选版本。这基本上是执行一些脚本并将标签和文件上传到GitHub的过程。(实际上工作量远不止按几个按钮)。然后,我会通知发布团队已上传发布候选版本,并给出一些提示,说明我希望更加仔细地测试哪些内容。例如,对我来说看起来复杂或风险较高的PR。根据发布团队的反馈,我会修复报告的基本问题,并在实际发布前几天创建另一个RC或构建最终的发布包。
创建实际发布通常分为两天。第一天,我会与JSST确认哪些安全修复已经准备好并可以合并。这只能在笔记本电脑上完成。我会标记发布版本并构建软件包。此外,我还会为发布日准备几个Joomla属性。这意味着我在downloads.joomla.org上创建下载条目,在joomla.org上创建发布文章,并与市场营销团队分享以进行其他语言的翻译。此外,最终软件包还会再次分发给发布团队进行最终测试,特别是安全补丁。另外,一小部分其他团队会提前一点时间获得最终文件。在发布日,通常为周二,我会通知发布团队即将发布的版本,并在网站上进行最后的清理。将文件上传到三个不同的位置(Amazon S3、update.joomla.org、github)开始实际发布。然后,我将准备好的安全文章和Joomla.org文章公开,我还将合并的安全/发布提交推送到github。这基本上是发布的最后任务。在此之后,我会合并一些为docker准备的提交,并更新夜间构建和API文档。我可能会根据整体情况更新维基百科。这是如果一切顺利的发布,但还没有结束,现在需要关注论坛和问题跟踪器。只要没有报告真正严重的问题,我的工作就结束了。如果不是这样,我将有一个漫长的糟糕日子,需要创建另一个发布。
在你看来,成为一个优秀的发布领导者需要什么?
我不知道一个优秀的发布领导者需要知道什么。我不知道我是好是坏。大多数时候,我只在坏事发生时收到反馈。如果一切顺利,我可以在论坛上阅读一些成功故事。对于Joomla!我会说,你需要一个坚强的外壳,不要把所有的事情都放在心上(这对我很困难)。
你是如何成为Joomla志愿者的?
自从使用Mambo以来,我在IRC频道上进行了一些随意的聊天,并于2016年参加了第二届JoomlaDay奥地利。在这之后,我开始通过访问JoomlaDay德国并加入glip聊天来变得活跃。所以实际上,我在这个社区中并不久。
你在社区中已经活跃了好几年。哪些时刻你将永远铭记在心?
我想是在我的第一次JoomlaDay奥地利上和一个戴黑色棒球帽的人交谈。还有在罗马的Joomla世界大会。有一些情况,但实际上是那些我遇见并喜欢交谈并成为朋友的人。
如果有人想在技术层面上提供帮助,你会建议他们什么?
只要开始,理解Joomla并不太难。它遵循常见的模式,并试图让开发人员更容易理解。
你为什么参与了这么多团队?你是如何管理这些的?
无法拒绝?我的意思是,我是发布领导者,这会自动让你加入三个团队。除此之外,我还是生产部门协调员,这会让你加入另一个100个团队频道……但基本上,如果你不拒绝,你将被吸纳入Joomla的每个团队。
当谈到新发布时,人们最大的误解是什么?
人们认为一切都很明显,但实际上找到帮助创建一个稳固和稳定的发布的人真的很困难。有时很难找到测试发布候选人的测试人员。幸运的是,Philip Walton在建立发布团队方面做了很好的工作。我从扩展开发者那里从未收到过关于在即将发布的版本上测试他们自己的扩展的反馈。
作为Joomler,我们可以做些什么来使发布领导者的工作更容易?
在发布网站上测试发布候选人和pull请求。
那么,什么让它变得更难?
对推迟的功能进行抱怨,这些功能可能不适合发布。
为了使Joomla为未来做好准备,需要什么?
志愿者们,这真的很简单,我们需要各个领域具备所有技能的人才。当然,我会说我们需要开发者,但我认为更重要的是一个有效的营销团队和筹款人员。
我想对Luca说声谢谢,因为你作为秘书的职位上做得非常出色。我认为没有你,Joomla将会完全不同,而且不会是好事。还有两个人我想感谢他们投入在Joomla和我身上的时间。第一个是George Wilson,他非常聪明,努力让J4发布出来,当然还有那个戴黑色棒球帽的Benjamin Trenkle,没有他,我无法管理我在Joomla上的所有活动!
在Joomla社区杂志上发表的一些文章代表了作者对特定主题的个人观点或经验,可能与Joomla项目的官方立场不一致。
通过接受,您将访问 https://magazine.joomla.net.cn/ 外部的第三方提供的服务
评论 1
Joomla的RC发布确实让我们3PDs感到惊讶。我们看不到任何迹象表明RC将会发布,直到我们在一个周四晚上的推文中看到Joomla的推文。即使我们牺牲了周末,我们也只有4天的时间来测试我们的所有软件并报告问题。这是最好的情况,因为考虑到RC的意外性质,我们可能正处于发布周期中,而且没有时间放下一切来测试Joomla。
即使我们测试了Joomla的RC,这又有什么意义?它不包括任何安全修复,在我们看来,这是补丁级别发布中破坏事物的主要原因。即使情况不是这样,我们的经验是,向Joomla报告问题是一场磨难。我们肯定会被告知我们做错了。如果我们设法坚持下去,并且奇迹般地让发布经理看到了问题,Joomla的发布仍然会进行。因此,我们浪费了时间,我们仍然必须解决你引入的问题。我们还会被告知我们应该使用RC进行测试——哦,讽刺啊。
从商业角度来看,什么都不做才是最好的选择。周二发布后,事情可能会出错。我们将在数小时内了解原因,并找出它们为什么会出错。我们将等待一天或两天,看看 Joomla 是否会发布新版本来修复这些问题。如果没有,我们将发布我们软件的新版本,包含针对最新核心错误的解决方案。这样可以避免浪费时间,减少工作量,而且效果和以前一样。
难怪第三方开发者(3PD)懒得测试 RC 版本。在当前的时间框架和实施过程中,测试 RC 版本是一项徒劳无功的挫败感练习。