Improve Repositories

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的存在，开发者不会去思考如何在稳定性上进行快速迭代．转而将本该承担的责任转嫁到测试人员身上．