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 F32DF138010 for ; Wed, 31 Oct 2012 18:39:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7BD9421C049; Wed, 31 Oct 2012 18:39:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D657C21C032 for ; Wed, 31 Oct 2012 18:38:23 +0000 (UTC) Received: from [10.169.32.2] (212-226-75-61-nat.elisa-mobile.fi [212.226.75.61]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id C15C933D85C for ; Wed, 31 Oct 2012 18:38:22 +0000 (UTC) Message-ID: <50916EFD.7040807@gentoo.org> Date: Wed, 31 Oct 2012 20:33:33 +0200 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120916 Thunderbird/15.0.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] On the usefulness of eclass changelog References: <20121030190839.A9A3D21600@flycatcher.gentoo.org> <20121030191725.GC809@gentoo.org> <20121030222444.694cd93d@pomiocik.lan> <5090468F.2030701@gentoo.org> <20121030183944.3b0a8652@gentoo.org> <20121031122605.581161e8@gentoo.org> <5091454D.7060701@gentoo.org> <20121031123933.2f690239@gentoo.org> <50914EB8.60501@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: b43ff136-af79-4ca2-ab16-1508a7b01aef X-Archives-Hash: 082e90d3c208dd915c3b362a1bb30656 On 31/10/12 20:17, Rich Freeman wrote: > On Wed, Oct 31, 2012 at 12:15 PM, Samuli Suominen wrote: >> eclass/ handling should go to repoman and the automated ChangeLog process, >> should be rather straight forward for knowing person. > > Perhaps, but right now the policy is to update it, so do it. The > policy is also to post eclass changes for review on -dev, so do that > too. That means do it BEFORE you commit it. I don't care if you post > it raw, or post a link to a file, or post a link to a proposed commit > on your private little git branch, but don't commit it and then send > out a link to the commit in production after the fact. > > This whole double-thread is ridiculous. If somebody at work > deliberately violated a dumb policy and pointed out it was dumb, the > answer would be, "thanks, we'll look into changing the dumb policy, > now pack up your desk to make room for the new employee who can > benefit from the improved policy." > > If you don't like the rules feel free to whine, beg, and plead to QA, > the council, $DIETY, or your mother, but follow the rules until > they're changed. There is always room for mistakes, but big projects > don't work when everybody just does whatever they feel like doing. I'd expect the file to be zeroed out after the repoman has been fixed to cover eclass/ as inconsistent ChangeLog equals useless ChangeLog And indeed this is ridicilous as the claims of not following rules has not been even broken. The eclass was sent to ML months ago already, and the conserns from back then have been counted in already for: http://gentoo.2317880.n4.nabble.com/rfc-udev-rules-eclass-td45792.html How many times are you required to do that before pushing it in? Last minute changes were made, yes, but this is no new news that it was coming in. - Samuli