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

Re: julia_1.0.0-1_amd64.changes REJECTED

On 2018-11-21 18:47 +0100, Matthias Klose wrote:
> On 21.11.18 16:56, Holger Levsen wrote:
> > On Wed, Nov 21, 2018 at 03:19:33PM +0000, Ian Jackson wrote:
> >> Why is any of this a reason for an ftpmaster REJECT ?  I still think
> >> all of this should be handled as bugs (possibly RC bugs) in the BTS
> >> in the conventional way, after ACCEPT.
> > 
> > because why accept rc-buggy software in the archive (when we know it's
> > rc-buggy), whether at NEW time or with any following upload?
> is the decision about rc-buggy-ness one for ftp-master?  usually these issues
> are sorted out between package maintainer, bug submitter, release team, and
> maybe ctte.  I don't see ftp-master involved with that.  Sure it makes sense to
> reject *obvious* rc issues, but that doesn't seem to be the case here.

Right. The FTP-master check is primarily for things we shouldn't ship
because it's not legal (primarily copyright infringement, but
potentially other things like patents, munitions, under-age porn). To
stop things getting into the archive that will cause a load of
trouble. Some other basic checks for 'is completely broken' are also
fair enough. But everything beyond that I think we should handle in
the normal way, as bugs, to discuss.

Maintainers get lots of QA checks from our infra, and we like it when
they take notice, but disagreeing, or simply not doing much about it
in a timely manner, is not a reason to keep software out of the
archive IMHO. I sense feature-creep in the (already tricky) job of
FTP-master, and I'm not convinced it's a good idea.

> I really like the approach of some ftp-masters to accept a package and then file
> rc-issues, if there are some, like adding updated copyright information.  This
> way you also have a place to discuss the issue.

This seems sensible to me.

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: