From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Nz8UI-0001iW-G1 for garchives@archives.gentoo.org; Tue, 06 Apr 2010 13:06:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6CE76E0C16; Tue, 6 Apr 2010 13:06:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1FB33E0C0D for ; Tue, 6 Apr 2010 13:06:27 +0000 (UTC) Received: from [192.168.0.5] (pool-96-245-231-248.phlapa.fios.verizon.net [96.245.231.248]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 937E61B4068 for ; Tue, 6 Apr 2010 13:06:26 +0000 (UTC) Message-ID: <4BBB31D0.3080702@gentoo.org> Date: Tue, 06 Apr 2010 09:06:24 -0400 From: Richard Freeman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100306 Thunderbird/3.0.3 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] [git migration] The problem of ChangeLog generation References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 566c091e-f71a-4867-ac84-5e43e9a4233f X-Archives-Hash: 066fc10db2d7ea4e597df785af5c6f0c On 04/05/2010 10:13 PM, Nirbheek Chauhan wrote: > * Proposed is to generate ChangeLogs from git commits on the rsync > server side when metadata generation is done > - Scripts to do this already exist[1] I haven't seen this discussed, so I'm going to toss this out there and duck: Why not just get rid of the in-tree Changelogs entirely? The scm logs already document this information, so why have it in a file? It seems like the main purpose for it is for end-users to have some idea what changed in an ebuild. However, in my experience the upstream changes are far more impactful than the ebuild changes, and those aren't in the Changelogs at all. Instead, why not just create a script that gets distributed with portage that will upon request tell a user what changed based on the scm logs? I can't imagine that the hit on the servers will be all that large, and since this is read-only traffic it might be manageable through replication. Rich