On Sat, 2010-08-07 at 07:58 -0400, Daniel Shahaf wrote:
> Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200:
> > On 07.08.2010 12:44, Daniel Shahaf wrote:
> >> If corporations want to have configuration override, fine.
> >>
> >> But I want a way to disable that completely. I don't necessarily want to
> >> allow a random sourceforge repository to control my auto-props settings for
> >> a wc of that repository.
> >
> > Maybe a stupid question: why not?
>
> Why don't I let ezmlm configure my mailer's "use html?" setting?
I think he was asking for an answer specifically relating to auto-props,
not an answer about configuration in general. There's not generally a
lot of room for individual disagreement about what auto-props should be
for a given project.
My thinking about repository configuration is that the uses cases should
be divided into two categories:
1. Stuff that isn't really client configuration at all, like
auto-props, should come from the repository instead, and should only
come from client configuration for compatibility.
2. Stuff that is client configuration should only come from client
configuration. Client control is not legitimate business for an open
source product, though it could be the business of a proprietary
value-added fork.
Note that there's no general extension of the config framework here, no
whitelisting or blacklisting, no override settings. Invent a mechanism
for getting repository configuration from the server and apply it to the
specific use cases in (1), falling back to client configuration as a
legacy mechanism.
Received on 2010-08-07 18:19:01 CEST