From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BE7A513877A for ; Tue, 12 Aug 2014 17:25:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03C88E0C89; Tue, 12 Aug 2014 17:25:47 +0000 (UTC) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 07276E0C63 for ; Tue, 12 Aug 2014 17:25:45 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id lf12so13836576vcb.1 for ; Tue, 12 Aug 2014 10:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=gLxPL3feGBDgaYgWP/LcW6F8wPoUxCUbm3ZjZYc4mgo=; b=cPSrnj+4pCjoBuePQ0GSzSBaASfPvuJ8ALKyxpkXFwFgz/d8MfoF1XzUkHZAco+q18 mXVFfLSn/pyM16Ni+zDs3mPQbQTTtykIUFA+9g8fvLWkMq09dFtP0+dmICKe5Ki4iOf4 1tNBVV1ixB2TzusNGslxCNoxmJWv0CKzeFK3tM3eUzSAA0rxMEWQfSVhMHQTN7M01eq1 l61pKE2k2pmGGzBLrZNAUbxl7a66TB7/2FFbpeVvNCYBgwVUqGxJORmzES/jK0ZkhZWb ZOs78zJLxBTtRci0yS9968e+i2rG+67uEZgO0+mZDvvVffLAtO+zxPAeTIs5kxHXFJsj Y3xw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.94.108 with SMTP id db12mr24798495vdb.8.1407864344773; Tue, 12 Aug 2014 10:25:44 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Tue, 12 Aug 2014 10:25:44 -0700 (PDT) In-Reply-To: <53EA4B26.10608@gentoo.org> References: <20140810152211.2cc5ae94@sf> <20140812014820.GA3086@linux1> <53E97502.40604@gentoo.org> <20140812024257.GA3262@linux1> <53EA0CC6.6050000@gentoo.org> <53EA1C86.6070800@gentoo.org> <53EA1F0A.8010907@gentoo.org> <53EA476F.6000300@gentoo.org> <53EA49FD.4020203@gentoo.org> <53EA4B26.10608@gentoo.org> Date: Tue, 12 Aug 2014 13:25:44 -0400 X-Google-Sender-Auth: sD98rWA2z-8IXlwhC9rx3wl-pBo Message-ID: Subject: Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings ) From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: eccfaf27-afbf-4f3f-919e-2ef4c3acae14 X-Archives-Hash: 48822af484f655f31c9d9fb7b40b72f0 On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius wrote: > > I don't consider a recommended style message to be 'broken' just > because it's not listed in the devmanual/PMS/etc as a requirement. > The implementation of it, on the other hand, yes that could be broken > and in this case should be fixed if we keep the check around. > If we are bothered enough by something to have repoman check it, we can be bothered enough to add it to the devmanual. I think we need to decide whether we care about periods at the ends of DESCRIPTIONs. If we do, then it should be a warning and devs should fix their ebuilds at the next convenient opportunity. If we don't, then let's just drop the warning. I'm fine with the separation of hard/soft errors, because some issues could be situational and left to developer discretion. However, we wouldn't want to hide those, because if a dev introduces a new issue we don't want them to not see the warning. If somebody has a whitespace issue they should get a warning. They should be doing a scan before commit, and they should generally take the time to fix the issue, even though it is just style. What is the point in having a style guideline if half of us are just going to ignore warnings related to it. That doesn't mean that our style guidelines have to be over-the-top - the solution to that is to drop requirements that aren't important, not to hide them. If somebody wants to come up with a bunch of extra optional repoman warnings for stuff like style, I think their time would be better spent coming up with an ebuild pretty-printer or something which just fixes things instead of whining about things that aren't policy. Ultimately quality has to be something we invest in for each other's sake. If a rule isn't really benefiting anybody, then it doesn't belong. Within reason good style helps us all out - bash doesn't care if the whole ebuild fits on one line with all the phases/variables/etc in semi-random order, but we impose some sane style so that we can work in the tree and not rip our eyes out. -- Rich