Hi all, Krisztian VASAS wrote: > On Mon, 27 Feb 2012 16:27:52 -0800 (PST), James Buren wrote: >> After difficulties we had during 1.6 release cycle, I am proposing a >> rule addition. In addition to the freeze we do from rc2 -> stable, >> I am proposing we do a new feature and major bump freeze on >> everything that is not in a -extra group as its main group after we >> are past the pre2 release of a release cycle. The way I feel is, >> major changes in the main groups should be implemented by the >> time we have pre2 released. This gives us a 2 month period instead of >> a mere two weeks to resolve outstanding issues with the >> main branch. I don't wish to apply this to anything in extra, as that >> has few important packages, and is way too massive for us >> to do any real quality control on. Thoughts? > > I don't want to say that i was talking about this years ago. I also > don't want to say this is one of the main reasons i don't use Frugal > on desktop any more. But i've tried several distros, maybe you think > about my opinions: > - why not freezing after rc1? just because of the time. there can be > bugs that are not trivial. freezing after pre2 is a good idea imho Wait a second: freezing means no version bumps, but not no bug fixing. I go for rc1 for this. Even not trivial bugs could be fixed till release.. or reverted.
> - why not excluding xapps? just because most of the users will use > packages from xapps. these packages are the most frequent packages, > they should work in stable without bugs +1 > - the installer should be tested much better. i don't want to give > offense to vmiklos, but last time when i used the installer i had to > choose a very basic install becasue i ran into strange things +1 > - last time when i've seen the text-based installer, all the big > desktop environments were choosen by default. you should choose only > one default, not all. if this was changed, then sorry. As vmiklos already said: who should decide which one? Perhaps there should be none preselected but the user noticed to choose one. > - kernel: i know vmiklos' opionion about this, but the current kernel > upgrade mechanism is the worst i've ever seen. i war running into > strange problems when i had to pick the installer, chroot into the > installed system and hack just because the original, working kernel > was deleted and the new kernel wasn't usable. currently the distros > use a mechanism where the "kernel" (or whatever they call the package) > is only a virtual package that depends on the "kernel-$version" > package that contains the kernel itself. if you do an update and the > "kernel" package is updated, the system will install a new package > with the new kernel and does NOT remove the original, currently > working kernel package. i know it can be strange but i think it's > still better to remove current-1/current-2/current-N kernels than > running into strange things. > This reminds me of some glitch in pacman-g2 packagehandling: If some package replaces another one and while installing the replace something goes wrong (like me installing without --noarch ;) the old package is gone and in a second attempt the replace will no longer be installed. It would be realy helpfull to have some general rollback/history mechanism. I must admit, that this would not help in case of non booting Kernel, but anyway ;) Greetings DeX _______________________________________________ Frugalware-devel mailing list [email protected] http://frugalware.org/mailman/listinfo/frugalware-devel
