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 9630E59CAF for ; Mon, 4 Apr 2016 02:27:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6D17EE07D2; Mon, 4 Apr 2016 02:27:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BD055E077B for ; Mon, 4 Apr 2016 02:27:49 +0000 (UTC) Received: from [192.168.10.30] (ool-457bb23b.dyn.optonline.net [69.123.178.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: NP-Hardass) by smtp.gentoo.org (Postfix) with ESMTPSA id 42D7D340AB2 for ; Mon, 4 Apr 2016 02:27:48 +0000 (UTC) Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2016-04-10 To: gentoo-project@lists.gentoo.org References: <22264.15335.14348.781616@a1i15.kph.uni-mainz.de> <22273.23505.485029.889112@a1i15.kph.uni-mainz.de> <22273.32213.132692.773143@a1i15.kph.uni-mainz.de> From: NP-Hardass Openpgp: id=862040BE422755F27FDE13D5671C52F118F89C67; url=https://sks-keyservers.net/pks/lookup?op=get&search=0x671C52F118F89C67 X-Enigmail-Draft-Status: N1110 Message-ID: <5701D11E.8080601@gentoo.org> Date: Sun, 3 Apr 2016 22:27:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: a522513a-c8b9-49fb-ae06-65d17abf7223 X-Archives-Hash: 90c3cc1c46fd595a17a4a7f97cec22cf -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2016 06:55 PM, Rich Freeman wrote: > On Sun, Apr 3, 2016 at 4:32 PM, Ulrich Mueller > wrote: >>>>>>> On Sun, 3 Apr 2016, Rich Freeman wrote: >> >>> What project (if any) is officially responsible for the >>> creation or non-creation of Changelogs in the rsync mirrors? >>> Do they have an opinion on this matter? Would they prefer that >>> the Council make a decision? >> >>> I bring this up because this seems like the sort of thing the >>> Council typically doesn't interfere with. >> >> This concerns the Portage tree as a whole, as it is seen by a >> large fraction of users. Therefore I think it is a global issue, >> which is genuine council territory. Also the council has >> discussed this topic previously, most recently in the 20141014 >> and 20151108 meetings. >> >> From the 20141014 meeting summary: >> >> "do we need to continue to create new ChangeLog entries once >> we're operating in git?" No: blueness, creffett (proxy for ulm), >> dberkholz, dilfridge, radhermit, rich0, williamh > > Sure, but the whole point of our vote was to not create a > requirement. Per the previous Council decision there is no > requirement for Changelogs to be present, but there is also no > prohibition on them being present. > > I'm not really advocating for changing this. > >> >> Furthermore, quoting robbat2's message from March 2nd: >> >> | Either way, ~60% are in favour of getting rid of changelogs. >> >> | IMO this is a BETTER goal than continuing to generate them for >> | rsync, and bike-shedding about what the order should be; and >> it | provides a huge benefit by reducing the size of rsync by >> 155MiB. >> >> To me this sounds more like an open question than as a notice >> that infra is going to drop ChangeLogs. If the council thinks >> that such a decision is at infra's discretion then presumably we >> should make a statement to that effect. > > That works fine for me, and was basically my intent. > >> >>> Right now I'm personally inclined to vote against any >>> resolution requiring anybody to do anything simply because I >>> don't see a pressing need to impose a policy on them. I'd >>> encourage anybody who wants a repo with different/absent >>> Changelogs to just create one and let others sync it as they >>> desire. >> >> Presumably, this would imply duplicating the rsync mirror >> system? > > Sure. It has already been done once with git: > https://github.com/gentoo-mirror/gentoo.git > > I don't see why others couldn't do the same if they wished. > > In any case, I'm fine with leaving it completely up to infra. I > consider Changelogs to be nice to have, and I'm not going to force > devs to maintain them. I'm not sure how I could even force a dev > to maintain them if I wanted to. At most I could volunteer to > maintain them myself, and I don't intend to do that. However, if > somebody else wants to maintain them and feels there is a barrier > standing in their way I don't have a problem with removing that > barrier if it is reasonable to do so. > An aside: Part of the git migration was converting the cvs history to git to be available as a graft point [1][2]. Regardless of whether this is to ultimately become the canonical means of looking up a package's changelog, can we document how the graft is supposed to be done/configure the repo accordingly? I'm completely unfamiliar with git grafting, but [3] suggests that there should be an entry in .git/info/grafts. Since I'm unfamiliar with grafting, is there a reason why we don't ship the repo with this file populated to begin with ? - -- NP-Hardass [1] https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Steps [2] https://gitweb.gentoo.org/repo/gentoo/historical.git [3] https://git.wiki.kernel.org/index.php/GraftPoint -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXAdEdAAoJEBzZQR2yrxj7SroP/j7V3r7hKC/TxrxkZNwsMq5E 97Cjg0qUpjbDjzxTlCVKQHL2tc5ff3dWI9PfXPpol6mo/DMmPdiPClXGKg6ukmmh 5zGjDQ3DZHw6F1r4jINjZ6/Dp+w5k2qeLFCJnKpD25RvGldYxwlltoxVp4D7dhCn sztYEksHYqmeBx+TQTxlvfx2BCaiPk/AE2VQI4KDaETcgZv5hVrg9tMqljG45S+/ WVrB7jv4s68As6yqCbOyQkFDAi4IyoKNhJXREpV56lbS0ujvCL5fKXz2QyRGAPwi /jtTISbTMYu9xo6cCJCJwRMJxSacpip7Hv28tfUkGFKs0Taeib2q+vr1Fd29073q RfM2S0coVjZWJnlIdE0wclfDYhkv6Y2rGwBgEWxz0xatFAsQKHK0wqD8mb0q9VY8 X2Xoh6kzJ6fivoxfhHS8GkC7Wx6ir9bo9SnfaT7kV59OvL9iUbysV7MxTNMRtl9c 9NP7ozIOD5FTePyvlQGLGQChJ6px4520oGDZxxJQR/ZrENSTR29SibjMjhj6MM+T igdNnx844NP7/SJCEtRolxcwExN090Vw6pAxrYvTRBj/rJ/RkWwG+hry2OhJ717x I2ZytlrV6pe2osJXtl4adCImINnFixcLx6/rKtV+QNnrlyGSIeFqH7gkk6kki9rd mpFerByvoaMy+M1m+mWY =/1DF -----END PGP SIGNATURE-----