[Top][All Lists]

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

[Octave-bug-tracker] [bug #39479] 'pkg -forge list' takes 56.5 seconds

From: Mike Miller
Subject: [Octave-bug-tracker] [bug #39479] 'pkg -forge list' takes 56.5 seconds
Date: Fri, 22 Mar 2019 19:59:54 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36

Follow-up Comment #22, bug #39479 (project octave):

Andrew - I agree on all of your points for improvements, and have even more,
and could probably be broken up into several distinct projects that could be
worked on independently and incrementally.

Package Installation - This seems like the topic that Packajoozle is mainly
addressing. This covers the `pkg` or `pkj` function itself, the options, the
downloading of packages, the handling of metadata, building, handling
dependencies, etc. I'd include the serve-side package repository details here
too. I think you've got that well covered.

Package Quality - This covers what you touched on in comment #20, fixing
packages and making sure they pass their tests, but could be expanded a lot.
Do packages build, install, have tests, do the tests pass, do they have demos,
do they have help strings, do the help strings have examples, etc. I can see a
lot of room for improvement in automating these kinds of checks, doing package
linting, auditing, and so on. This is on my mind since we have a large backlog
of unreleased Forge packages right now, and I recently proposed that we try to
do peer review to help distribute the package QC workload, and I think this
could be automated and streamlined a lot. I do intend to do some work on this

Package Building / Maintenance - There was a thread recently about the
downsides of the makefile system Octave Forge packages currently use for
routine maintenance tasks. Someone mentioned the rust cargo command, and
having something like that for Octave packages might be an interesting
project. A set of commands for turning a directory, git repo, or hg repo into
a package, probably available as a package itself. This would take over all
the tasks that the top-level maintainer's makefile does right now, including
running tests from the developer side, running CI tests, running doctest,
running QA checks, making the tarball the right way, building the HTML docs,
running a package against multiple versions of Octave if they are available,
stuff like that.


Reply to this item at:


  Message sent via Savannah

reply via email to

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