Re: m68k release future
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
>> Um, I think I've missed something. What'd be the functional difference
>> between the two?
>
> testing-m68k == having something that updates from unstable at its own
> pace for m68k only. That might mean lagging behind the real testing if
> there are toolchain problems, eg. If you wanted it to, it could mean
> advancing ahead of the real testing if some RC bugs for some release
> architectures don't apply to m68k.
>
> etch-m68k == having something that matches etch.
>
> Right now, the practical difference is that m68k needs to be dropped from
> actual etch, and some new suite created that you guys can start poking at.
> If that's testing-m68k, then you'll probably find yourselves diverging
> from etch to the point where an etch-m68k release isn't possible. I
> might be wrong on that score though.
I'm very much in favour of having etch[-m68k] and very much against
testing-m68k. A testing-m68k would put the port complety outside of
the normal Debian and maintainers would be much more unwilling to
accept patches (more so than now) to fix m68k bugs in fear of
introducing bugs in the real Debian. They would object to porter
upload for an inofficial port and so on. I've seen the struggle amd64
had with this and didn't like it.
I don't think it is neccessary to divert from etch at all, except for
omitting packages. So I vote for etch[-m68k] and a common sid for
all. Patches go directly to sid like now and migrate into etch and
possibly etch-m68k at different speeds. Preferably at the same speed.
> Maybe you want to have a testing-m68k now, with the expectation of doing
> a snapshot that matches etch as closely as possible when etch releases,
> and leaving it open whether you want to do snapshots again in future
> before the next new stable release.
I want a stable "stable". Something that installs and works and is a
solid base to upgrade from and to run buildds on. As such I would
rather have less updates than more. I wouldn't even mind cutting away
all of KDE and GNOME for the time being if that means we can keep up
with etch and get included back in fully.
>> 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?
>
> Well, mostly, I was hoping you'd tell me what you want to do for that...
>
>> 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.
>
>> 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.
>
> I'd like to see snapshots for testing anyway, and Joey Hess has
> expressed a similar interest, among others. We haven't managed it yet
> though, obviously. The unembargoed security team are doing some work
> at supporting testing again atm too, btw.
Maybe m68k isn't the right architecture to test this with.
> Cheers,
> aj
Earlier you mentioned that in future there could be both an etch-m68k
and testing-m68k. Would that mean we have a base system of
essential/important stuff (etch-m68k) that is kept in close/exact sync
with debian and then fringe stuff or stuff that just takes too long to
keep up with in a sepperate testing-m68k tree?
The essential/important stuff would be relesed in sync and officialy
by Debian while the testing-m68k tree gets snapshots from time to time
at its own pace? Etch-m68k would have security support but
testing-m68k not?
Is that a correct or viable picture?
MfG
Goswin
Reply to: