本文关于开放构建服务的文档已过时！
您可以在 https://github.com/openSUSE/open-build-service/ 上找到最新的信息

未来是开放的

此页面收集了 Open Build Service 开发者以及社区的想法、愿望和经验教训。请勿与 openSUSE:Build_Service_Roadmap 混淆，后者涵盖了短期（更现实）的目标。请理解，这些只是想法，既不是承诺也不是计划中的功能！

被认为值得追求的想法可以被制定成概念并移动到 openSUSE:Build_Service_Concepts wiki 页面。它们然后可能成为未来 Open Build Service 版本的发布目标。但现在，请将此页面视为一个头脑风暴。

架构

合并 Api 和 Webui？

换句话说，从三层架构转变为两层架构。

较少的开发投入
较少缓存问题，减少 XML 的传输
你知道何时清除哪些缓存。
- 参见 bnc#559158
- 更小的（更容易！）代码库
强制执行一致的 API 风格（例如完全 REST）
- 编写测试套件
- 使用 rails 格式处理
  - /project/home:darix/runit(.html) -> html
  - /project/home:darix/runit.json
  - /project/home:darix/runit.xml
迁移到 Rails-3（甚至 Django :-)
- 为每个项目提供可选功能（例如将 redmine 合并到 webui 中）
  - 所有附加功能，如 bug 跟踪、wiki 应该都是可选的
  - 应该能够正确地在每个项目/包的基础上引用外部 wiki/bug 跟踪器。
- 小型 bug 跟踪器/wiki/博客，以便项目可以展示自己

Mimetypes

为通过（未来的）REST API 提供的文件设置正确的 mime 类型。一些当前的（糟糕的）例子

https://api.opensuse.org/build/_workerstatus 返回的是二进制文件而不是 text/xml
bnc#470611

工作流和协作

submitrequest 太过繁重 / 支持太多用例
- 而是使用添加和更新请求
每个请求只有一个操作，以避免当前控制器/视图检查是什么的混乱
工作流引擎 http://ruote.rubyforge.org/
Bug/Tickets/Features 更贴近项目/包？
- 可能像 Redmine 一样，即每个项目/包的票务系统，可以选择委托给中央 / 另一个 bugzilla 实例
- 每个项目/包的 wiki（再次是 redmine）
用户 karma 和统计信息，如打包工作量、wiki 编辑、请求编辑、票据/bug 处理
- 为了激励（满足精英主义），让用户操作可见（Facebook 成瘾）
- +1 用于提交
  - +1 用于 changelog 条目
  - +2 用于成功构建
  - +1 用于提交日志条目，...
- -1 用于未构建的提交
- 需要指标

       1:n           1:n
user ----> roles -----> permissions
             
workflow --> roles
             \-> permissions

- 为所有操作定义明确的使用案例
  - cucumber/rspec 也许？

使用 ruote 处理工作流？ http://www.engineyard.com/blog/2011/ruote-and-flow/

包黑名单！
搜索如果包已经在构建服务中，并提示用户，而不是让他自己构建它 (tm)

审计

后端和前端应该将谁在何时做了什么记录到同一个数据库中，以便能够重现更改

将所有内容都基于模型

