1 |
On Thu, 16 Jan 2014 22:14:10 -0800 |
2 |
Alec Warner <antarus@g.o> wrote: |
3 |
|
4 |
> I think the point Alexander is trying to make here is also a point I |
5 |
> tried to make on IRC. Many times large refactoring projects fail. |
6 |
|
7 |
Repoman's code base is of small enough size for it to succeed for sure. |
8 |
|
9 |
> I've tried to do them in Portage, and they have failed. |
10 |
|
11 |
Portage is indeed quite a bit bigger, that's why I might look at that |
12 |
from a software re-engineering perspective with the necessary practices |
13 |
that are done in that particular field to deal with legacy code. |
14 |
|
15 |
But, in one of the bugs I indeed have seen such a smaller attempt; if we |
16 |
want to see Portage itself refactored, it will require agreement and |
17 |
cooperation. Otherwise the refactoring commits would never be accepted. |
18 |
|
19 |
Definitely we will want to look into reproducible and incremental |
20 |
operations; so, we shouldn't so much send-email a huge diff, but rather |
21 |
send scripted commands for review that are easier to understand. Eg. |
22 |
|
23 |
move function1 to file1 |
24 |
rename functin2 to function3 |
25 |
... |
26 |
|
27 |
Of course not everything can be written down that way; but the big |
28 |
stuff can, and that's exactly the stuff which in the diff form would |
29 |
be much harder to accept. |
30 |
|
31 |
> I think folks are leery of this. |
32 |
|
33 |
Yes, the more manual work of refactoring can break things; good coverage |
34 |
testing can help keep this minimal, I see Portage has quite some tests |
35 |
which is a good thing but I'm not sure how well they cover Portage. |
36 |
|
37 |
> We are often more comfortable with incremental changes. That means |
38 |
> one change at a time; portage is large ship and I don't think anyone |
39 |
> is under the impression that portage will 'turn on a dime.' |
40 |
|
41 |
The only thing I like to see here is that these small incremental |
42 |
changes work towards a good design; there's a difference between doing |
43 |
it just because you can and doing it on purpose. |
44 |
|
45 |
> What I think we are trying to avoid, is changes that go in the |
46 |
> opposite direction. |
47 |
|
48 |
"Yes, we will not sail there; but where do we go to instead?" |
49 |
|
50 |
> Generally one of the first things you decide to do when you want to |
51 |
> clean something up is to stop making new messes. I think that is the |
52 |
> logic we are trying to convey here. |
53 |
|
54 |
Your first comment was clear to me, I didn't object to putting it in a |
55 |
function. But anything more than that needs a proper discussion, as just |
56 |
creating a random file and putting it in there is a mess as well. :) |
57 |
|
58 |
(My response was based on that I _want_ to refactor it, hence the care) |
59 |
|
60 |
> I'm not really following this part of the conversation. Speaking has |
61 |
> someone who has tried the grand refactoring of portage; it has not |
62 |
> worked well for me in the past. |
63 |
|
64 |
What caused trouble doing this? |
65 |
|
66 |
> Incremental changes are easier to get accepted, they get released |
67 |
> more often, they are tested faster, and so forth. |
68 |
|
69 |
A refactor attempt can be planned to be done in incremental steps. |
70 |
|
71 |
> > > Sebastian even *told* you specifically how to do this properly. |
72 |
> > |
73 |
> > I think he was referring to the feedback that Sebestian gave on the |
74 |
> > thread later on. I recommend you consider incorporating |
75 |
> |
76 |
> the feedback into your patch. |
77 |
> |
78 |
> I think he was referring to the feedback that Sebastian gave you on |
79 |
> the thread later on. |
80 |
|
81 |
The feedback has no mention of what is referred to as far as I can see. |
82 |
|
83 |
> Look, I realize Alexander (and probably myself) didn't have a great |
84 |
> tone; but I thought Sebastian's feedback was pretty useful. Is there |
85 |
> some reason you wouldn't want to incorporate it? |
86 |
|
87 |
It is incorporated in v2 of the patch. |
88 |
|
89 |
-- |
90 |
With kind regards, |
91 |
|
92 |
Tom Wijsman (TomWij) |
93 |
Gentoo Developer |
94 |
|
95 |
E-mail address : TomWij@g.o |
96 |
GPG Public Key : 6D34E57D |
97 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |