[11:16] <Keybuk> morning Marco
[11:17] <AlexExtreme> Keybuk: what did you use to create the graph on http://wiki.ubuntu.com/ReplacementInitscripts ?
[11:19] <Keybuk> dot
[11:19] <Keybuk> from the graphviz package
[11:19] <Keybuk> http://people.ubuntu.com/~scott/feisty.dot
[11:20] <AlexExtreme> cool, thanks
[11:20] <Keybuk> (note, that's a text file, not an OpenOffice document <g>)
[11:20] <AlexExtreme> yeah :)
[11:24] <AlexExtreme> bbl
[11:30] <Keybuk> Md: I guess you saw kay's lkml post about merging some of modprobe into udev?
[11:32] <Md> Keybuk: not yet
[11:39] <Keybuk> ah
[11:39] <Keybuk> it's in the thread BenC started about making it possible to move some of the device/driver binding decisions to userspace
[11:40] <Keybuk> Md: no major changes of consequence in our m-i-t patch; just our usual two extra patches (silence modprobe & combine modprobe.conf/modprobe.d automatically)
[11:41] <Keybuk> I suspect we'll be dropping the silence one now that we want verbose log messages by default
[12:15] <Md> can you tell me the thread title?
[12:17] <_ion> A nice graph.
[12:17] <Keybuk> [RFC]  Pushing device/ddriver binding decisions to userspace
[12:17] <Keybuk> Kay's comment in that
[06:52] <Keybuk> *yawn*
[06:54] <AlexExtreme> *yawn* too
[06:54] <Keybuk> I've almost finally finished merges
[06:54] <Keybuk> just sysvinit to go
[06:54] <Keybuk> that'll be fun
[06:54] <AlexExtreme> i'm trying to find something to code, which is usually a signal that i'm bored ;)
[06:55] <AlexExtreme> merges of what?
[06:55] <Keybuk> Debian changes into Ubuntu
[06:55] <Keybuk> it's the blackhole of developer time in the first few weeks of our release cycle
[06:56] <AlexExtreme> ah
[06:56] <AlexExtreme> ok
[06:56] <AlexExtreme> i'm going to get some food
[06:56] <AlexExtreme> bbl
[11:21] <Keybuk> wasabi: hey
[11:55] <Keybuk> so I thought about things a bit
[11:55] <Keybuk> I'm convinced that the eight-step state machine is correct
[11:55] <Keybuk> but think you're right that the events aren't
[11:56] <Keybuk> especially as the state machine is more complex, you could end up being started by an event but needing to list two or three stop events, depending on the path through the state machine
[11:56] <Keybuk> so...
[11:56] <Keybuk> keeping the eight states (but renamed a bit, to make more sense)
[11:56] <Keybuk> but only having four events
[11:56] <Keybuk> start (or starting?) when the goal is set to start, started once the entire process of starting is complete
[11:56] <Keybuk> stop (or stopping?) when the goal is set to stop, stopped once the entire process of stopping is complete
[11:57] <Keybuk> that should fulfil all the use cases I had
[11:57] <_ion> Where is the spec about this 8-step state machine?
[11:57] <Keybuk> _ion: http://upstart.ubuntu.com/wiki/JobStates
[11:57] <Keybuk> so, the interesting thing about the start and stop events ...
[11:57] <_ion> "starting" and "stopping" make sense
[11:57] <_ion> Thanks.
[11:58] <Keybuk> the "start" and "stop" commands can then just generate those events
[11:58] <Keybuk> and only once those events are handled, begin the process of starting the job
[11:59] <Keybuk> so if tomcat had "stop on stop apache"
[11:59] <Keybuk> then tomcat would be fully stopped before apache began stopping
[12:08] <Keybuk> anyhoo, bed