On Wed, Sep 9, 2015 at 6:14 AM Ian Booth <[email protected]> wrote:
> Those workers below aren't the only ones. There's also minunits and > peergrouper > workers. > > No-one does these things on purpose. Just last week I caught and rejected > a pull > request to introduce a new worker depending on state directly. People make > mistakes. Perhaps we should introduce a test which fails if state is > imported > into any worker code. We have similar tests already for other forbidden > imports. > +1. I was thinking the same thing, and eventually that test should be increased to other packages too. On 08/09/15 17:12, William Reade wrote: > > People keep writing them, in defiance of sane layering and explicit > > instructions, for the most embarrassingly trivial tasks > > (statushistorypruner? dblogpruner? txnpruner? *all* of those can and > should > > pass through a simple api facade, not just dance off to play with the > > direct-db-access fairies.) > > > > There is no justification for *any* of those things to see a > *state.State, > > and I'm going to start treating new workers that violate layering this > way > > as deliberate sabotage attempts. Leads who have overseen the introduction > > of those workers, sort it out. > > > > > > > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
