| 1 |
Paul de Vrieze <pauldv@g.o> writes: |
| 2 |
|
| 3 |
[ ... ] |
| 4 |
|
| 5 |
> Personally I have only one issue that could be addressed. It |
| 6 |
> concerns portage. There are many features that portage will |
| 7 |
> implement someday and that have allready been identified. |
| 8 |
|
| 9 |
I might have more issues than just portage, but portage is a big |
| 10 |
one. I've made four separate attempts to "get into" portage and |
| 11 |
produce some sane patches to the code, only to give up when trying |
| 12 |
to make heads or tails of the code itself. |
| 13 |
|
| 14 |
to be blunt, one thing Zynot and Zachary Welch has going for them is |
| 15 |
the goal of rebuilding portage. I just they've learned. a clean, |
| 16 |
modular codebase as well as interchangable front- and backends would |
| 17 |
be a simple requirement. |
| 18 |
|
| 19 |
> Many of those TODO's have been there a long time. While I know that |
| 20 |
> it is necessary to keep portage stable, and I know that adding |
| 21 |
> features is much work, I would like to know the status of those |
| 22 |
> features. |
| 23 |
|
| 24 |
if you've looked at the code there is a good reason why we're not |
| 25 |
seeing a lot of developers jumping into portage. |
| 26 |
|
| 27 |
> ps. As a suggestion, I understand that current portage might need a |
| 28 |
> rewrite for parts. If it is not too straining a testing portage |
| 29 |
> might be made to accommodate such a rewrite, while maintaining the |
| 30 |
> current portage. |
| 31 |
|
| 32 |
the current portage should be modularized and documented before |
| 33 |
anything else is done to it. a test version would be a godsend, and |
| 34 |
I for one would be more than happy to contribute and test that piece |
| 35 |
of code. |
| 36 |
|
| 37 |
-- |
| 38 |
Terje |
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-dev@g.o mailing list |
Archives