1 |
Hello, |
2 |
|
3 |
A better method to review code? |
4 |
|
5 |
I find myself having to audit the code inside |
6 |
of ebuilds in order to understand how a given |
7 |
piece of code has been changed. |
8 |
|
9 |
So what I do is go to the /usr/portage/distfiles |
10 |
and then use vi to look at the file listing; |
11 |
move up and down to select the file of interest |
12 |
and then enter the file (yes from inside of vi). |
13 |
Not very elegant, but does not require unpacking the |
14 |
files. |
15 |
|
16 |
Definitely not the best approach, but, I do not |
17 |
want the unpack the sources, most of the time. |
18 |
Suggestions as to a better quick approach for reviewing sources? |
19 |
|
20 |
If I want to unpack the sources and modify |
21 |
some code, what would be the recommended semantics? |
22 |
Maybe make a dir under /usr/local and open the packages |
23 |
as James-overlay(package), modify the code, install it |
24 |
and test? (What do the "Titans of code" do?) |
25 |
|
26 |
Maybe use/hack my own slot numbers? |
27 |
Any guidance or dev documents as to how most |
28 |
G_devs do this is of keen interest to me. |
29 |
I'm looking for a (proper) methodology to start cleaning |
30 |
up some codes that are neglected. Surely there |
31 |
is a preferred methodology? |
32 |
|
33 |
|
34 |
|
35 |
James |