这实际上是理所当然的，以下是如果不这样做会发生什么

  def involved_requests(opts = {})
    opts = {:cache => true}.merge opts

    cachekey = "#{login}_involved_requests"
    Rails.cache.delete cachekey unless opts[:cache]

    requests = Rails.cache.fetch(cachekey, :expires_in => 10.minutes) do
      # FIXME: we assume that the user is involved in all his subprojects (home:#{login}:...)
      #        that should not be needed ... verify ...
      iprojects = involved_projects.each.map {|x| x.name}.reject {|x| /^home:#{login}:/.match(x) }.sort
      requests = Array.new
      request_ids = Array.new

      myrequests = Hash.new
      unless iprojects.empty?
        # find active requests where person is maintained in target project
        predicate = iprojects.map {|item| "action/target/@project='#{item}'"}.join(" or ")
        predicate = "#{predicate} or starts-with(action/target/@project, 'home:#{login}:')"
        predicate = "(state/@name='new' or state/@name='review') and (#{predicate})"
        collection = Collection.find :what => :request, :predicate => predicate
        collection.each do |req| myrequests[Integer(req.value :id)] = req end
        # find requests created by person and still active
        collection = Collection.find :what => :request, :predicate => "(state/@name='new' or state/@name='review') and state/@who='#{login}'"
        collection.each do |req| myrequests[Integer(req.value :id)] = req end
        # find requests where person is reviewer
        collection = Collection.find :what => :request, :predicate => "state/@name='review' and review[@by_user='#{login}' and @state='new']"
        collection.each do |req| myrequests[Integer(req.value :id)] = req end
        keys = myrequests.keys().sort {|x,y| y <=> x}
        keys.each do |id| 
          unless request_ids.include? id
            requests << myrequests[id]
            request_ids << id
          end
        end
      end

      # check for all open review tasks
      collection = BsRequest.find_open_review_requests(login)
      collection.each do |req| myrequests[Integer(req.value :id)] = req end
      keys = myrequests.keys().sort {|x,y| y <=> x}
      keys.each do |id| 
        unless request_ids.include? id
          requests << myrequests[id]
          request_ids << id
        end
      end

      requests
    end
    return requests
  end

这部分疯狂的代码实际上试图捕获特定用户参与的所有请求（而且 coolo 说它甚至不完整 / 有 bug）。实际上，这应该只是向模型询问特定 ID 的所有请求......

用户和组

最近，我们获得了对 by_project 和 by_package 审查的支持，这实际上是一种粗糙的解决方法，因为我们没有真正的组概念。新的 OBS 迭代应该为每个新项目和包创建一个组，或者采用现有的组作为所有者。在此基础上，每个用户都应该有一个只包含他自己的组。这样，代码只需要进行组检查，管理就会变得轻而易举。顺便说一下，这是几个主要的 Web 开发框架所证明的有效方法。

每个用户都有一个只包含他的组
每个项目/包/无论什么都是由一个组拥有的
默认情况下，为项目/包/无论什么创建一个新组，或者在创建时使用现有的组

简单的设计，没有黑客手段，没有令人头疼的边缘情况。

Web 前端

将日志记录到 /var/log/obs-frontend 而不是 $RAILS_ROOT/log
服务器端语法高亮显示 / 放弃基于 JavaScript 的语法高亮显示
- 结果应该只在源代码更改 / 首次访问时生成
- 结果应该相应地缓存

模型 / 数据存储

ActiveXML 有点笨拙
- 使用 ActiveModel
- 是否需要围绕 XML 的包装器？
- 也许 JSON 会更好？
  - 如果选择 JSON，CouchDB 可能是存储的好主意？
基于 Git 的存储？
- 每个包一个 Git 仓库？
  - 提交前钩子用于身份验证
  - 提交后钩子用于生成全局统计信息（karma、贡献历史记录）

resources :projects do
  resources :packages do
    resources :history
    resources :roles
    resources :flags
    resources :attributes
  end
  resources :roles
  resources :flags
end

数据库中的全文搜索：https://github.com/Casecommons/pg_search

控制器

认为过于臃肿，真正的逻辑应该只在模型中，而控制器只聚合数据用于呈现

视图

认为过于臃肿，视图不应该包含任何代码（即强制执行 MVC 模式）
- 迁移到不同的模板引擎而不是 ERB / eRuby / erubis
  - 有趣的候选者可能是 Django 模板（Python）或 Mustache、Liquid、Haml
项目、包、监控和状态页面的分页？

志愿者

它们目前过于臃肿，即它们应该只转换数据并且应该很小
- 实际上，它们应该只作为最后的手段使用。
我们有跨多个页面生成大量 HTML 的辅助方法。
- 辅助函数永远不应该生成 HTML！！！（XSS 疯狂）

路由

讨论见 openSUSE:Build_Service_Future_Routing

搜索

讨论见 openSUSE:Build_Service_Future_Searches

授权

拥有 OAuth
拥有 OpenID
使用授权框架，如 https://github.com/stffn/declarative_authorization

后端通信

使用消息队列系统，如 ZeroMQ / ActiveMQ？
- 这可以避免我们配置每个端点，而是广播消息，所有部分都可以挂钩。
- http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes#RabbitMQ
- http://www.igvita.com/2010/11/17/routing-with-ruby-zeromq-devices/
- 所有消息都需要引用带有修订版的数据
  - 我们的存储必须支持版本化数据

国际化 / 本地化

从一开始就整合（gettext 首选，http://www.yotabanana.com/hiki/ruby-gettext.html）
我们必须找出哪些模板引擎支持它（除了 ERB）
JavaScript 在 i18n/l10n 上存在问题
- 避免通过 JavaScript 生成文本，即仅 DOM 操作
- AJAX 查询应该获取服务器端生成的翻译内容
语言可以从用户代理发送的内容中确定（绝不能使用地理位置），并且应该在用户设置中配置为选项

与其他工具的通信

XMLRPC 而不是通过 HTTP 的 XML 文件（参见 py2pack 作为示例）
- 更容易，消除了大量的解析 / 检查代码。
- 更自然，客户端（如 osc）可以直接调用其本机语言中的（远程）函数
- 如何在 Ruby 中实现：http://www.ibm.com/developerworks/opensource/library/os-ws-rubyrails/index.html

后端

迁移到 Perl6 :-D

代码规范

适当的缩进规则（即检查选项卡）
尽可能地明确而不是隐式或自动魔法

ChangeLogs

一个不错的想法是拥有一个 git 提交前钩子，它检查提交消息。如果消息包含一个特殊标签，如“#change”，它可能会将条目添加到（尚未创建的）ChangeLog 文件中，并将此添加到当前的提交中。

Ruby 特有

始终使用 foo() 函数调用语法
使用 lower_case_function_names
在每个函数的末尾添加显式返回语句（即使返回 nil？）
- 提高安全性：函数不会泄露最后一条语句！
- 允许在最后一条语句上设置断点（调试）

Rails Forms

仅使用 form_for 并使用 CSS 设置表单样式
每个表单都有自己的部分！（面向未来，可重用）

Perl 特有

使用注释来解释出色的代码结构！

参见

Open Build Service 路线图和概念页面与此主题密切相关。

归档：构建服务未来

目录