Re: m68k release future
On Fri, Oct 27, 2006 at 06:38:55PM +1000, Anthony Towns wrote:
> 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.
Um, I think I've missed something. What'd be the functional difference
between the two? Isn't it going to be so that we'd be able to do our own
arch-specific NMUs in both cases? Or is it in both cases going to be a
matter of deciding which package will be part of the distribution and
which not?
> 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.
The point is that if we can actually get something out that is as close
to etch as possible, that we don't have to redo everything the security
team is doing already anymore. There may be some additional work in case
a package is different from the official etch, but those should be
minimal.
If we do our own snapshots and we do want security support, we would be
pretty much on our own. That's not what I'd like to see.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: