Gentoo Archives: gentoo-project

From: Daniel Campbell <zlg@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] council meeting agenda, mar 12
Date: Mon, 13 Mar 2017 06:53:44
Message-Id: 20170313065326.GA31816@sporkbox
In Reply to: Re: [gentoo-project] council meeting agenda, mar 12 by Rich Freeman
1 On Sun, Mar 12, 2017 at 09:33:35AM -0400, Rich Freeman wrote:
2 > On Sun, Mar 12, 2017 at 1:39 AM, Daniel Campbell <zlg@g.o> wrote:
3 > >
4 > > If there's already an easy way to find council decisions like this, pardon
5 > > my ignorance.
6 >
7 > Council decisions are generally made in meetings, and posted in the
8 > summaries at:
9 > https://wiki.gentoo.org/wiki/Project:Council/Meeting_logs
10 >
11 > For whatever reason this decision was pushed a bit and is in a bug:
12 > https://bugs.gentoo.org/show_bug.cgi?id=611234
13 >
14 > Speaking personally I didn't mind voting this way since it was mostly
15 > just a re-iteration of the previous decision, and it had been hashed
16 > out on the lists.
17 >
18 > I believe it is on the agenda for today mainly to get it into the
19 > summary so that it isn't lost in bugzilla. I don't really expect much
20 > further discussion.
21 >
22 > The decision was:
23 >
24 > The council confirms its earlier decision (2014-10-14 meeting) to drop
25 > CVS headers after migration to Git.
26 >
27 > 1) Any $Id$ and $Header$ lines are to be removed from ebuilds and
28 > eclasses in the gentoo repository, as well as from other files, e.g.,
29 > metadata, profiles, and files (except patches) in FILESDIR.
30 >
31 > 2) Removal should be done at once, and a repoman check should be
32 > implemented to prevent such lines from accidentally being inserted
33 > again.
34 >
35 > 3) Infra is asked not to expand any $Id$ or other keywords, neither at
36 > rsync generation time, nor via git attributes in the development
37 > repository."
38 >
39 > --
40 > Rich
41 >
42
43 Thanks for taking the time to point readers in the right direction. I
44 did as mgorny told me last night. I found a single bug and a commented
45 out portion of code in the repoman branch of portage.git. It took some
46 digging to learn what you covered above.
47
48 The git migration happened quite a while ago, so it'll be nice to see
49 ebuilds with a little less boilerplate. What pushed the decision back so
50 far it was reconfirmed? Assuming the tooling already exists to replace
51 the functionality that was intended [1], it seems like we're due to get
52 this behind us. :)
53
54 To confirm: going forward, maintainers don't need to edit their old
55 ebuilds, but repoman will yell at you if any *new* files get added and
56 have $Id$. Do I have that right?
57
58 Thanks again for being constructive.
59
60
61 [1] I believe git can do that with some hook magic

Attachments

File name MIME type
signature.asc application/pgp-signature