On Fri, Oct 20, 2006 at 08:21:15PM -0500, Stephen R Marenka wrote: > > (c) not bother with an etch-equivalent release for m68k > I'm not sure about this. I'd sure like to have some form of stable, even > if we only do base and security-support base-type packages. I'd hate to > have to maintain unstable/testing as the distribution on my buildd's. On Sun, Oct 22, 2006 at 01:01:39AM +0200, Michael Schmitz wrote: > > (c) not bother with an etch-equivalent release for m68k > I'd like to keep that option, at least to build a release of our own > design (maybe leaving out some tough stuff; at the very least something > you can install and then work from). On Sun, Oct 22, 2006 at 02:37:04AM +0200, Wouter Verhelst wrote: > > (c) not bother with an etch-equivalent release for m68k > I'm with Stephen on this one. It doesn't have to be a full release, but > something that we and our users can use and that we can build security > support packages for would be nice. On Wed, Oct 25, 2006 at 02:39:26PM +0200, Goswin von Brederlow wrote: > >> (c) not bother with an etch-equivalent release for m68k > I'm very much for a stable release for m68k. It gives you something to > run the buildd on or to reinstall from that you know works. With > testing something breaks every day. > > I don't mind removing large amounts of packages from stable for > m68k. Cut away anything that isn't working and not neccessary. Avoind > diverting from the official stable sources unless something neccessary > breaks. So, right now you need to decide on which you want to focus on, getting a etch equivalent release out, or getting a testing-m68k operational. It might be possible to have both eventually, but you definitely need to choose one now. If you want to do an etch-m68k you'll need to work out what packages you want to drop, and how you're going to keep in sync with etch proper now; the testing-m68k stuff will probably have to wait 'til after etch in that case. Personally, I think m68k would be better served by having a testing-m68k and taking occassional snapshots which serve as the supported stable-m68k release, rather than worrying about something equivalent to etch itself. And please note: while the security team /might/ be willing to do support for a limited m68k-etch, you can't assume they will -- you really should be ready to that support yourself in case they find themselves too busy supporting sarge and etch on the release architectures. Cheers, aj
Attachment:
signature.asc
Description: Digital signature