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

Re: FTPTeam: Programming fun task available



>> 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

Thats a git repo inside a tarball. You could make it easier and just
provide it as a git repo. :)

> 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.

Good start. I dont have much time today to look in detail, and its much
more complex for just a 2 minute review, so only some remarks right now.

> - 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?).

Well. We can end up in two ways:
1) the information is read out of the database
2) each script has the information about itself, what it provides,
   depends, priority. They are then linked into a directory, and
   "dinstall" looks into that dir, and from all links figures out in
   which order it runs them. (Hello init system once more :) )
Though database does seem to be nicer.

> 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).

If you look into cron.dinstall you will see that there is only one
function ever taking arguments. So I dont think we need to bother too
much for that (if it doesn't cost much to do, then fine)


-- 
bye, Joerg
[...]that almost anything related to "intellectual property" is idiotic
by it's nature, [...]


Reply to: