Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)
Hi,
On Thu, Nov 22, 2018 at 12:52:48PM +0000, Ian Jackson wrote:
> Holger Levsen writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> > 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?
>
> Because:
>
> * Discussions about the RC bugs can be more effectively dealt with
> using our existing discussion mechanisms, including primarily the
> Debian BTS. Compared to REJECT mails:
> - Discussions in the BTS are more transparent
> - Discussions in the BTS are better organised
> - Discussions in the BTS can have wider participation
> - Discussions in the BTS are better archived
> - Discussions in the BTS have better metadata
>
> * Publishing a work-in-progress in the Debian archive enables more
> people to more easily help improve and fix it.
The experimental distribution is a good place for work in
progress. Maybe the rules for automatic rejects can be relaxed for
experimental so a package can go into the archive (and have e.g. the BTS
used for that version) if the maintainer doesn't want to fix the reject
right away.
Cheers,
-- Guido
>
> * Once a package is accepted metadata about it, and parts of it, are
> automatically published by a variety of Debian services, making it
> much easier to work with - for example, one can see who the
> maintainer is and what its issues are.
>
> * ftpmasters are already far too overloaded looking for problems like
> unredistributability, dfsg-nonfreeness, malformed packages,
> breakages of the archive, etc.
>
> * It is not ftpmasters' role to determine whether a package is
> RC-buggy; that task is for the Release Team.
>
> > (in that sense I would appreciate packages getting automatically tested
> > (and rejected if needed) before they enter *unstable*, and then again,
> > with stricter automatic tests before they enter testing.)
>
> I agree that automatic checking is fine, but humans should be able to
> override it. I have no problem with auto-REJECTs, which are generally
> either for really serious problems, or can be overridden.
>
> Ian.
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
>
Reply to: