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

Re: buildd administration

Anthony Towns <aj@azure.humbug.org.au> writes:

> On Sat, Dec 10, 2005 at 03:51:36PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns <aj@azure.humbug.org.au> writes:
>> >   (a) seeing if the FTBFS can be fixed immediately, and finding it can't
>> >   (b) documenting (this is the transparent bit, so pay attention) that
>> >       fact by not having s390 incorrectly listed as a supported arch in
>> >       the source and ensuring it does not incorrectly indicate a known
>> >       broken build is successful as it did in the past
>> >   (c) informing ftpmaster that the build currently in the archive is
>> >       broken by filing a bug requesting the broken build be removed
>> >       (you know, communicating with people)
>> >   (d) downgrading the bug so that it is not incorrectly listed as
>> >       a RC issue that the RM and QA teams have to attend to
>> >   (e) as maintainer, work with upstream and porters to fix the
>> >       downgraded but still open bug we were just talking about
>> I disagree with this.  
> Then you're not maintaining your packages properly, and you're making
> life more difficult for the rest of the project out of spite.

You are incorrect.  I disagree with your approach to fixing this
particular problem.  I think it is better to keep the package out of
testing until the problem is resolved one way or the other.

You have failed to detail any particular difficulty that this causes,
nor have you given any reason why the package should be added to
testing in advance of my judgment that it's ready, nor have you given
any explanation of why you think it's ready now.

You have not pointed at any documentation of maintainer policies that
indicates that one must clear an RC bug as soon as possible, for
unreleased packages, to push them into testing before the maintainer
thinks they are ready.

By contrast, your strategy of "maintaining" packages which you simply
ignore, is a direct violation of the standards of the Project.


Reply to: