Re: [gentoo-project] Re: Call for agenda items - Council meeting 2016-04-10

[NP-Hardass]

-----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 <ulm@g.o>
> 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-----