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

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

On Mon, Mar 14, 2005 at 09:37:11PM +0000, Brian M. Carlson wrote:
> On Sun, 2005-03-13 at 20:45 -0800, Steve Langasek wrote:
> > Architectures that are no longer being considered for stable releases
> > are not going to be left out in the cold.

> I disagree. I feel that maintainers are going to ignore the SCC
> architectures for the purposes of portability bugs and security fixes.


> > - binary packages must be built from the unmodified Debian source
> >   (required, among other reasons, for license compliance)

> This is a problem. No one will fix the portability bugs that plague, for
> example, sparc (memory alignment SIGBUS) without them being severity
> serious.

Sparc is no longer the only architecture that has problems with unaligned
memory access, so these are likely to be caught whether or not sparc is a
release arch.

> Therefore, I would support this plan *iff* it were stated that
> portability bugs were still severity serious (I would not object to an
> etch-ignore tag for the purpose of stating that they are irrelevant to
> the release), that security bugs were still severity grave and critical
> (again etch-ignore would be okay), and that maintainers actually have to
> fix such bugs, or their packages could be pulled from the archive as too
> buggy to support.

Well, by definition if the bugs were tagged etch-ignore or equivalent, they
shouldn't be grounds for removing the package from testing or unstable; and
I don't think there's any reason that bugs on non-release archs should mark
a package as "too buggy to support."  But that doesn't mean porter NMUs
would be disallowed.

> For the record, I own more sparc machines than any other single
> architecture, and I am not pleased about this plan.

Then please, get involved in the sparc port to help ensure that it remains
viable for etch.  There is clearly no problem with sparc hardware that would
justify dropping the port, and in spite of being down to only one buildd
right now, we've generally not had problems with it failing to keep up; and
yet, sparc's only packaged bootloader (silo) seems to be in terrible shape
with unreproducible boot failures (which will be downgraded for sarge), and
was one of the last architectures to have the necessary kernel updates done
for d-i RC3.  The signs certainly point to bit rot, but if someone takes
responsibility for it, I see no reason for sparc to not be in shape for the
etch release.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: