How to play with OpenWrt?How to play with OpenWrt?
首页
  • 简介
  • 选择OP
  • 分裂之争
  • 路由系统
  • 路由概念
  • 路由模式
  • 进阶指南
  • 前言
  • 准备
  • ESXI
  • iKuai
  • OpenWrt
  • 群晖DSM
  • OpenWrt

    • 磁盘扩容
    • 主题安装
    • SmartDNS
    • AdGuardHome
    • OpenClash
    • DNS防泄漏
    • 远程唤醒
    • iStore
    • 固件编译
  • iKuai

    • MAC修复
    • 单线多拨
  • Synology NAS

    • 版本更新
    • 修复CPU显示
  • 通用

    • 全局DNS
    • IPv6 DDNS
    • 开启HTTPS
声明
首页
  • 简介
  • 选择OP
  • 分裂之争
  • 路由系统
  • 路由概念
  • 路由模式
  • 进阶指南
  • 前言
  • 准备
  • ESXI
  • iKuai
  • OpenWrt
  • 群晖DSM
  • OpenWrt

    • 磁盘扩容
    • 主题安装
    • SmartDNS
    • AdGuardHome
    • OpenClash
    • DNS防泄漏
    • 远程唤醒
    • iStore
    • 固件编译
  • iKuai

    • MAC修复
    • 单线多拨
  • Synology NAS

    • 版本更新
    • 修复CPU显示
  • 通用

    • 全局DNS
    • IPv6 DDNS
    • 开启HTTPS
声明
  • 分裂之争

OpenWrt和LEDE的分裂之争

事件

OpenWrt项目可能是最广为人知的基于Linux的家庭WiFi路由器和接入点发行版;它是从现在著名的Linksys WRT54G路由器的源代码中产生的,超过12年前。五月初,当一群核心OpenWrt开发人员宣布他们正在开始OpenWrt的分拆(或者,也许是一个分支)时,OpenWrt用户社区陷入了相当多的混乱,命名为Linux嵌入式开发环境(LEDE)。公众并不完全清楚为什么会发生分裂 - LEDE的公告令其他一些OpenWrt开发人员感到惊讶的事实表明团队内部存在麻烦。

LEDE公告于5月3日由Jo-Philipp Wich发送到OpenWrt开发列表和新的LEDE开发列表。它将LEDE描述为“OpenWrt社区的重启”和“OpenWrt项目的衍生产品”,旨在创建一个嵌入式Linux开发社区,“重点关注透明度,协作和去中心化”。

重启的理由是,OpenWrt遭受了长期存在的问题,这些问题无法从内部解决,即内部流程和政策。例如,公告称,开发人员的数量处于历史最低水平,但没有新开发人员入职的流程(而且似乎没有向新开发人员授予提交访问权限的流程)。公告称,该项目基础设施不可靠(显然,过去一年的服务器中断在项目内引起了相当大的冲突),但内部分歧和单点故障阻止了修复它。内部以及从项目到外部世界也普遍缺乏“沟通、透明度和协调”。最后,提到了一些技术缺陷:测试不足,缺乏定期构建以及稳定性和文档性差。

该公告继续描述了LEDE重启将如何解决这些问题。所有沟通渠道将可供公众使用,决策将通过项目范围的投票做出,合并政策将更加宽松,等等。有关新项目政策的更详细说明,请参见LEDE网站的规则页面。除其他细节外,它还表示将只有一类提交者(即没有具有额外权限的“核心开发人员”组),简单多数票将解决决策,并且由项目管理的任何基础设施必须至少有三个具有管理访问权限的操作员。在LEDE邮件列表中,Hauke Mehrtens补充说,该项目将努力将补丁发送到上游 - OpenWrt过去一直受到批评,特别是在内核方面。

除了Wich之外,OpenWrt的贡献者John Crispin,Daniel Golle,Felix Fietkau,Mehrtens,Matthias Schiffer和Steven Barth也共同签署了该公告。最后,邀请其他有兴趣参与的人参观LEDE网站。

反应和问题

有人可能会认为,LEDE的组织者希望他们的宣布会遇到一些积极和消极的反应。毕竟,仔细阅读公告中对OpenWrt项目的批评表明,有一些OpenWrt项目成员发现LEDE阵营难以合作(例如,阻止基础设施修复的“单点故障”或“内部分歧”)。

而且,确实有负面的反应。OpenWrt联合创始人迈克·贝克(Mike Baker)对此表示震惊,不同意LEDE公告的所有结论,并表示“诸如'重启'之类的短语既模糊又具有误导性,LEDE项目未能确定其真实性质。大约在同一时间,有人禁用了签署LEDE公告的开发人员的@OpenWrt.org 电子邮件别名;当Fietkau反对时,Baker回答说这些帐户“暂时被禁用”,因为“目前还不清楚LEDE是否仍然代表OpenWrt”。另一位OpenWrt核心成员Imre Kaloz写道,“LEDE团队在OpenWrt中创造了大部分破碎的现状”,现在它正在抱怨。

但OpenWrt列表中的大多数回复都对这一公告表示困惑。名单成员不清楚LEDE团队是否会继续为OpenWrt做出贡献,也不清楚导致分裂的基础设施和内部问题的确切性质是什么。Baker最初的回应对公告中提到的问题缺乏公开辩论表示遗憾:“我们认识到当前的OpenWrt项目存在许多问题”,但“我们希望我们有机会讨论并尝试解决”这些问题。贝克总结道:

We would like to stress that we do want to have an open discussion and resolve matters at hand. Our goal is to work with all parties who can and want to contribute to OpenWrt, including the LEDE team. 我们要强调,我们确实希望进行公开讨论并解决手头的问题。我们的目标是与所有能够并希望为OpenWrt做出贡献的各方合作,包括LEDE团队。

除了对新项目基本原理的质疑之外,一些列表订阅者对LEDE是否针对与OpenWrt相同的用例表示困惑,因为新项目的名称听起来更通用。此外,许多人,如Roman Yeryomin,对为什么这些问题需要LEDE团队离开表示困惑,特别是考虑到LEDE小组共同构成了活跃的核心OpenWrt开发人员的大多数。一些列表订阅者,如Michael Richardson,甚至不清楚谁仍将开发OpenWrt。

澄清

LEDE团队做了一些尝试来进一步澄清他们的立场。在Fietkau对Baker的回复中,他说OpenWrt项目中关于拟议更改的讨论往往会很快变得“有毒”,因此没有进展。此外:

A critical part of many of these debates was the fact that people who were controlling critical pieces of the infrastructure flat out refused to allow other people to step up and help, even in the face of being unable to deal with important issues themselves in a timely manner. 许多这些辩论的一个关键部分是,那些完全控制基础设施关键部分的人拒绝让其他人站出来提供帮助,即使面对无法及时处理重要问题的情况也是如此。

This kind of single-point-of-failure thing has been going on for years, with no significant progress on resolving it. 这种单点故障的事情已经持续了多年,在解决它方面没有重大进展。

Wich和Fietkau都没有指责特定的个人,尽管名单上的其他人似乎认为OpenWrt的基础设施和内部决策问题归结为少数人。丹尼尔·迪金森(Daniel Dickinson)表示:

My impression is that Kaloz (at least) holds infrastructure hostage to maintain control, and that the fundamental problem here is that OpenWrt is not democratic and ignores what people who were ones visibly working on OpenWrt want and overrides their wishes because he/they has/have the keys. 我的印象是,Kaloz(至少)将基础设施作为人质以维持控制,这里的根本问题是OpenWrt不民主,并且忽略了那些明显从事OpenWrt工作的人想要什么,并凌驾于他们的愿望之上,因为他/他们拥有/拥有钥匙。

另一方面,Luka Perkov反驳说,许多OpenWrt开发人员希望从Subversion切换到Git,但Fietkau负责阻止这一变化。

似乎很清楚的是,OpenWrt项目一直在一个没有按预期运作的治理结构下运作,结果,个性冲突正在爆发,个人能够破坏或阻止提议的变更仅仅因为没有明确定义的流程。显然,从长远来看,这不是一个行之有效的模式。

5月6日,克里斯平在一个新的帖子中写信给OpenWrt列表,试图重新构建LEDE项目公告。他说,这并不是一种“敌对或破坏性”的行为,而是要彻底摆脱OpenWrt的功能失调结构,重新开始。他说,这件事“不会归结为一个单一的事件,一个人或一个单一的火焰战争”。“我们想与过去自己犯的错误以及有时做出的错误管理决策分开。克里斯平还承认,这一宣布没有得到很好的处理,称LEDE团队“搞砸了发射的政治”。

Crispin的电子邮件似乎并没有让Kaloz满意,他坚持认为Crispin(作为发布经理)和Fietkau(作为首席开发人员)可以在OpenWrt项目中做出任何理想的改变。但讨论线程随后陷入沉默;无论LEDE还是OpenWrt方面接下来发生什么,还有待观察。

意图

对于那些仍在寻求有关LEDE团队认为OpenWrt中存在问题的进一步细节的人来说,还有一个信息来源可以阐明这些问题。在公开宣布之前,LEDE组织者花了几周时间讨论他们的计划,IRC的会议日志现在已经发布。特别令人感兴趣的是3月30日的会议,其中包括对项目目标的详细讨论。

其中包括对OpenWrt基础设施的几个具体抱怨,例如该项目的Trac问题跟踪器的缺点。Wich说,它被不完整的错误报告和“我也是”的评论所淹没,因此,很少有提交者使用它。此外,人们似乎对GitHub上也跟踪错误的事实感到困惑,因此不清楚应该在哪里讨论问题。

IRC的讨论也涉及开发过程本身。LEDE团队希望实现一些更改,首先是使用在正式合并窗口期间合并到主干中的暂存树,而不是OpenWrt采用的直接提交到主数据库的方法。该项目还将致力于基于时间的发布,并鼓励用户测试,只发布由社区而不是核心开发人员在实际硬件上成功测试的二进制模块。

最后,IRC的讨论确实清楚地表明,LEDE团队的意图并不是让OpenWrt的宣布感到惊讶。克里斯平建议LEDE首先是“半公开的”,然后逐渐变得更加公开。Wich指出,他希望LEDE是“中立,专业和欢迎OpenWrt,为未来的重新整合敞开大门”。发射在这方面似乎并不顺利,这是不幸的。

在一封电子邮件中,Fietkau补充说,OpenWrt的核心开发人员在补丁审查和维护工作等任务上一直受到瓶颈的困扰,这些瓶颈阻止了他们完成其他工作,例如设置下载镜像或改进构建系统。他说,在LEDE宣布后的头几天,该团队就设法解决了镜像和构建系统的任务,这些任务已经萎靡了多年。

A lot of what we did in LEDE was based on the experience with decentralizing the development of packages by moving it to GitHub and giving up a lot of control over how packages should be maintained. This ended up reducing our workload significantly and we got quite a few more active developers this way. 我们在LEDE中所做的很多事情都是基于通过将软件包移动到GitHub来分散软件包开发的经验,并放弃了对软件包维护方式的大量控制。这最终大大减少了我们的工作量,通过这种方式,我们得到了相当多的活跃开发人员。

We really wanted to do something similar with the core development, but based on our experience with trying to make bigger changes we felt that we couldn't do this from within the OpenWrt project. 我们真的很想在核心开发方面做类似的事情,但根据我们尝试进行更大更改的经验,我们认为我们无法在OpenWrt项目中做到这一点。

他说,修复基础设施也将获得其他红利,例如改进用于管理用于签署版本的密钥的系统。该团队正在考虑一项规则,对非上游补丁施加一些条件,例如要求对补丁进行描述并解释为什么尚未将其发送到上游。他还指出,许多剩余的OpenWrt开发人员都表示有兴趣加入LEDE,相关各方正试图弄清楚他们是否会重新合并这些项目。

人们希望LEDE扁平化的治理模式和对更高透明度的承诺将有助于它在OpenWrt陷入困境的领域取得成功。目前,理清困扰最初公告的沟通问题可能被证明是一个主要障碍。不过,如果这个过程进展顺利,LEDE和OpenWrt可能会在未来找到共同点并合作。如果没有,那么这两个团队可能被迫以比以前更少的资源前进,这可能不是开发人员或用户希望看到的。

详情

原文链接:LEDE and OpenWrt

在经过一系列事情之后,迎来了OpenWrt社区的重启 A reboot of the OpenWrt community。

In 2016, the LEDE project was founded as a spin-off of the OpenWrt project and shared many of the same goals. The project aimed at building an embedded Linux distribution that makes it easy for developers, system administrators or other Linux enthusiasts to build and customize software for embedded devices, especially wireless routers. The name LEDE stood for Linux Embedded Development Environment.

2016年,LEDE项目作为OpenWrt项目的衍生产品成立,并拥有许多相同的目标。该项目旨在构建一个嵌入式Linux发行版,使开发人员,系统管理员或其他Linux爱好者可以轻松地为嵌入式设备(尤其是无线路由器)构建和定制软件。LEDE这个名字代表Linux嵌入式开发环境。

Members of the project included a significant share of the most active members of the OpenWrt community and intended to bring new life to Embedded Linux development by creating a community with a strong focus on transparency, collaboration and decentralisation.

该项目的成员包括OpenWrt社区中最活跃的成员的很大一部分,并打算通过创建一个非常注重透明度,协作和去中心化的社区,为嵌入式Linux开发带来新的活力。

LEDE’s stated goals were:

LEDE的既定目标是:

  • Build a great embedded Linux distribution with focus on stability and functionality. 构建一个出色的嵌入式 Linux 发行版,专注于稳定性和功能性。

  • Make regular, predictable release cycles coupled with community provided device testing feedback. 制定定期、可预测的发布周期,并结合社区提供的设备测试反馈。

  • Establish transparent decision processes with broad community participation and public meetings. 建立透明的决策流程,让社区广泛参与和公开会议。

The formation of the LEDE project was decided to solve long standing issues that were deemed unfixable from within the OpenWrt project/community:

LEDE项目的成立是为了解决OpenWrt项目/社区内部长期存在的问题:

  1. Number of active core developers at an all time low, no process for getting more new people involved. 活跃的核心开发人员数量处于历史最低水平,没有让更多新人参与的过程。

  2. Unreliable infrastructure, fixes prevented by internal disagreements and single points of failure. 不可靠的基础架构,内部分歧和单点故障阻止的修复。

  3. Lack of communication, transparency and coordination in the OpenWrt project, both inside the core team and between the core team and the rest of the community. OpenWrt项目缺乏沟通,透明度和协调,无论是在核心团队内部还是核心团队与社区其他成员之间。

  4. Not enough people with commit access to handle the incoming flow of patches, too little attention to testing and regular builds. 没有足够的具有提交访问权限的人员来处理传入的补丁流,对测试和常规构建的关注太少。

  5. Lack of focus on stability and documentation. 缺乏对稳定性和文档的关注。

To address these issues, the LEDE project was set up in a different way compared to OpenWrt:

为了解决这些问题,LEDE项目的建立方式与OpenWrt不同:

  1. All communication channels are public, some read-only to non-members to maintain a good signal-to-noise ratio. 所有通信渠道都是公开的,有些对非成员只读,以保持良好的信噪比。

  2. Decision making process is more open, with an approximate 50/50 mix of developers and power users with voting rights. 决策过程更加开放,拥有投票权的开发人员和高级用户的比例约为 50/50。

  3. Infrastructure is simplified a lot, to ensure that it creates less maintenance work for us. 基础设施大大简化,以确保它为我们创造更少的维护工作。

  4. More liberal merge policy, based on our experience with the OpenWrt package github feed. 更自由的合并策略,基于我们对OpenWrt包github提要的经验。

  5. Strong focus on automated testing combined with a simplified release process. 专注于自动化测试与简化的发布流程相结合。

Announcing the OpenWrt/LEDE merge 宣布OpenWrt/LEDE合并

As of January 2018, both the OpenWrt and LEDE projects agreed to re-merge back under the OpenWrt name.

截至2018年1月,OpenWrt和LEDE项目都同意以OpenWrt的名称重新合并。

The new, unified OpenWrt project is governed under the rules established by the former LEDE project. Active members of both the former LEDE and OpenWrt projects contribute to the unified OpenWrt.

新的,统一的OpenWrt项目受前LEDE项目制定的规则管辖。前LEDE和OpenWrt项目的活跃成员都为统一的OpenWrt做出了贡献。

Joint future 共同的未来

LEDE's fork and subsequent re-merge into OpenWrt did not alter the overall technical direction taken by the unified project. OpenWrt will continue to work on improving stability and release maintenance while aiming for frequent minor releases to address critical bugs and security issues like LEDE did with the 17.01 series and its multiple point releases until now.

LEDE的分支和随后重新合并到OpenWrt并没有改变统一项目采取的整体技术方向。OpenWrt将继续致力于提高稳定性和版本维护,同时旨在频繁发布次要版本,以解决关键错误和安全问题,就像LEDE对17.01系列及其多点版本所做的那样。

Old pre-15.05 OpenWrt CC releases are not supported by the merged project anymore, leaving them without any future security or bug fixes. The OpenWrt CC 15.05 release series did receive a limited amount of security and bug fixes, but due to its lacking integration in the release automation, no further binary image releases were made.

合并的项目不再支持旧的15.05之前的OpenWrt CC版本,使它们没有任何未来的安全性或错误修复。OpenWrt CC 15.05 发布系列确实获得了有限数量的安全性和错误修复,但由于它缺乏与发布自动化的集成,因此没有进一步发布二进制映像。

The merged project uses the code base of the former LEDE project. OpenWrt specific patches not present in the LEDE repository but meeting LEDEs code quality requirements got integrated into the new tree while the source code has been moved to git.OpenWrt.org with a continuously synchronized mirror hosted at Github. The original OpenWrt codebase has been archived on Github for future reference.

合并后的项目使用前LEDE项目的代码库。LEDE存储库中不存在但符合LEDE代码质量要求的OpenWrt特定补丁被集成到新树中,而源代码已通过Github上托管的持续同步镜像移动到 git.OpenWrt.org。原始的OpenWrt代码库已存档在Github上以供将来参考。

The remerged OpenWrt project is legally represented by the Software in the Public Interest (SPI) - an US 501(c)(3) non-profit organization which is managing our OpenWrt trademark, handling our donations and helping us with legal problems.

重新合并的OpenWrt项目由公共利益软件(SPI)合法代表 - 一个美国501(c)(3)非营利组织,管理我们的OpenWrt商标,处理我们的捐赠并帮助我们解决法律问题。

Infrastructure formerly available under the lede-project.org domain has been mostly moved to corresponding OpenWrt.org subdomains and redirects were put in place when appropriate.

以前在 lede-project.org 域下可用的基础设施大多已移至相应的 OpenWrt.org 子域,并在适当时进行了重定向。

现代人的争论

现在争论最多的,应该在于lean’s lede 和 OpenWrt 项目的内核争论最激烈,很早以前的讨论可见一斑。

很长的一段时间内,甚至截至目前,很多人都是将 lean’s lede 作为唯一库使用的。

当然,也有很多不一样的声音,就不举例了。但是,对于整体行业的推进都是不可或缺的。

可以接受现在的OpenWrt,也可以接受lean’s lede,不会冲突。

Life Is About Trouble, So Is Code...
Copyright © 2023 Allen Lu