有几个关于 update-test 的问题想问一下：
1.en.opensuse.org/Portal:Maintenance中提到：after postive feedback by testers of the update-test repository the update gets released into the official main update repository of the particular openSUSE version
那么这个 postive feedback 来自哪些 tester？即 tester 需要满足什么条件？要有多少人的 positive feedback 才能推到主更新源？有没有需要等够多少天才能推主更新源的规定？
2. 有 negative feedback 如何处理？
3.feedback 是否都在相应的 bugzilla 里？在 opensuse-updates 和 opensuse-testing mailling list 里我找不到什么反馈。
4. 假如 bnc 里没有没有 bug report，但上游放出了一个小版本修复升级，那么 openSUSE 会不会升级？（我以前认为是不会的，但看了这个后就不敢肯定了，见 https://bugzilla.novell.com/show_bug.cgi?id=850445，这个 syslog-ng 升级推得有点像 fedora 的风格）
5.update-testing 里的一些包在版本号不变的情况下为什么修改时间会有改变？
openSUSE 维护更新的流程简单说就是设计成这样：
汇报 bug → 在 bugzilla 上讨论 → 确认故障 → CC 发行版维护团队的人来看需不需要维护更新 → 软件包维护者准备维护更新 → 故障提交人测试 → 维护团队同意，进入官方 Update 源并推送。
实际上因为有方便好用的 OBS 的存在更多的是这样：
汇报 bug → 在 bugzilla 上讨论 → 确认故障，软件包维护者去 branch 那个包并提供修复 → 故障提交人测试那个 branch → 软件包维护者准备正式的维护更新并提交 → 维护团队看看 changelog 没什么大问题，同意，进入官方 Update 源并推送。
它说的 update-test 源可能是指这种：
build.opensuse.org/project/show/home:MargueriteSu:branches:OBS_Maintained:gcin
它距离进入 Update 源只差一个「维护团队同意」。但更多的是这样的：
build.opensuse.org/project/show/home:sumski:bnc851987
tester 是故障提交者和在 bug report 里声明这个 bug 也影响他了的人。条件自然是能复现 bug。全部，但多数时候 bug report 只是提交人和修复人的双方互动。没有。
继续修，update-test 作废。但实际中都是继续更新那个源。
当然。
可以升级，看软件包维护者愿意不愿意。但必须只能是没有添加任何新功能的故障修复版。比如你 4.2.4 的 fcitx 只能升级到 4.2.4.1，升级到 4.2.8 的确也修复了那些 bug，但是是不可以的。
没看懂。因为我们没有名为 update-testing 的源，我在 build.opensuse.org/search 没找到。
总之，我们的维护更新策略比较「人治」，相信软件包维护者的能力而不是维护团队的能力，维护团队的能力主要体现在安全更新的专业性上面而不是一把抓，不像 Fedora 那么蛋疼。
抱歉，写错了，我是说类似 update/13.1-test 这些源，我明白修改日期变动的原因了，估计是做什么 rebuild 吧。