Differences between revisions 8 and 9
Revision 8 as of 2005-02-04 05:06:01
Size: 10719
Editor: anonymous
Comment:
Revision 9 as of 2005-02-04 06:21:05
Size: 7721
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 47: Line 47:
[http://hjsos.com/zhuangxiu.html 装修]
[http://hjsos.com/jiaquan.html 甲醛]
[http://hjsos.com/snwr.html 室内污染]
[http://hjsos.com/zxwr.html 装修污染]
[http://hjsos.com 甲醛污染]
[http://www.zy-image.com 摄影学校]
[http://www.ltjz2000.com/beijingsijiazhentan.htm 北京私家侦探]
[http://www.timead.net/zgjs.html 窄告]
[http://www.etoo.cn/jianruishiyou 尖锐湿疣]
[http://www.etoo.cn/jlb 计量泵]
[http://www.etoo.cn/yiliao/gfzbd.htm 高分子绷带]
[http://www.etoo.cn/yiliao/gkqx.htm 骨科器械]
[http://www.etoo.cn/yiliao/gkzrw.htm 骨科植入物]
[http://www.etoo.cn/yiliao/wgdzj.htm 外固定支架]
[http://www.etoo.cn/yiliao/jzcp.htm 脊柱产品]
[http://www.etoo.cn/yiliao/nwgd.htm 内外固定]
[http://www.etoo.cn/yiliao/jkhc.htm 进口耗材]
[http://www.etoo.cn/yiliao/gkhc.htm 骨科耗材]
[http://www.etoo.cn/yiliao/gkqc.htm 骨科器材]
[http://www.etoo.cn/yiliao/ylqx.htm 医疗器械]
[http://www.etoo.cn/yiliao/ylqc.htm 医疗器材]
[http://www.16safe.com/qiche/anquan.htm 轮胎安全]
[http://www.16safe.com/qiche/znjc.htm 智能监测]
[http://www.16safe.com/qiche/luntai.htm 轮胎防爆]
[http://www.16safe.com/qiche/qiche.htm 汽车轮胎]
[http://www.ltjz2000.com/zhentan.htm 私人侦探]
[http://www.ltjz2000.com/sj.htm 私家侦探]
[http://www.ltjz2000.com/xunren.htm 寻人]
[http://www.ltjz2000.com/hydc.htm 婚姻调查]
[http://www.ltjz2000.com/dc.htm 调查]
[http://www.ltjz2000.com/zhentan.htm 侦探]
[http://www.ltjz2000.com/sj.htm 北京私家侦探]
[http://www.ltjz2000.com/dc.htm 调查公司]
[http://www.etoo.cn/zhaigao 窄告]
[http://www.etoo.cn/sports 健身器材]
[http://www.etoo.cn/sports 健康器材]
[http://www.etoo.cn/sports 体育器材]
[http://www.etoo.cn/stadium 场馆设备]
[http://www.etoo.cn/stadium 跑步机]
[http://www.etoo.cn/21win-win 拓展训练]
[["SsSa"]] [["SsSb"]] [["SsSc"]] [["SsSd"]] [["SsSe"]] [["SsSf"]] [["SsSg"]] [["SsSh"]] [["SsSi"]] [["SsSj"]] [["SsSk"]] [["SsSl"]] [["SsSm"]] [["SsSn"]] [["SsSo"]] [["SsSp"]] [["SsSq"]] [["SsSr"]] [["SsSs"]] [["SsSt"]] [["SsSu"]] [["SsSv"]] [["SsSw"]] [["SsSx"]] [["SsSy"]] [["SsSz"]]
[http://www.wjmgy.com 脉管炎]
[http://www.wjmgy.com/1 脉管炎]

The following may be the most extensive suggested release process modification yet. OK, with that said, the first step is to abandon the current concept of stable/testing/unstable distributions, and merge all packages that encompass the above distributions into a single pool. This may sound crazy at first, but the ideas that follow, I believe, simplify the package management and release process drastically.

Now, with all packages located within a single pool, a slight rearrangement of dependencies will be required. Packages that implement basically the same feature set are considered to belong to a new concept called a "level." A sample graphical package map in the new regime follows http://members.cox.net/zero79/fig1.png A few notes on the above figure

  • arrows indicate a dependency link (non-arrow side is the depending package)
  • multiple arrows that arrive at the same level indicate that the dependency can be met by any of those packages multiple arrows to multiple levels indicate dependencies on multiple packages
  • last digit increment in a package name indicates a fork from a previously stabilized package
  • circular dependencies are not considered, but hopefully, a smart developer should be able to figure out how to support such a scenario
  • a higher level package must inherit the same versions of dependencies of those packages that it depends on (in the example map, if gnome2.8.1-1 depends on gtk2.4-2, then it is automatically dependent on gtk2.4-2, gcc3.3-2, and debian-base3.2-3; or it could be dependent on gtk2.4-2, gcc3.3-1, and debian-base-3.2-2; or gtk2.4-2, gcc3.3-1, and debian-base3.2-1; but gtk2.4-2, gcc3.3-2, and debian-base3.2-2 would not be permissible). These varying package dependency configurations will be discussed subsequently.
  • it would be useful to have a package that could generate the software map (for the developers' sanity) for all software or subsets in the pool
  • note that the example package pool map is not based entirely on the current reality of available Debian packages

Note that the above would require some subtle changes to the package management system. One of which is that dependencies are satisfiable by multiple packages (for example dependencies of gcc3.3-1 can be satisfied by either debian-base3.2-2 or debian-base3.2-1).

Now, on to my idea for a refined release process (utilizing the above refinements to the packaging system of course). I'm going to use the acronym RC for Release Candidate and RCB for Release Critical Bug (most documents seem to call both RC). I'm also going to call the next release debian3.2 for lack of a better name. The first release candidate, debian3.["2RC0"], will begin at month 0 in the time line. This RC can be thought of as roughly equivilant to the current unstable distribution. On day 0, all of the packages from the previous stable release (debian3.1R0) are forked (the last digit of the name of all packages is incremented), and all relevant strings are changed to reflect the name and version of the new release.

From now until month 6 day 0, the package system will try it's best to include the packages with the highest version number that do not contain any ["RCBs"]. As soon as an RCB is reported, the offending package (along with all dependent packages that can't fall back on other packages on the same level as the offending package) is instantly rolled back to the previous stable version. When the RCB is fixed, the offending packages are brought back into the distribution. The system always favors the package with the highest version number so long as that package contains 0 ["RCBs"]. For example, on month 3 day 4, debian3.["2RC0"] consists of the packages contained within the dashed line in the following figure http://members.cox.net/zero79/fig2.png On month 3 day 5, a user reports that there is an RCB in gtk2.4-2. The system sees that it can fall back on the last stable gtk package (gtk2.4-1), but will also need to revert to gnome2.6.1-1 and evolution1.4-1 as in the following figure because gnome2.8.1-1 was not built to depend on gtk2.4-1. http://members.cox.net/zero79/fig3.png

The above process produces a distribution with 0 ["RCBs"] at any instance in time. Thus, at month 6 day 1, a virtually bug-free distribution is available, which will now be called debian3.["2RC1"] (equivilant to current testing). The key differentiator is that packages in this RC with ["RCBs"] are not rolled back right away and no new packages are accepted. The package maintainers now have a 3 month window until month 9 day 0 to fix any new ["RCBs"] that arise. On month 9, day 0, all packages containing ["RCBs"] are reverted back to the versions from the last stable release. Again, the system is RCB-free. Now, from month 9 day 1 until release, the final port and polish is put on debian3.["2RC2"] (a new concept, called "polish"). Any valid ["RCBs"] at this point, again force the offending package to be reverted back to the previous stable release, but contrary to ["RC0"], the package may not return. I'd imagine the polish process should take anywhere between 1 to 2 months, at which point, debian3.["2RC2"] becomes debian3.2R0. Security updates to previous stable packages (that remain within ["RC0"]/["RC1"]/["RC2"]) may be accepted at any point in the development process. Packages should be evaluated in terms of how well they work in the new system throughout ["RC0"] and ["RC1"], and packages that just don't fit or don't play well can be excluded any time during that process.

Cons:

  • potential abuse via the ability to kill any package by reporting an RCB at the last minute before the ["RC0"]/["RC1"] transition.
  • potential abuse via the ability to kill any package by reporting an RCB during any point in ["RC2"] (perhaps 2 out of 3 reviewing developers including only one of the package maintainers must approve ["RCBs"] at this stage).
  • debian3.2R0 would probably take 12-18 months to be released because package management modifications (dpkg, apt-get, moving everything to a single pool, etc) could take 3-9 months.
  • ["RCBs"] may potentially be reported in packages that were previously declared as stable (fall back to previous previous stable???)

Pros:

  • all package versions can coexist peacefully in a universal pool (gnome2.10.0 can exist along with gnome2.9.5, gnome2.8.1, gnome2.8.0, gnome2.6.1, etc.). there is no longer any need for testing/unstable/experimental/volatile/supermegafryurdisk/etc to compensate for new package development.
  • when debian3.["2RC1"] is initialized at month 6 day 1, debian3.["3RC0"] can be initiated right away from previous stable (probably like debian3.1R2 at this point). in other words, there can be two potential releases in the works at any given time; producing stable releases approximately every 6 months.
  • at month 12 day 1, debian3.["4RC0"] can be initialized from debian3.2R0.
  • packages lag only between 4-10 months (usually on the 5 month side depending on how well ["RC0"] integration goes)
  • users can install any package in the universal pool (I suggest big warning flags for those packages with ["RCBs"] or security issues). say gnome2.8.1-1 is in the stable release, but the user wants to run gnome2.11.3-1, so they do "apt-get install gnome2.11.3-1" and they get a warning about installing from outside the stable realm, then they see ["RCBs"], security issues, and other potential warnings about using non-stable packages.
  • no need for backports.org. newer packages built to depend on the stable system can be built directly into the universal package pool.
  • ["RCBs"] do not delay releases.