Re: m68k release future
Wouter Verhelst <email@example.com> writes:
> On Sat, Oct 21, 2006 at 06:58:21AM +1000, Anthony Towns wrote:
>> Hey all,
>> So, from the other thread, seems like the idea for m68k is:
>> (a) keep building unstable as per usual
A per architecture tracking of arch:all package would be nice
there. Only allow libfoo-common in for an arch when libfoo gets
uploaded for that arch.
>> (b) maintain a separate testing-like suite for m68k based on (and
>> thus probably trailing) the real testing, maintained by m68k
>> porters, that is installable (using d-i etc)
If arch:all handling isn't improved this would be the next best thing.
>> (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.
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
We did that for amd64 and got support from the security team for
it. If the m68k team can setup a DAK for this and keep up the security
buildds the security team might just aggree to keep supporting it.
>> (d) try to release with etch+1, possibly with coldfire support
With the old stable release manager and amd64 it was said that there
won't be any change in the release archs for a point release. Has that
changed now that there is a stable release team?