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

Re: FTPTeam: Programming fun task available



[I'm not on the list; please include me in replies]

Hi,

On Thu, Oct 14, 2010 at 12:26:00AM +0200, Joerg Jaspert wrote [edited]:
> meeting at [1] is number 13. "dinstall replacement". Even though it is
[..]
>  1. reads in the scripts
>  2. computes the optimal scheduling
>  3. outputs a list of processing steps, each step containing a list of
>  tasks that can be run in parallel.

As discussed on irc, I'd work on this, so here's the first cut:

    http://people.debian.org/~sez/dinstall.tgz

It implements the above functionality but not yet in a usable way -- no point
until there's proper dak integration. In fact the script itself doesn't do
anything at all, try tests.py instead.

Here's a brief overview.

- the Script class has the generic properties of a script, ie. those that
  apply to all invocations of the script
- a ScriptJob, or simply job, is a concrete instance of a script
- a job set is a collection of jobs that belong to the same state machine

The job set FSM is parsed by the ScriptsDefinition class. The input format is
pretty much like ganneff's example, except that fields are colon-separated
(should pull data from the db instead?).

The idea is that job sets are instantiated against a given FSM, along with
some job-set-specific parameters, such as the job set id, and the archive
value. This will obviously have to be extended for real script arguments (eg.
a .changes file).

As requested, the script implements priorities, dependencies,
at-least-one-of-many dependecies (a|b|c), and conditional dependencies (a,b if
archive==x).

Every job knows its reverse dependencies. Given that, I haven't worried much
about complexity (I assume that the number of jobs in individual FSMs is
small) but there's space for improvement if necessary.

Cheers,
Serafeim


Reply to: