1 |
After today's release of portage-2.2.21, I merged the repoman re-write |
2 |
code in to portage master branch. So, the code is functionally |
3 |
identical to portage-2.2.21 with the exception of repoman. It is now |
4 |
ready for more testing before it too is released in a normal portage |
5 |
release. Please keep in mind that the current re-write code is |
6 |
functionally not different the the old monolithic script. While the |
7 |
code itself has been changed, The intent for this stage of the |
8 |
re-write process was to not change functionality, but to break up the |
9 |
code into a reasonable python structure. In so doing some code has |
10 |
naturally been improved, but this code is to be considered in an interim |
11 |
state only. There are many more changes to happen in the code base. |
12 |
|
13 |
General plan: |
14 |
|
15 |
Stage 1: break up the monolithic code into a reasonable python |
16 |
structure. This included moving some code into a sudo plugin |
17 |
type system within the same class it was moved to. This was |
18 |
in preparation for stage 2. |
19 |
|
20 |
*** We are here at this point. Please test this code as it will be |
21 |
the only code patches will be accepted for from now on. The old |
22 |
code is too different to be able to reliably rebase the rewrite |
23 |
changes on. So, please check that any issues you find are not also |
24 |
issues in the current releases, file any new bugs tagged with the |
25 |
9999 version. It is possible to use the new code directly from the |
26 |
portage checkout without being installed. Just create a symlink |
27 |
from your users bin/ directory to the bin/repoman command in the |
28 |
checkout (using a slightly different name). That will allow you to |
29 |
run it from anywhere on your system your user has access to. It |
30 |
will also let you keep your normal portage installed for performing |
31 |
most tasks. It also lets you do back to back runs one testing the |
32 |
re-write, the other, using the stable existing code to compare the |
33 |
results with. |
34 |
|
35 |
|
36 |
|
37 |
Stage 2: Create proper plugin systems for various sections of the code. |
38 |
This includes one for all VCS (git, svn, hg, cvs,...) actions. |
39 |
And one for all repository checks. |
40 |
Possibly others... (to be determined). This will also allow |
41 |
for better configurability. And should allow easier |
42 |
addition/removal of checks. |
43 |
|
44 |
# After this next stage is completed it too will be merged back |
45 |
into master and a release made after suitable testing/debugging. |
46 |
|
47 |
|
48 |
Stage 3: Re-factoring of the code to properly optimize it's actions, |
49 |
add a configuration file(s), and other code improvements. It |
50 |
will be at this stage that the API's will be finalized. It |
51 |
will include moving the results tracking of the errors, |
52 |
warnings from a simple list to namedtuple classes. This will |
53 |
make it possible to add other front-ends to running repoman |
54 |
other than the command line interface it comes with. This |
55 |
will mean that a Q/A website frontend could be created that |
56 |
returns the results to the pages as proper python data or |
57 |
json converted data rather than parsing stdout which can be |
58 |
buggy and need constant updates if the format changes. |
59 |
|
60 |
Thank you :) |
61 |
-- |
62 |
Brian Dolbec <dolsen> |