[arch-dev-public] towards namcap 2.8
dpmcgee at gmail.com
Fri Jan 28 14:39:35 EST 2011
On Tue, Jan 25, 2011 at 8:50 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Tue, Jan 25, 2011 at 5:11 PM, Rémy Oudompheng
> <remyoudompheng at gmail.com> wrote:
>> Following an earlier discussion, I have stepped forward as a volunteer
>> to continue namcap maintenance: in my personal clone at
>> you may find several patches addressing issues reported in FlySpray. I
>> have also tried to update the NEWS file in some sensible way. Can
>> someone have a look at these? I'd also like to know more about the
>> release process of namcap and the main directions of development?
>> My next goal would be the support for split packages.
> Thanks Rémy.
> I'll take a look in the near future and give you feedback; I'm out of
> town this week without a lot of time on my hands. I'll also try to
> fill you in on the typical release steps I've taken for the past few
> tags and cuts of code. I'll also give you a TODO list I've had in my
> head for a while of things that would make namcap a much better system
The work you did looks good; no obvious problems seen in any of it.
I've actually merged it to master.
* Make changes
* Get to a point where there are enough to release
* Update setup.py as necessary
* `python2 setup.py sdist`
* Create tag in git (make sure you use `git tag -a`)
* Push tarball to /srv/ftp/other/namcap/
* Rebuild package
* Make this a python3 project- since Arch is rather bleeding edge
anyway and this is Arch-specific, it is a perfect candidate for moving
forward. Some things have already been tweaked, but things like octal
literals, etc. need work.
* Add a test suite.
* Overhaul the way we process rules. Right now, they are done in
serial fashion. This makes processing more rules add a lot to the
runtime for tarball type rules. It is less noticeable now since we
force unzip each package, but try running without the wrapper script.
Instead, since most of these simply do something as we iterate over
either the file names or file objects, make it callback-based. Namcap
would then iterate through the package contents only once, calling the
rule callbacks on each object, resulting in a much faster per-package
* This has been done, I can't remember where though, but making it
secure enough to actually run it on every package and PKGBUILD in our
repos would be awesome, and then showing this info in a web interface.
Looks like it is mentioned here at the bottom:
You ready to take it over? It's all yours.
More information about the arch-dev-public