建议ML的开发维护人员考虑下各版本的延续性
用了ML的好几个版本感觉很好，但版本之间的升级很糟，基本上不能升至下一版本，只能格盘新装；还有updates里的包跟发行版有一定的问题，我升了几次都不行只能降回来，昨天又去升了，甚至都进不去系统了，我建议各位老大把包整理下，单独列一个可稳定升级的软件库，把经测试可在发行版上稳定升级的包集中在一起以便大家升级更新。 :wink: 我都是重装系统，用ubuntu的时候都很少升级到新版本。
不过我支持这个建议，mgc确实需要在成熟后考虑一下这个问题了。 嗯，下一步我会整理仓库的。 sejishikong 兄现在看到了吧，如果是前一个时期给你提意见你肯定接受不了，只能等大家来骂街了。你最大的错误在于把未经测试的东西扔进了仓库。
强烈建议，任何进入仓库里的东西必须经受严格组内检验，没问题才能进入仓库测试区，测试一段时间，若没问题才能进入正式仓库。移植并非就是拿别人的 srpm 稍加修改在本地编译一便那么简单，有时要下比较大的工夫修改才行。你现在的一些包连中文菜单都没有，易用性更别提了。 维护软件仓库既费时又费力，不管怎样，都要感谢为ml做出贡献的各位！ :oops: 如果实现网上升级...... 升级仓库的混乱是MGC最大的心腹大患，虽然SHE兄一再表示不应该是他本人的错误，可是到底问题出在哪呢？
新的系统是否有必要升级GTK2.8也值得考虑，因为GTK2.8带来的麻烦比新的性能还要多。
MGC的更新应该本着实用性，而不应该是追新，早些时候我会听不进KDE的那些话，但我现在觉得就算MGC唯护的是一个所谓的旧系统，只要他能实现各方面稳定的需求就对了。这就是到底是开发系统还是提供玩具的区别。 这不是色兄一个人的问题。
ML 应该把保持仓库的稳定性作为一个制度确定下来。
支持 KDE 的建议：
任何进入仓库里的东西必须经受严格组内检验，没问题才能进入仓库测试区，测试一段时间，若没问题才能进入正式仓库。
问题在于，谁来测试？
有很多包我已经扔了很长时间才有人测试出问题，我的环境只是虚拟机，尤其是多媒体这块，我根本没有办法测试。
我的想法就是现在只能想办法加软件，软件多了才有人用仓库，才能测试出问题。
下一步我的考虑是参考Debian的做法，将仓库分为测试和稳定两个。但是还是这个问题，测试的仓库由谁来测试？测试仓库的内容什么情况下才算稳定，以时间做限制？还是经过多少人的使用？ 问题在于，谁来测试？
有很多包我已经扔了很长时间才有人测试出问题，我的环境只是虚拟机，尤其是多媒体这块，我根本没有办法测试。
我的想法就是现在只能想办法加软件，软件多了才有人用仓库，才能测试出问题。
下一步我的考虑是参考Debian的做法，将仓库分为测试和稳定两个。但是还是这个问题，测试的仓库由谁来测试？测试仓库的内容什么情况下才算稳定，以时间做限制？还是经过多少人的使用？
我的想法是：把仓库分为两个部分看待，ML 默认安装的和用户安装的。
ML 默认安装的，一方面这些包是 ML 默认安装的，仓库应该保证它的稳定；另一方面这些包也是大部分人常用的软件包，有定时提供版本更新必要性。
这些软件包，可以上测试仓库两个星期后转为稳定，因为用的人多，估计时间也足够了。
用户安装的，则要区分常用的和非常用的。
常用的应该采取与 ML 默认安装的一样的测试标准。
非常用的人可以很少，用的机会也不多，个人觉得没有进行测试的必要了。只要能找到在开发组中没有异议的 patch，在一个星期内更新软件包就可以了。
测试组是开放的，使用 bugzilla。发现 bug 提交到 bugzilla 就可以了。论坛中有这么多热情的兄弟，相信测试组的人员数目能维持在一定水平。
PS：用户安装的软件包中，如何区分什么是常用的，什么是非常用的，这是个问题。 可以考虑增加一个小软件,用来登陆后进入系统提示.
如果有新的软件加入仓库,就显示其名称,版本,用途,需要测试吗？
愿意测试的兄弟应该是很多的，关键是没这个概念。 我初步的想法是分成这样的目录：
2-
stable-
RPMS.os
...
unstable
RPMS.os
...
3-
stable
unstable
基本已经确定3可能不能直接在2上升级，所以要有两个版本的仓库。
每个版本再分stable/unstable, unstable两个星期（或更长时间）放入stable(如果没有问题).
不过这样一来维护工作量会非常之大。 不知能否这样处理：
把软件包定义为三种状态：
稳定、测试、错误（冲突）未解决
稳定的放在 stable 中，测试或错误（冲突）未解决的放在 unstable 中。
被标记为测试的，一个时间段没问题后就移到 stable 中。
被标记为错误（冲突）未解决的，则让其停留在 unstable 中，不作处理。
用服务器后台程序控制状态的改变。
不知这样是否可取，讲各位大大都来讨论一下 我的想法是这样的：
1。新增软件的编译问题，必需确保所有新增软件在原有的系统底层上进行编译，避免用户由于安装软件需要更新类库，新增软件列入stable；
2。对系统底层进行改动或类库的所有更新全部列到unstable，那部份是供测试用的，只有对Linux有了解的朋友才有能力进行测试和报告，比如GTK2.8等等；
3。重要的更新放入stable中，改良更新全部列入unstable
这么做的结果是Magic的在线更新不会有多少可用部份，确保大家尽量可能少更新现有系统，可以自由更新一些新的软件，有利于发现和解决现有问题。
现有的Magic更新是混乱的，以致于根本就不知道该更新哪些。很多的更新根本是没必要的或是改良的，更新的朋友包括我在内对更新带来的任何作用一无所知，出现问题根本不知从何入手，只好和大家现在的“全面更新”有问题。。。 我初步的想法是分成这样的目录：
每个版本再分stable/unstable, unstable两个星期（或更长时间）放入stable(如果没有问题).
不过这样一来维护工作量会非常之大。
我个人认为根本没必要去分析stable或unstable，所有对底层的变动更新全部归入unstable，如果确保底层更新能实现系统性能新的飞越时，可以进行ISO打包，同时提升小版本号，这时才能把新版本的底层实现移动到stable中。
更新应该是提供给不方便重新下载ISO重新格式安装系统的朋友，我不认同Magic模仿ubuntu或FC的更新方法，那对用户特别是初学者是一种误导。
页:
[1]
2