Improve Repositories

cxbii edited this page Jan 22, 2016 · 3 revisions

Deepin 仓库改善方案

背景介绍

仓库完善的目标

  • 提高软件数量 (O1)

    软件就是仓库的灵魂力。优秀软件的数量是仓库质量的一个体现。

  • 减少软件之间的冲突 (O2)

    软件本该是拿来用的,而不是来折腾的。软件冲突虽然在linux上已经被大家 默认可以宽恕的事情了,但作为一个特意进行维护的软件仓库来说,这些问题

 是可以极大的进行改善。

  • 提高查询接口的种类 (O3)
    • 当前仓库有哪些类软件?
    • 是否是应用程序?
    • 是否是驱动程序?
    • 哪些软件几乎就没被下载过?

 没有以上信息虽然也可以勉强的玩下去,但若想建立一套能自我更新的平台,怎么  可以缺少自我认识的机制。 

  • 提高软件本身的质量 (O4)

 软件质量看似无法通过仓库进行改进。但其实不然,仓库可以做两件事情

  1. 进入仓库前的把关。
  2. 剔除低质量的软件。

 这两个简单的方式配合O3(所有人一起反应的结果)从而影响软件本身的质量。

目前Deepin存在的较严重的问题

  • patch的软件被高版本覆盖 (P1)
  • 推送软件到仓库的流程严重依赖于参与人的自觉性 (P2)
  • 上游软件的回归测试不足,经常导致合并上游软件导致仓库整体出现问题 (P3)
  • 仓库出现问题时,完全依赖于有人遇到后进行上报,没有进行自动化检测 (P4)
  • 测试/推送等信息流十分不清晰,整个过程严重依赖于人。(P5)

目前Deepin的仓库说明

软件来源 (TODO:统计每类软件的大概数量)

  • Deepin开发/维护的软件,托管在https://cr.deepin.io 中,并通过pkg_debian 这个项目进行deb配置文件的维护
  • Deepin打过patch的软件, 系统组内部维护。(维护方式不详)
  • debian仓库上游的软件, 

仓库地址说明 (TODO:确认并完善linuxdeepin仓库地址的解释)

ShortName的缩写原则

  • p = public 完全公开的源。正常用户应该只使用此类源。
  • m = p通过m进行同步,一般不被直接使用。
  • t = 由自动化流程自动更新的仓库。 非常不稳定,除测试人员不建议使用。
  • c = 在”自动更新的测试源”与”m”之间起缓冲作用。虽然比t稳定,但仍然不建议QA以外的人员使用。

对外的仓库规划

  • t.e.e 会被分解成数量较多颗粒较小的众多ppa. 产品人员,测试人员,开发人员均可使用少量的几个需要的PPA
  • c 的作用会逐步被自动化机制取代。将c的作用逐步迁移到对应的t中,并通过自动化机制快捷迅速的进行迭代
  • 不再使用2014,2015这类目录名称,统一使用Deepin目录+不同的dist name进行区分。 
  • dsit name不再采用unstable, stable这类功能性的名称(此类功能由t+c进行处理)。 某一时代(一个大版本),只会提供一个仓库。所有体验,测试性质的仓库均通过t进行提供,且不保证t的长期维护。(p会进行长期维护)
ShortName Repository URL Dist Name Description
p.unstable (官方源) http://packages.deepin.com/deepin unstable 官方源,由m.2015.unstable推送
p.cdn.unstable (CDN源) http://cdn.packages.deepin.com/deepin unstable CDN加速源,同步p.unstable
p.trusty (2014源) http://packages.deepin.com/deepin trusty Deepin 2014 trusty基础源。
p.precise (2014源) http://packages.deepin.com/deepin precise Deepin 2014 trusty基础源。
p.precise-updates (2014源) http://packages.deepin.com/deepin precise-updates Deepin 2014 trusty基础源。
c.deepin.stable http://pools.corp.deepin.com/deepin stable 未来的stable基础源。
c.deepin.unstable http://pools.corp.deepin.com/deepin unstable 合并c.*.unstable
c.debian.unstable http://pools.corp.deepin.com/debian unstable 使用apt-mirror工具同步上游Debian更新。
c.maintain.unstable http://pools.corp.deepin.com/maintain unstable 收录开发打了tag之后的包.
c.universe.unstable http://pools.corp.deepin.com/universe unstable 收录第三方软件包。
c.import.unstable http://pools.corp.deepin.com/import unstable 收录搜狗拼音,wps,有道词典等特殊包。
c.autoupdate.unstable http://pools.corp.deepin.com/autoupdate unstable 自动同步更新上游包,如google浏览器。
t.e.e http://pools.corp.deepin.com/experimental experimental https://cr.deepin.io 中最新的代码.(T:需要分解成类似ppa.dstore的形式)
t.ppa.dstore http://pools.corp.deepin.com/ppa/dstore experimental 深度商店ppa仓库,包含最新的深度商店,自动生成
t.deepin.experimental http://pools.corp.deepin.com/deepin experimental 由p.e.e仓库更新而来的experimental基础源。(?:和t.e.e的关系)
t.2014 http://pools.corp.deepin.com/testing/2014 trusty Deepin 2014 的测试仓库。
m.2015.experimental http://mirrors.corp.deepin.com/2015 experimental c.deepin.experimental 的推送缓冲
m.2015.stable http://mirrors.corp.deepin.com/2015 stable c.deepin.stable 的推送缓冲
m.2015.unstable http://mirrors.corp.deepin.com/2015 unstable c.deepin.unstable 的推送缓冲
ubuntu.* http://packages.linuxdeepin.com/ubuntu ? 同步ubuntu仓库。
? http://packages.linuxdeepin.com/debian ? 同步debian仓库。
? http://packages.linuxdeepin.com/deepin-debian ? Deepin 2015 外网源(上面)
? http://packages.linudeepin.com/deepin-server ? Deepin 服务器版仓库
? http://packages.linuxdeepin.com/enterprise ? Deepin 企业版仓库
? http://packages.linuxdeepin.com/loongson ? Deepin 龙芯仓库

