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