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 |