On Thu, 16 Jan 2014 22:14:10 -0800 Alec Warner <anta...@gentoo.org> wrote:
> I think the point Alexander is trying to make here is also a point I
> tried to make on IRC. Many times large refactoring projects fail.
Repoman's code base is of small enough size for it to succeed for sure.
> I've tried to do them in Portage, and they have failed.
Portage is indeed quite a bit bigger, that's why I might look at that
from a software re-engineering perspective with the necessary practices
that are done in that particular field to deal with legacy code.
But, in one of the bugs I indeed have seen such a smaller attempt; if we
want to see Portage itself refactored, it will require agreement and
cooperation. Otherwise the refactoring commits would never be accepted.
Definitely we will want to look into reproducible and incremental
operations; so, we shouldn't so much send-email a huge diff, but rather
send scripted commands for review that are easier to understand. Eg.
move function1 to file1
rename functin2 to function3
...
Of course not everything can be written down that way; but the big
stuff can, and that's exactly the stuff which in the diff form would
be much harder to accept.
> I think folks are leery of this.
Yes, the more manual work of refactoring can break things; good coverage
testing can help keep this minimal, I see Portage has quite some tests
which is a good thing but I'm not sure how well they cover Portage.
> We are often more comfortable with incremental changes. That means
> one change at a time; portage is large ship and I don't think anyone
> is under the impression that portage will 'turn on a dime.'
The only thing I like to see here is that these small incremental
changes work towards a good design; there's a difference between doing
it just because you can and doing it on purpose.
> What I think we are trying to avoid, is changes that go in the
> opposite direction.
"Yes, we will not sail there; but where do we go to instead?"
> Generally one of the first things you decide to do when you want to
> clean something up is to stop making new messes. I think that is the
> logic we are trying to convey here.
Your first comment was clear to me, I didn't object to putting it in a
function. But anything more than that needs a proper discussion, as just
creating a random file and putting it in there is a mess as well. :)
(My response was based on that I _want_ to refactor it, hence the care)
> I'm not really following this part of the conversation. Speaking has
> someone who has tried the grand refactoring of portage; it has not
> worked well for me in the past.
What caused trouble doing this?
> Incremental changes are easier to get accepted, they get released
> more often, they are tested faster, and so forth.
A refactor attempt can be planned to be done in incremental steps.
> > > Sebastian even *told* you specifically how to do this properly.
> >
> > I think he was referring to the feedback that Sebestian gave on the
> > thread later on. I recommend you consider incorporating
>
> the feedback into your patch.
>
> I think he was referring to the feedback that Sebastian gave you on
> the thread later on.
The feedback has no mention of what is referred to as far as I can see.
> Look, I realize Alexander (and probably myself) didn't have a great
> tone; but I thought Sebastian's feedback was pretty useful. Is there
> some reason you wouldn't want to incorporate it?
It is incorporated in v2 of the patch.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
