On 05/16/2011 03:07 PM, Martin Sivak wrote:
Again, this looks like it will work, but it requires lot of scrolling and reading to understand how it operates. Better documentation would be helpful, have you considered writing docs/dispatch.txt to document the design decisions? Also, see the comments in the code.
I added comments in the code.
You should state somewhere around schedule/skip/, that they are not to be used outside of dispatch to ensure the history tracking works.
You inspired me to fix this whole problem by moving the tracking from
dispatch into the steps. When a step is rescheduled it receives the step
that should track the change as an argument. Some stuff could be removed
this way.
+ return self._reschedule(self.SCHED_SKIPPED)
This method does no tracking, it only records information passed from somewhere outside. So it should be documented what values are to be passed in, their effect. The name could be changed too probably, either to track_scheduling to match the method from dispatch or maybe to for example record_history?
Renamed to record_history.
You access most of the Step internals using properties and methosd.. why the direct access to changes here?
Defined as property. I'm sending the patch again.
Ales
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
