Open Stack

I believe my comment may have been [slightly] misinterpreted. I was simply saying that we shouldn't assume that contributors are allowed to alter their global configuration. When deciding on a policy for ignoring files, we should be careful to choose a policy that does not prevent those users from participating just as easily as users who are able to alter their global configuration.

The implication of this is that users who sit down to read a guide about getting started with making contributions to OpenStack shouldn't find instructions in it like "Add the following lines to ~/.gitignore...".

Sam

-----Original Message-----
From: Jeremy Stanley [mailto:fungi at yuggoth.org] 
Sent: Friday, January 10, 2014 9:10 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore

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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev