【Hacker News搬运】我们正在分叉Flutter

hackernews

Title: We're forking Flutter

我们正在分叉Flutter

Text:

Url: https://flutterfoundation.dev/blog/posts/we-are-forking-flutter-this-is-why/

由于我无法直接访问外部链接，我将根据您提供的标题和一般信息来创建一个模拟的总结。以下是对Flutter Foundation博客文章《We Are Forking Flutter – This Is Why》（我们正在分支Flutter——这是为什么）的总结：

---

**文章标题：我们正在分支Flutter——这是为什么**

**总结：**

Flutter Foundation宣布了一个重要的决定：分支Flutter框架。这一决定背后的原因是多方面的，旨在确保Flutter社区的未来发展，同时保持其创新和灵活性。

**以下是分支Flutter的几个主要原因：**

1. **社区需求与贡献：** Flutter社区庞大且活跃，但有时在贡献过程中可能会出现一些分歧。分支Flutter将允许不同的团队或组织根据自己的需求调整框架，同时仍保持与主分支的兼容性。

2. **技术创新：** 分支Flutter可以为特定社区或项目提供试验新特性的机会，这些特性可能在未来被整合回主分支。这有助于推动Flutter技术的持续进步。

3. **定制化需求：** 某些组织可能需要针对特定行业或用例进行定制化的Flutter实现。分支框架可以满足这些定制化需求，同时不影响其他用户。

4. **长期维护：** 分支Flutter可以确保即使主要框架不再活跃，社区中的某些分支仍然可以获得维护和支持。

**文章还可能包含以下内容：**

- 对Flutter当前状态的概述，包括其社区和生态系统的增长。
- 分支过程的具体细节，包括如何进行分支、如何保持与主分支的同步以及如何合并改进。
- 对Flutter Foundation和社区成员的感谢，他们的努力使这一决定成为可能。

通过分支Flutter，Flutter Foundation和社区成员都希望确保Flutter的未来是开放、包容且充满活力的。

---

请注意，以上总结是基于文章标题的一般性推测，实际文章可能包含更多具体细节和背景信息。

Post by: alexzeitler

Comments:

1st1: > How large is the Flutter team, today? Google doesn't publish this information, but my guess is that the team is about 50 people strong.> That's 50 people serving the needs of 1,000,000. Doing a little bit of division, that means that every single member of the Flutter team is responsible for the needs of 20,000 Flutter developers! That ratio is clearly unworkable for any semblance of customer support.This is a weird exercise. Python, for example, is a #1/#2 language in the world and there's only 50 active core devs, 90% of which don't even work on Python full time. Somehow we make that work.

1st1: &gt；Flutter团队今天有多大？谷歌没有；我不会公布这些信息，但我猜这个团队大约有50人 &gt；那；50人满足100万人的需求。做一点划分，这意味着Flutter团队的每个成员都要负责20000名Flutter开发人员的需求！对于任何形式的客户支持来说，这个比率显然都是不可行的 这是一个奇怪的练习。例如，Python是排名第一的语言#世界上有两种语言；只有50名活跃的核心开发人员，其中90%没有；我甚至没有全职使用Python。不知何故，我们做到了这一点。

divan: > We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter.That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post.The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replacement (just configuring FVM - Flutter Version Manager):<pre><code> Configure .fvmrc to use Flock:
{
"flutter": "master",
"flutterUrl": "https://github.com/Flutter-Foundation/flutter.git"
}

</code></pre>
Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell. And the frustration described in the post is felt by many CTOs and developers. Especially those who use Flutter for desktop and web. Flutter provides an amazing experience for desktop apps, and precisely because of that, it feels so frustrating when you stumble upon some stupid bug that has been open for a year or two and never gets prioritized. Usually, it's nothing critical, but still requires workarounds and wasting time.I don't know, the idea of Flock sounds good, the main question is engaging the community. Hopefully, the author (who seem to be an ex-Flutter team member himself) have a good grasp on the state of the community.Wishing luck to the project and going to keep an eye on the progress.

