Gentoo Archives: gentoo-portage-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Re: Re: Refactoring of emerge code
Date: Tue, 09 May 2006 17:37:00
In Reply to: Re: [gentoo-portage-dev] Re: Re: Refactoring of emerge code by m h
2 Hash: SHA1
4 m h wrote:
5 > Fair enough, if the trunk is frozen, I wish that would have been
6 > indicated to me. No one has said that yet. The patches don't add any
7 > functionality per se, but could be seen as bug fixes for
8 > sloppy/extraneous code ;)
9 >
10 > Again, this isn't supposed to be taken in the wrong way. I'm coming
11 > from the point of view of a lurker of normal gentoo (and
12 > user/psuedo-dev of the prefix branch (which is based on 2.1)) I
13 > appreciate the clarification you've provided Duncan. Again, if 2.1 is
14 > just throw-away code, then perhaps code cleanup refactoring is a waste
15 > of effort, but I don't think it is....
17 Once I also did some emerge refactoring [1]. Unfortunately, my patch was against the dead 2.1-experimental (ebd) branch [2]. I should have chosen the 2.0.x branch at the time but I didn't know any better because that was when I first got involved with the portage team (I was still a python newbie at the time).
19 Although it's too late to do any really significant refactoring in the 2.1 branch, emerge can still be refactored for later releases. Right now most of the focus is on stabilizing 2.1 for the 2006.1 release, but we can break off a development branch as soon as it becomes necessary. One other thing to keep in mind is that other projects (pkgcore and paludis) are competing to make the current portage codebase obsolete. If a competitor is able to become a "drop-in" replacement for portage, then the next major branch after 2.1 may not survive long enough to become stable.
21 Zac
23 [1]
24 [2]
26 Version: GnuPG v1.4.3 (GNU/Linux)
29 WsSlN3v9+b421YHX09uokvk=
30 =HJpr
31 -----END PGP SIGNATURE-----
32 --
33 gentoo-portage-dev@g.o mailing list