1 |
On Monday 13 January 2014 09:53:45 Tom Wijsman wrote: |
2 |
> On Mon, 13 Jan 2014 16:15:37 +0700 "C. Bergström" wrote: |
3 |
> > At the end of the day we have one codebase which is |
4 |
> > "engineered" and another which has "evolved". |
5 |
> |
6 |
> Too broad generalization, too much assumption; both can be held as |
7 |
> meaning nothing compared to what "engineered" and "evolved" could |
8 |
> really be, but as with doing that, it gets a subjective nature. |
9 |
> |
10 |
> In other words, the lack of context makes this statement meaningless. |
11 |
|
12 |
anyone who has spent serious time in the portage code base knows it sucks. |
13 |
i'm not blaming anyone -- it's no one's fault. portage started as prototyped |
14 |
idea that has since had more and more stuff piled onto it over the years by |
15 |
each successive maintainer. devs i've talked to agree that it sucks to work |
16 |
with. it's why pkgcore was born in the first place. |
17 |
|
18 |
i'd like to see portage & pkgcore merge, but it'd take quite a bit of work on |
19 |
the portage side to migrate step by step. we generally haven't had leads who |
20 |
have enough time sorting out the existing bugs/feature requests to try and |
21 |
also restructure/reshape things. maybe by trying to get new interest in the |
22 |
project means we can find some people willing to rip off some sizable chunks. |
23 |
the fact that the public API is pretty much non-existent is nice because it |
24 |
means we're free to change/break whatever we want. |
25 |
|
26 |
note though that the "let's rewrite everything in a branch and then merge |
27 |
later" approach doesn't work. it's been done a few times in portage land and |
28 |
aborted each time. it's rare for this to work for other projects either. |
29 |
small steps are much easier to review/merge. |
30 |
-mike |