[gentoo-portage-dev] sys-apps/portage-9999 and the repoman rewrite. Call for testers

[gentoo-portage-dev] sys-apps/portage-9999 and the repoman rewrite. Call for testers

[Brian Dolbec]

After today's release of portage-2.2.21, I merged the repoman re-write
code in to portage master branch.  So, the code is functionally
identical to portage-2.2.21 with the exception of repoman.  It is now
ready for more testing before it too is released in a normal portage
release. Please keep in mind that the current re-write code is
functionally not different the the old monolithic script. While the
code itself has been changed, The intent for this stage of the
re-write process was to not change functionality, but to break up the
code into a reasonable python structure.  In so doing some code has
naturally been improved, but this code is to be considered in an interim
state only.  There are many more changes to happen in the code base.

General plan:

Stage 1: break up the monolithic code into a reasonable python
         structure.  This included moving some code into a sudo plugin
         type system within the same class it was moved to.  This was
         in preparation for stage 2.

    *** We are here at this point.  Please test this code as it will be
    the only code patches will be accepted for from now on.  The old
    code is too different to be able to reliably rebase the rewrite
    changes on.  So, please check that any issues you find are not also
    issues in the current releases, file any new bugs tagged with the
    9999 version.  It is possible to use the new code directly from the
    portage checkout without being installed.  Just create a symlink
    from your users bin/ directory to the bin/repoman command in the
    checkout (using a slightly different name). That will allow you to
    run it from anywhere on your system your user has access to.  It
    will also let you keep your normal portage installed for performing
    most tasks. It also lets you do back to back runs one testing the
    re-write, the other, using the stable existing code to compare the
    results with.
 


Stage 2: Create proper plugin systems for various sections of the code.
         This includes one for all VCS (git, svn, hg, cvs,...) actions.
         And one for all repository checks.
         Possibly others... (to be determined).  This will also allow
         for better configurability.  And should allow easier
         addition/removal of checks.

    # After this next stage is completed it too will be merged back
    into master and a release made after suitable testing/debugging.


Stage 3: Re-factoring of the code to properly optimize it's actions,
         add a configuration file(s), and other code improvements.  It
         will be at this stage that the API's will be finalized.  It
         will include moving the results tracking of the errors,
         warnings from a simple list to namedtuple classes.  This will
         make it possible to add other front-ends to running repoman
         other than the command line interface it comes with.  This
         will mean that a Q/A website frontend could be created that
         returns the results to the pages as proper python data or
         json converted data rather than parsing stdout which can be
         buggy and need constant updates if the format changes.

Thank you :)
-- 
Brian Dolbec <dolsen>