On Tue, Nov 03 2009, Stefano Zacchiroli wrote:
> On Tue, Nov 03, 2009 at 09:30:04AM -0600, Manoj Srivastava wrote:
>> > The ideal solution would be to have dak know the previous state and do
>> > not accept _regressions_ wrt the previous set of fatal upload errors
>> > (according to the proposed wording). I'm not sure it is worth though,
>>
>> I beg to differ. In the long run, there should not be *any* such
>> violations in the archive; so it is not really worth spending time
>> writing code for dak that will shortly be a dead path.
>
> For packages that are now in the archive with lintian errors that would
> have prevented them to be uploaded, you're right. However, as a corner
> case, you can imagine a new lintian check added 10 years from now, and
> that check be used to refuse uploads. All packages upload starting from
> now to that moment might be prone to that error. That error would upload
> to upload NMUs which do not fix it (but possibly fix other serious
> errors).
>
> This argument is moot only if you assume that we will never add a new
> check to the dak black list which has at least one matching package in
> the archive. Are you sure that will never be the case? I'm not that
> confident.
That is not what I meant. I meant that when we do add such a
lintian check to the blacklist, we also file serious bugs against those
packages in the archive; and aggressively work to either fix the
packages, or remove them from the archive. I think our effort should be
spent in the fixing/removal, rather than perpetuating buggy packages in
the archive. If a package is too buggy to be i Debian, we should not
do more work in order for it to remain in.
manoj
--
How wonderful opera would be if there were no singers.
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
