| 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> |
Archives