[MERGE][RFC] Enhanced hooks
Monty Taylor
monty at inaugust.com
Wed Feb 6 14:48:05 GMT 2008
John Arbash Meinel wrote:
> Actually, for some, branch.conf represents lower cost. Specifically
> thing a large company with a lot of branches wanting to enforce some
> company policy.
> To go one step further, how about "encourage" company policy. They could
> always get around it, but the point is to *help* them do the right thing.
>
> That is actually one of the reasons Monty wanted to put the config files
> in .bzr-<plugin>/default.conf or possibly .bzr-plugins/plugin.conf
Yes - but also the reason that my approach is specifically for plugin
config that still requires plugins to be installed _and_ configured as
trusted plugins. I feel pretty strongly that I _don't_ want hooks to
come along with a branch that might execute without me knowing about it.
> Consider, one solution would be to require hooks to be gpg signed, and
> then give a list of keys that you are willing to trust the hooks. It
> would be possible, but it really starts adding a lot of complexity. I
> think it is far easier to have someone install the "site-configuration
> for company Foo" plugin.
Yes - and in my company where we are trying to roll out bzr as a
replacement for things, people are not rebelling against that. In fact,
we tell them to just bzr branch the company plugins into their plugin
dir, and occasionally we can tell them to update the company plugin. Of
course, I think it was suggest to write a hook in the company plugin
that goes and checks to make sure the user has the latest company plugin
version and bails out until they install it...
Monty
PS. Haven't gotten a chance to fix the plugin config patch yet... :)
More information about the bazaar
mailing list