Re: Bits (Nybbles?) from the Vancouver release team meeting
Jeroen van Wolffelaar <jeroen@wolffelaar.nl> writes:
> On Mon, Mar 14, 2005 at 09:19:27AM -0500, Andres Salomon wrote:
>> On Mon, 14 Mar 2005 15:15:16 +0100, Marc Haber wrote:
>> > Additionally, they are being excluded from having access to important
>> > resources, and the possibility of filing RC bugs which is the only way
>> > to get lazy maintainers moving is being taken away.
>> >
>>
>> That's an awfully pessimistic view. All porters need is some sort of
>> leverage that allows them to force maintainers to accept or deal w/
>> their patches; perhaps some QA team members who will NMU
>> poorly-maintained packages on behalf of porters? The amd64 crew seems to
>> be getting along ok w/out having their FTBFS bugs considered RC..
>
> The developers reference has a significant piece of text about porting.
> It includes NMU possibilities (NMU's are *always* a possibility to work
> around "lazy" maintainers, recall that the Social Contract explicitely
> mentions you can never demand work from anyone).
>
> http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-porting
>
> Note that porter patches for kFreeBSD and amd64 so far seem, as far as I
> can see, to be relatively swiftly applied anyway by maintainers, despite
> those patches not being RC either. This suggests to me that also in the
> future with patches for SCC architectures, this should normally not be
> a problem, and of course, NMU's are possible otherwise.
>
> --Jeroen
Looking just at the ones I reported:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=submitter&data=brederlo%40informatik.uni-tuebingen.de&archive=no
#249397: FTBFS: amd64 missing in Architecture list
Package: mga-vid; Severity: important; Reported by: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>; Tags: patch; 301 days old.
# #249440: inetutils: Wrong Priorities and Sections in debain/control break debian-amd64
Package: inetutils; Severity: important; Reported by: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>; merged with #205487, #266666, #290700; 301 days old.
# #251765: FTBFS: missing amd64 support
Package: scm; Severity: important; Reported by: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>; Tags: patch; 288 days old.
# #252760: FTBFS: architecture missing
Package: mkrboot; Severity: important; Reported by: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>; 282 days old.
# #252771: FTBFS: wrong architecture
Package: bsign; Severity: important; Reported by: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>; 282 days old.
# #254089: FTBFS: test for res_mkquery is broken
Package: mtr; Severity: important; Reported by: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>; Tags: patch; 274 days old.
# #255725: FTBFS: amd64 needs Build-Depends svgalig1-dev too
Package: cthugha; Severity: important; Reported by: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>; 265 days old.
....
That suggests that FTBFS bugs for SCC archs will be ignored just as
long, 1/2 - 3/4 of the planed release cycle. Now imagine a bug in fsck
that destroys data being left open for so long.
SCC will become useless real quick unless porting NMUs remain allowed
after 7 days as it is now and unless portes exercsise those NMus more
often.
MfG
Goswin
Reply to: