Open Stack

On 2014-01-10 21:57:33 +1300 (+1300), Robert Collins wrote:
> I have *no* aversion to allowing contributors to police things on
> their own.
[...]

I know you don't. It was stated in the message I was replying to (in
context you trimmed) that "...the community should not accept or
promote any policy which suggests a configuration that alters the
behavior of systems beyond the scope of a local workspace used while
working with OpenStack..." I disagree, and think we as a collective
of individuals should feel free to exchange tips and suggestions on
configuring our development environments even if they may have
(potentially positive) implications outside of just work on
OpenStack code.

> If we have to review for a trashfile pattern then we have
> contributors using that. There are more editors than contributors
> :).
[...]
> I don't understand why you call it polluting. Pollution is toxic.
> What is toxic about the few rules needed to handle common editors?

For me, the ignore list is there so that someone doesn't have to
worry about accidentally committing *.o files because they ran make
and forgot to make clean when they were done. I'm less keen on it
being used so that developers don't need to know that visual studio
is leaving project directories all over the place.

Anyway I was using the term "polluting" more in reference to
accidentally committing unwanted files to the repository, and only
to a lesser extent inserting implementation details of this week's
most popular code flosser. How do you determine when it's okay to
clean up entries in the ever-growing .gitignore file (that one
person who ran a tool once and added pattern for it has moved on to
less messy choices)? A file with operational implications which
grows in complexity without bounds worries me, even if only in
principle.

Anyway, it's not a huge deal. I'm just unlikely to review these
sorts of additions unless I've really run out of actual improvements
to review or bugs to fix. (And I already feel bad for wasting time
replying to several messages on the topic, but I couldn't let the
"should not...promote any policy which suggests a configuration that
alters the behavior of systems" comment go unanswered.)
-- 
Jeremy Stanley