[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] PyArch status update

From: David Allouche
Subject: [Gnu-arch-users] PyArch status update
Date: Wed, 24 Mar 2004 17:07:53 +0100
User-agent: Mutt/

Since PyArch was recently mentioned on this mailing-list, I remembered
to merge some pending changes and make a public status update.

Pyarch Code

Johannes Berg has implemented a native NameParser which dramatically
improves performance compared to using "tla parse-package-name" and "tla
valid-package-name" for usage patterns involving a lot of archive

He also implemented a support for traversing the output of "tla merges"
with nested iterators.

I have mostly rewritten the new NameParser to make it faster and more
elegant. I have also made the code PyChecker clean, that helped fix a
lot of dormant bugs and ugliness.

Johannes implementation of "merge" inspection is useful for depth-first
traversal but buggy for breadth-first traversal. I have a more correct
and more generic implementation in the works, but I want to be able to
test it with the test suite before releasing it[1].

To that end, test suite (initially contributed by Ben Burns) was heavily
modified to make it cleaner and more correct. I have started adding
features and test cases to create WorkingTree (arch sandboxes) so I
could eventually implement test cases for Version.iter_merges().

    [1] if there is a public demand for this code, I could put it in a
        micro-branch in the meantime.

Help Wanted

Since the test suite is still quite small, it will be a lot of work
before I can validate my new Version.iter_merges() implementation.
Contributions to help it get there are greatly appreciated: test cases
are needed for "commit", "tag" and "star-merge".

Complete test cases and extra functionality needed for the test cases
(the commit support is still _very_ basic) are preferred.

Development Process

There have been a sudden spur of interest for PyArch when Johannes
started working on its graph tool (in his pyarch-contrib branch). To
preserve a clean star-topology I have decided to set-up pyarch--devo
branch in my archive to serve as star-trunk. It will get contributed
patches and changes with little latency and little scrutiny.

    Development branch.

    Get contributed changes quickly with little scrutiny.
    Intended as a community trunk version, caveat emptor, so developers
    will be able to share new patches while preserving a clean star
    topology even when I have little time to spare on PyArch.

    My personal development branch

    The merging policy with devo is not clearly defined yet, but the
    focus of this branch is maintaining high quality standards more than
    getting the latest feature.

In order to maintain a high code quality, all contribution to devo
should be PyChecker-clean (use the ./ script for that) and come
with test cases (in the ./ script), if only I had used
Pychecker before... (sight)

                                                            -- ddaa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]