divan: &gt；我们将Flock描述为&quot；Flutter+”；。换句话说，我们不想也不打算分叉Flutter社区。Flock将不断更新Flutter 当我看到标题分裂的社区和两个不兼容的版本时，这是我第一次担心。很高兴看到它在邮件中被提及 第二个只是担心它会使开发过程复杂化，但它似乎是一个直接的替代品（只是配置FVM-Flutter版本管理器）：<pre><code>Configure.fvmrc使用Flock：{&“；“颤动”：&“；“大师”；，&“；flutterUrl”：&“；https:&#x2F；github.com；Flutter基金会；flutter.git”；}</code></pre>Flutter是自Qt以来UI开发中发生的最好的事情。大多数人不会；我不知道他们每天使用多少用Flutter编写的应用程序，仅仅是因为它；这不可能说出来。许多CTO和开发人员都感受到了这篇文章中描述的沮丧。尤其是那些在桌面和网络上使用Flutter的人。Flutter为桌面应用程序提供了一种惊人的体验，正因为如此，当你偶然发现一些已经打开一两年但从未被优先考虑的愚蠢错误时，你会感到非常沮丧。通常，它；这并不重要，但仍然需要变通方法和浪费时间 我不知道；我不知道，Flock的想法听起来不错，主要问题是吸引社区。希望作者（他自己似乎也是Flutter团队的前成员）能够很好地掌握社区的状况 祝项目顺利，并密切关注进展。

skybrian: Back when I worked on GWT, we had trouble accepting outside contributions because the team had a mandate to support Googlers. That is, much like other libraries and tools at Google, changes could not break google3. This means testing patches against google3 and either changing the patch, or fixing whatever code used it, and these are tasks that no outsider can do.Shepherding these patches is no fun when you have your own changes to work on that are more important to the team.We did something similar, by creating an external fork where changes could be tried out by the community, without necessarily being accepted into the internal version.I think a fork could work if there was enough external momentum, but even 20 people working full time would actually be pretty good for an open source project. How many developers will this fork attract? The fork would need to attract other businesses who can put people on it.One downside is that the code isn't tested against google3. Sometimes you find actual bugs that way.Edit: reading more closely, the complaint doesn't seem to be that patches weren't reviewed, but rather that bug reports weren't investigated. That's definitely something outside developers could do more of, and seems a lot easier than forking?

skybrian: 当我在GWT工作时，我们很难接受外部贡献，因为团队有支持谷歌员工的任务。也就是说，就像谷歌的其他库和工具一样，变化不会破坏谷歌3。这意味着在google3上测试补丁，或者更改补丁，或者修复使用它的任何代码，这些都是外人无法完成的任务。当你有自己的更改要做，而这些更改对团队更重要时，管理这些补丁并不有趣 我们做了类似的事情，通过创建一个外部分支，社区可以尝试进行更改，而不一定被内部版本接受 我认为如果有足够的外部动力，一个fork可以工作，但即使是20个人全职工作，对于一个开源项目来说也相当不错。这个分叉会吸引多少开发者？分叉需要吸引其他可以把人放在上面的企业。一个缺点是代码不是；t对谷歌进行了测试。有时你会发现实际的bug 编辑：仔细阅读，投诉没有；似乎补丁不是；没有审查，而是错误报告没有审查；t调查。那；这肯定是外部开发人员可以做得更多的事情，而且似乎比分叉容易得多？

plorkyeran: > That's 50 people serving the needs of 1,000,000. Doing a little bit of division, that means that every single member of the Flutter team is responsible for the needs of 20,000 Flutter developers! That ratio is clearly unworkable for any semblance of customer support.If "only" 50 people working on a project used by one million people was unworkably low then every single successful project out there would be doomed. I've certainly worked on things with much worse ratios than that.> one has to critically assess why a team that loves external contributions has only managed to merge contributions from 1,500 developers over a span of nearly a decade.External contributions from 1500 developers over a decade is a lot. That is an unusually high number, not a low one, and backs up Flutter's claim to love external contributions.The fact that this person thinks that they can just magically conjure up dozens of volunteer PR reviewers is wild. Everything about this post makes it pretty clear that they don't have the slightest clue of the scope of what they're trying to do. This feels like one of the standard examples of an ex-bigco person setting off on their own with no understanding how just how much the bigco did in the background to facilitate their job.

plorkyeran: &gt；那；50人满足100万人的需求。做一点划分，这意味着Flutter团队的每个成员都要负责20000名Flutter开发人员的需求！对于任何形式的客户支持来说，这个比率显然都是不可行的 如果&quot；只有&quot；50个人在一个100万人使用的项目上工作，这个数字低得令人难以置信，那么每一个成功的项目都注定要失败。我；我确实在做比这更糟糕的事情 &gt；人们必须批判性地评估为什么一个喜欢外部贡献的团队在近十年的时间里只设法合并了1500名开发人员的贡献 十年来，1500名开发人员的外部贡献很大。这是一个异常高的数字，而不是低的数字，并且支持Flutter；他声称喜欢外部贡献 事实上，这个人认为他们可以神奇地召唤出几十名志愿公关评论员，这太疯狂了。关于这篇文章的一切都清楚地表明，他们没有；对它们的范围一无所知；我们正在努力做到这一点。这感觉就像一个前大公司员工独自出发的标准例子，他们不知道大公司在幕后做了多少工作来促进他们的工作。

stux: <a href="https://github.com/flutter/flutter/pulls?q=is%3Apr+author%3Amatthew-carroll">https://github.com/flutter/flutter/pulls?q=is%3Apr+author%3A...</a>- 0 open PRs- 2 PRs merged, 1 PR closed in the past 4 years- All PRs reviewed by a member of the Flutter team within 24hrs- [“If I'm still supposed to write tests, even for this change, then this is probably as far as I take the PR.”](<a href="https://github.com/flutter/flutter/pull/128910#issuecomment-1592088473">https://github.com/flutter/flutter/pull/128910#issuecomment-...</a>)- 40+ PRs from 2019So, disgruntled ex-employee?

stux: <a href=“https:&#x2F；/ github.com&#x2F-flutter&#x2F/flutter&quot；pulls？q=是%3Apr+作者%3Amatthew carroll”>https:&quot&#x2F；github.com；颤振；颤振；拉？q=是%3Apr+作者%3A</a> -0个打开的PR-2个合并的PR，1个关闭的PR在过去4年-Flutter团队成员在24小时内审查的所有PR-[“如果我仍然应该编写测试，即使是为了这个更改，那么这可能是我接受PR的范围。”]#x2F；github.com#x2F，Flutter&x2F，fletter&#x2F”，pull&#x291；issues comment-…</a>）-2019年以来的40多个PR那么，心怀不满的前员工呢？