On Sun, 2005-12-11 at 19:18 +0100, Andrzej Krzysztofowicz wrote: > =?UTF-8?B?TWFyY2luIEtyw7Ns?= wrote: > > > I can't see what's > > > bothering ppl bout dying ac and th. Windows 98 and 95 and ME died as > > > well, > > > other distros also make new versions and move on forward. > > > > For me personally if we will switch to "awlays in developement" distro > > it would be easier to: > > > > 1) Maintain my machines, by simply doing poldek --upgrade-dist out of > > stable tree. Occasionally there will be need to do some manual upgrades > > like from postgres 8.0 to 8.1 which requires database dump/restore. Now > > But if you leave one machine not upgraded, after some time it may become > not upgradeable. Because of missing triggers, package splits, missing > obsoletes, etc.
Perhaps it is time to start tracking those, and recording an upgrade path. > > lets assume that we will stay with current distro politics + we will > > release new version every year. So once a year I'll probably have to > > reinstall all the machines because version Z was released and X has > > reached an EOL. > > What for machines that are not upgradeable N -> N+1? Eg. because of their > configuration and bugs present in year N+1 release. Will rel. N+2 support > N -> N+2 upgrade ? > Eg. some X11 version (or any other commonly used library) is unusable for > them, suggested solution is to use previous version with bugfixes? I think part of the problem is that we would need to keep old package sets on FTP: A sort of mini-release with every batch of moves from ready to main. If the distro tree is laid out for that, I can see it working very well. Poldek 0.20's config files leave good infrastructure for rolling out new repo locations via updates, too. > > 2) Maintain distro itself. Now if there is some security bug it should > > be fixed in Ra, Ac, Th. With "always in developement" we'll > > prepare/commit/test/build fixed packages only once. > > Yes, leaving the work for machine admins is simpler. Hehe. Aria _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
