在一个很久以前 Fedora 核心 1 至 Fedora 核心 3，更新是通过手动过程处理的，涉及到发布工程的电子邮件。 从…开始 Fedora Core 4，一个仅供红帽员工使用的私有内部更新系统。
现代菩提世界始于 Fedora 7同时， Fedora 核心和 Fedora 演员被合并。 它引入了 Karma 的概念，它是用 TurboGears 1.x 编写的，并且在七年之后的许多次修订后的今天仍在生产中。
菩提在幕后做了很多事情，既极其复杂，又非常低效。 Luke 描述了这些年来出现的许多问题，包括不灵活的 SQL 例程和已经过时的业力过程。
菩提更新系统的作者和维护者 Luke Macken 在 2014 年的 Flock 演讲中谈到了 Fedora 更新过程。 他花了一点时间告诉我们这些年来出现的一些更有趣的故障，包括臭名昭著的 Fedora 9 GPG 重新键入并在更新推送期间发生多次崩溃。
之后，他开始讨论 Bodhi2 项目的计划。 计划是让它在之后的某个时间着陆 Fedora 21日发布。 我们不想依赖它来进行零日更新，但我们会在不久之后逐步引入它，希望它应该是一个优雅的过渡。
Bodhi2 的一些主要变化将是一个全面的 REST API、一个新的和改进的命令行工具以及对 UI 的重大变化，这些变化应该为用户提供更好的体验。
Bodhi2 的另一大特点是它将与 fedmsg 和新的 Fedora 消息服务，以减少 Bodhi 发出的“垃圾邮件”电子邮件的数量。 Luke 深入探讨了支持通知服务的 datagrepper 和 datanommer 挖掘工具以及您可以选择的过滤器集。
Luke 展示了 Bodhi2 将如何与 Taskotron 紧密集成以执行更新的自动化测试，以及与 Fedora 徽章（有很多可用于 Bodhi！），然后进入反馈系统。 他调用了 fedora-easy-karma 命令行工具和 fedora-gooey-karma GUI 工具来管理 Bodhi1 上的 karma 更新（并指出它们也将共同支持 Bodhi2）。
然后他离开了，让我对新的提交者流程束手无策，几乎所有事情都实现了自动化，并让它变得几乎令人难以置信的简单。 除此之外，新的业力系统允许提交者选择细粒度的业力控制，因此他们可以要求特定测试必须通过业力才能将其接受到稳定的存储库中。
演讲结束时对未来进行了一些预测，特别是谈到能够运行 AMI 和其他云映像更新。
