warnera6 wrote:
It was my understanding that large patches to portage were not to
receive great consideration due to just that, regressions and bugs. Why
break something that is proven? I will agree that emerge is a huge
piece, I've torn it apart more than once. However it currently does the
job, so I don't see a point in rewriting it unless there is : a) an
immediate benefit for users, and b) some sort of way to gaurantee a
problem free update.
I don't see a), they get prettier code to look at, but I wouldn't want
people writing code against emerge.
b) is hard to do, even if it's just function and variable re-organizing,
it's 2000 lines of code that has a lot of interaction and there are
going to be bugs.
a) Probably not much benefit, unless it helps us to recognize and fix subtle
bugs (not sure if there are any, in emerge at least).
b) Like I said, based on my analysis, I believe it can be done quickly and
painlessly, without regressions.
I just don't see the worth of it. Why rewrite the front-end when the
backend isn't done?
Again, no benefit unless it helps to fix bugs. I want to emphasize that I have not
suggested a "rewrite" per se, but only a quick reorganization.
Not to mention you can upgrade the code here, and then upgrade it again
to the new portage API in 2.1, since I would guess many calls are being
refactored and rewritten to be object oriented.
In the end nothing I say really matters, if you want to do the
refactoring I certainly can't stop you, I just don't think it's worth it
to rewrite at this time ;)
I certainly don't want to it if there's no benefit. ;-)
Zac
--
[email protected] mailing list
