Open Stack

On 2014-01-05 07:40:52 -0800 (-0800), Clint Byrum wrote:
[...]
> We have Oslo for algorithms, not configurations. We have global
> requirements to control external _dependencies_. This is about
> neither. Leave them in, add them when people submit them. How is
> this at all hard or controversial to just let this keep working
> the way it works now?

I think people are conflating two different "global" concepts
here...

There had been a discussion about synchronizing the .gitignore files
of all projects into one central list (a la openstack/requirements
synchronization): "global" across our entire developer community.

There were also suggestions that contributors could adjust their own
~/.gitconfig to ignore the particular trashfiles created by the
tools that they commonly use: "global" across all local git
repositories on a particular developer's computer.

The first is something which I'm pretty sure will flat out not work,
and would almost certainly annoy a great many people if we did find
enough workarounds to get it to "sort-of work." The second I see as
no different than configuring Git to know your preferred E-mail
address or OpenPGP key, but Sam was expressing a concern that we as
a project should never educate contributors about available options
for configuring their development tools.

I'm not opposed to projects adding random development tool droppings
to their .gitignore files, though I personally would prefer to just
configure my development environment to ignore those sorts of files
for any project I happen to touch rather than go on a crusade to
patch every project under the sun to ignore them.

I also disagree that they require no reviewer time... we have
release tooling which takes the patterns in .gitignore into account
so it knows to skip files which get generated as part of the build
process. A too-greedy pattern in a .gitignore file can very quickly
end in broken release tarballs if reviewers are not especially
careful to confirm those patterns match *only* what's intended
(which also means gaining confidence in the nuances of git's pattern
matcher).
-- 
Jeremy Stanley