仓库自动化平台概要设计

基于已经出现的Pn问题, Deepin 会通过建设一套仓库平台来实现On的这些目标。

因为涉及到的方面较多,所以设计原则有以下几点

  • 不规定流程,只提供机制。比如,不会假设每个两周或多长时间进行一次更新。
  • 尽量从完全公开的角度进行设计。拥抱社区,促进内部成长。

现有问题的解决

问题分析

P1本质在于patch没有进行非常正式的维护。

P2本质在于P5以及缺少自动化的辅助工具,导致大家害怕进行仓库更新测试。从而 潜意识的延后测试。进而累计的不稳定性更大,造成恶性循环。

P3本质在过于依赖上游测试结果,而没有将 Deepin 仓库作为中心来看待。潜意识 的认为 Deepin 的仓库是在上游仓库上添加软件包。从而对上游软件基本是默认放行。

P4本质在于根本没有对仓库的健康程度进行过任何自动检测。完全处在被动解决问题。

P5的本质在于没有及时调整思想, Deepin 现在的规模远超之前,仓库如此重要的方面, 做事方式已经不能再采用个别人员之间简单的进行口头交流。

为了解决以上问题,需要完成以下核心事情

  • 提供查询接口并*自动*维护 Deepin 修改过的所有软件列表。这个列表是自动化的基础。
  • 所有修改均需要对外公开,由外部进行督促检测。由此建立起完善的版本管理。
  • 建立仓库合并的自动测试机制。

On的努力方向

  • 提高软件数量
    1. 连横综合。 一方面迁移优秀的wine,webapp,andorid程序; 一方面从社区,商业方面联系国内外厂商开发/迁移高质量的应用软件。
    2. 制定deb的提交规范。 如针对第三方软件(或 Deepin 维护的外部软件)可以采取, 在对应git根目录下放置特定配置文件进行自动更新。方便开发者的同时也减少了 Deepin 的维护工作。
    3. 自动生成当前仓库的应用信息以及来源 只有知道当前的情况,才会知道如何去改进。
  • 提高查询接口的种类
    1. 加大对仓库信息的使用。
  • 减少软件之间的冲突
    1. 针对官方源进行强制性保障。若出现问题则不进行仓库*合并*(非之前的不推送),直到问题被解决。
    2. 继续非依赖性包格式的研究投入。

第一期改进任务

整理现有仓库种类说明,并提供工具进行切换,从而保障仓库解释的及时性。

 提供工具进行仓库源的切换,并完善该工具的帮助文档。及时的引导大家对仓库的认识,  从而让更多人参与到仓库合理化的建设中。

建立 Deepin 影响过的软件列表。

  • 包括但不限于以下类别
    1. cr.deepin.io
    2. 单独patch过的deb
    3. 上游的软件列表

需要囊括所有 Deepin 修改过的软件,进行合理分类.

t–>c的推送操作全部由非人工接口进行,包括发起,审核,验证。

  • 需要实现的功能点:

 1. 可以自助的发起推送申请  2. 自动进行仓库健康度测试  3. 自动提供明确的测试方式(源切换方面)

  1. 提供人工测试结果汇报工具. 收集当前测试环境的基本信息
  2. 审核通过后,自动进行合并操作.
  • 补充说明:
    1. 此过程中只要有权限任何人均可做任何角色的事情.
    2. 所有步骤需要尽可能的记录上下文信息.
    3. 目前计划通过大量使用jenkins + 少量自助界面来实现.

t.ppa的自助化以及公开化。从而分解不稳定性以及提早暴漏不稳定性。

  • 需要实现的功能点:
    1. 可以通过挑选任意项目(Pn)+特定版本(Vn)进行自助创建/修改/删除ppa.
    2. ppa在设计的时候需要考虑如何服务t–>c,以便两者相互促进完善.
    3. ppa可以选择对外进行公开
  • 针对t.e.e说明(2015开发中的内部experimental源),希望大家理解其造成的危害
    1. 使用者出现问题的时候会或多或少怀疑自己的环境不干净,而不是软件出现问题.
    2. 不同使用者有不同的需求,但强制只能使用experimental导致数不尽的系统崩溃.
    3. 所有的不稳定性集中在t.e.e中,只能通过定期的t.e.e->c进行短期强力度的集中测试.其测试时间过短,测试难道非常大.测试结果让人担忧.
    4. 因为有t.e.e的存在,开发者不会去思考如何在稳定性上进行快速迭代.转而将本该承担的责任转嫁到测试人员身上.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.