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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
