[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits (Nybbles?) from the Vancouver release team meeting

Hamish Moffatt <hamish@debian.org> writes:

> On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
>> All the work and support over all those years by all those users and porters
>> will be vanished with that stupid idea, imho. 
> Ingo, obviously you are pissed off. But really, is there much benefit in
> making *releases* for the SCC architectures? 

A stable release or at least a testing is quite essential to many
users. Especialy with the struggeling archs sid is broken for many
days on end with missing packages, broken dependencies, version skews
and and and.

If you want to install a full system from scratch on an scc arch you
can basicaly give up. Something will not work that day and maybe not
all month.

The reason for this are the DAK's _all.deb handling and wanna-builds
non-fifo queue. Both drastically increase the problems to last days or

The stable and testing releases through their extra consistency checks
don't have those problems.

> The packages will still be built and d-i maintained as long as there are
> porters interested in doing that work for the architecture. The only
> difference is that those architectures won't influence testing and they
> won't be officially released.

I can fully agree that scc archs should not hold back the official
release. But that does not mean the scc archs have to stop releasing,
stop security, stop testing nor does it require splitting them off to
another server.

The release, testing and security could just concentrate on the main
archs. The scc archs can keep their own testing (somewhat increasing
the size by having older sources linger longer) and security uploads
whenever their buildds are up for it.

Security releases for scc would be made by the porters or by a
security member willing to manage it. They don't have to hold up the
DSA but if they can make it in time they should be included in the

A release for an scc arch could come weeks or month later than the
main archs and be done by the porters alone. The only requirement for
it would be that only stable sources can be used (with a few
exceptions maybe for arch specific sources). Stable sources that don't
build can't be in an scc release. E.g. no patching of kde to build on
XYZ after the main archs have released, kde would have to be removed
on that arch.

For scc testing I believe britney would have to be patched or run
seperately for each arch with the porters being in charge of adding
overrides for that arch. The normal testing team should not be
bothered by this though. If it is having no testing or working on
britney to support it many porters will probably help out.


Reply to: