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: