Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
Robert Collins wrote: >>> I read that as 'we don't test that our tarballs work'. No? >> >> We don't test that changes won't break our tarballs in some ways, >> no. I suppose we could add new jobs to generate throwaway tarballs >> and then re-run all other tests using source extracted from those in >> addition to the source obtained from the VCS, but that's probably >> duplicating a lot of the current tests we run. Could be worthwhile >> to explore anyway. > > I'd be very keen to see *something* test that our tarballs work and > meet some basic criteria (such as perhaps we want to guarantee a > ChangeLog is actually in each tarball...) FWIW: As part of the milestone release process I run a script which verifies that the tarball matches the git repository content (script displays the diff for the human to check it's sane). It used to catch a lot of errors (missing files in MANIFEST.in) but since we use pbr there weren't any missing file anymore. The publication scripts also check that the tarball is not corrupted (tar ztvf) before uploading it. Ref: https://wiki.openstack.org/wiki/Release_Team/How_To_Release We can certainly improve the tests but the tarballs are not completely untested :) -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 2014-01-11 03:38:05 + (+), Sam Harwell wrote: > I believe my comment may have been [slightly] misinterpreted. Sorry about that! The wording seemed unnecessarily proscriptive. > 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. I agree that's reasonable, and we should avoid making it hard for anyone to commit whenever we can do so. > 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...". True, but the documentation could say, "You should avoid accidentally committing autosave/backup and similar sorts of files left behind by your development tools, and here are several possible ways to do help ensure that..." -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
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:fu...@yuggoth.org] Sent: Friday, January 10, 2014 9:10 PM To: openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 11 January 2014 15:39, Jeremy Stanley wrote: > On 2014-01-10 22:00:40 +1300 (+1300), Robert Collins wrote: > [...synchronized .gitignore across all projects...] >> Out of curiousity, why wouldn't it work? > > The example I gave earlier in the thread... one project wants > autogenerated ChangeLog so it's in their .gitignore but another > project wants a hand-curated ChangeLog so they commit it to the > repository. The two projects can't share a common .gitignore file as Yes they can. Ignore ChangeLog in .gitignore, the added one will override .gitignore and it's all fine. > a result. There are almost certainly other examples, that's just the > first to spring to mind. Could work around it by dynamically > proposing semi-synchronized .gitignore updates based on a number of > other preferences expressed individually by each project, but this > seems like overengineering. There *may* be some examples, but we don't have one yet :). > Do you have a recommendation for a canned .gitignore which safely > covers the files left behind by most free software editors, IDEs, > debuggers, test tools, et cetera? Something we should incorporate > into a recommended initial list in openstack-dev/cookiecutter's > template perhaps? I've added putting one together to my todo list. >> I read that as 'we don't test that our tarballs work'. No? > > We don't test that changes won't break our tarballs in some ways, > no. I suppose we could add new jobs to generate throwaway tarballs > and then re-run all other tests using source extracted from those in > addition to the source obtained from the VCS, but that's probably > duplicating a lot of the current tests we run. Could be worthwhile > to explore anyway. I'd be very keen to see *something* test that our tarballs work and meet some basic criteria (such as perhaps we want to guarantee a ChangeLog is actually in each tarball...) -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 2014-01-10 22:00:40 +1300 (+1300), Robert Collins wrote: [...synchronized .gitignore across all projects...] > Out of curiousity, why wouldn't it work? The example I gave earlier in the thread... one project wants autogenerated ChangeLog so it's in their .gitignore but another project wants a hand-curated ChangeLog so they commit it to the repository. The two projects can't share a common .gitignore file as a result. There are almost certainly other examples, that's just the first to spring to mind. Could work around it by dynamically proposing semi-synchronized .gitignore updates based on a number of other preferences expressed individually by each project, but this seems like overengineering. > *everyone* I know gets git's preferred email and gpg config wrong to > start with. Recent gits make this explicit by refusing to work in a > broken fashion. I see having common defaults in trees as an analogous > thing - rather than beating people up when they got it wrong, make it > harder for them to get it wrong. Do you have a recommendation for a canned .gitignore which safely covers the files left behind by most free software editors, IDEs, debuggers, test tools, et cetera? Something we should incorporate into a recommended initial list in openstack-dev/cookiecutter's template perhaps? [...adding my preferred tool dotfiles to every project...] > This is another strawman, no? Is anyone suggesting a crusade? If this is recommended as the preferred solution over me just configuring my computer to not commit these files, then yes. Each time I commit a change to another project, I'll need to propose an additional .gitignore change to cover whatever files my own oddball tool choices leave lying around in the repo. I still don't understand what's hard to get right about customizing your development environment, but trying to make this "easier" for people new to software development and doing it in inconsistent ways (some projects going out of their way to hide those file patterns, others not) strikes me as a recipe for *more* confusion, not less. However, I don't feel strongly about this one way or another, and was mainly responding to the previous objection that we as a project should never make development environment configuration recommendations to contributors. > I read that as 'we don't test that our tarballs work'. No? We don't test that changes won't break our tarballs in some ways, no. I suppose we could add new jobs to generate throwaway tarballs and then re-run all other tests using source extracted from those in addition to the source obtained from the VCS, but that's probably duplicating a lot of the current tests we run. Could be worthwhile to explore anyway. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 6 January 2014 05:18, Jeremy Stanley wrote: > 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 Out of curiousity, why wouldn't it work? > 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. *everyone* I know gets git's preferred email and gpg config wrong to start with. Recent gits make this explicit by refusing to work in a broken fashion. I see having common defaults in trees as an analogous thing - rather than beating people up when they got it wrong, make it harder for them to get it wrong. > 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. This is another strawman, no? Is anyone suggesting a crusade? > 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). I read that as 'we don't test that our tarballs work'. No? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 4 January 2014 08:31, Jeremy Stanley wrote: > I really don't understand the aversion to allowing contributors to > police on their own what files they do and don't commit in a review > to an OpenStack project. It all boils down to the following > balancing act: I have *no* aversion to allowing contributors to police things on their own. I have an aversion to forcing them to do so. > * Reviewing changes to each project's .gitignore for the trashfile >patterns of every editor and IDE known to man is a waste of >reviewers' collective time. This is a strawman. If we have to review for a trashfile pattern then we have contributors using that. There are more editors than contributors :). > * Having to point out to contributors that they've accidentally >added trashfiles created by their arbitrary choice of tools to a >change in review is also a waste of reviewers' collective time. > > Since there are ways for a contributor to configure their > development environment in a manner which prevents them from > inadvertently putting these files into a change for review, I feel > like it's perfectly reasonable to suggest that as an alternative. It > is just one of the many ways a contributor avoids wasting reviewer > time by neither polluting their changes nor every project's > .gitignore with details potentially relevant only to their own > personal development system and nowhere else. I don't understand why you call it polluting. Pollution is toxic. What is toxic about the few rules needed to handle common editors? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
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
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
Excerpts from Rushi Agrawal's message of 2014-01-05 05:41:58 -0800: > I can see people arguing in future over which top IDE's/editor's trashfiles > should or shouldn't be included in the gitignores. Also, I believe the > concept of global gitignore is a fantastic one. > Has it ever actually happened? Looks a little like a straw man to me. > What I'll suggest is, just not include any of the editor/IDE files in > project gitignores, AND mention how to set global gitignores for these > trashfiles in the wiki page where we give details of Gerrit/Jenkins/Git > https://wiki.openstack.org/wiki/GerritWorkflow > or > https://wiki.openstack.org/wiki/GerritJenkinsGithub > to aid a novice. > I think leaving them in is perfectly o-k. Contributors who use different editors and get annoyed that their files aren't ignored will just submit a patch. This patch will take almost zero cognitive load from reviewers. 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? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
I can see people arguing in future over which top IDE's/editor's trashfiles should or shouldn't be included in the gitignores. Also, I believe the concept of global gitignore is a fantastic one. What I'll suggest is, just not include any of the editor/IDE files in project gitignores, AND mention how to set global gitignores for these trashfiles in the wiki page where we give details of Gerrit/Jenkins/Git https://wiki.openstack.org/wiki/GerritWorkflow or https://wiki.openstack.org/wiki/GerritJenkinsGithub to aid a novice. Regards, Rushi Agrawal Cloud Storage Engineer Reliance Jio Infocomm Ph: (+91) 99 4518 4519 On Sat, Jan 4, 2014 at 1:01 AM, Jeremy Stanley wrote: > On 2014-01-03 19:10:28 + (+), Sam Harwell wrote: > > OpenStack does not have operational or administrative ownership > > over the computers used by contributors. As such, 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 project(s). > > Official alterations of a *global* .gitignore are completely > > unacceptable, but if certain files are not to be specified in the > > .gitignore committed with the project then a policy related to > > modifying the $GIT_DIR/info/exclude would be an acceptable > > alternative. > > I really don't understand the aversion to allowing contributors to > police on their own what files they do and don't commit in a review > to an OpenStack project. It all boils down to the following > balancing act: > > * Reviewing changes to each project's .gitignore for the trashfile >patterns of every editor and IDE known to man is a waste of >reviewers' collective time. > > * Having to point out to contributors that they've accidentally >added trashfiles created by their arbitrary choice of tools to a >change in review is also a waste of reviewers' collective time. > > Since there are ways for a contributor to configure their > development environment in a manner which prevents them from > inadvertently putting these files into a change for review, I feel > like it's perfectly reasonable to suggest that as an alternative. It > is just one of the many ways a contributor avoids wasting reviewer > time by neither polluting their changes nor every project's > .gitignore with details potentially relevant only to their own > personal development system and nowhere else. > -- > Jeremy Stanley > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 2014-01-03 19:10:28 + (+), Sam Harwell wrote: > OpenStack does not have operational or administrative ownership > over the computers used by contributors. As such, 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 project(s). > Official alterations of a *global* .gitignore are completely > unacceptable, but if certain files are not to be specified in the > .gitignore committed with the project then a policy related to > modifying the $GIT_DIR/info/exclude would be an acceptable > alternative. I really don't understand the aversion to allowing contributors to police on their own what files they do and don't commit in a review to an OpenStack project. It all boils down to the following balancing act: * Reviewing changes to each project's .gitignore for the trashfile patterns of every editor and IDE known to man is a waste of reviewers' collective time. * Having to point out to contributors that they've accidentally added trashfiles created by their arbitrary choice of tools to a change in review is also a waste of reviewers' collective time. Since there are ways for a contributor to configure their development environment in a manner which prevents them from inadvertently putting these files into a change for review, I feel like it's perfectly reasonable to suggest that as an alternative. It is just one of the many ways a contributor avoids wasting reviewer time by neither polluting their changes nor every project's .gitignore with details potentially relevant only to their own personal development system and nowhere else. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
OpenStack does not have operational or administrative ownership over the computers used by contributors. As such, 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 project(s). Official alterations of a *global* .gitignore are completely unacceptable, but if certain files are not to be specified in the .gitignore committed with the project then a policy related to modifying the $GIT_DIR/info/exclude would be an acceptable alternative. Thanks, Sam -Original Message- From: John Griffith [mailto:john.griff...@solidfire.com] Sent: Tuesday, December 31, 2013 10:46 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore Hey Everyone, I wanted to see where we stand on IDE extensions in .gitignore files. We seem to have some back and forth, one cycle there's a bug and a patch to add things like eclipse, idea etc and the next there's a bug and a patch to remove them. I'd like to have some sort of consensus on what we want here. I personally don't have a preference, I would just like to have consistency and quit thrashing back and forth. Anyway, I'd like to see all of the projects agree on this... or even consider moving to a global .gitignore. Thoughts?? John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On Tue, Dec 31, 2013 at 3:33 PM, Robert Collins wrote: > On 1 January 2014 06:07, Joe Gordon wrote: >> >> > >> >> I am not sure if this is the global .gitignore you are thinking of but this >> is the one I am in favor of: >> >> https://help.github.com/articles/ignoring-files#global-gitignore >> >> >> Maintaining .gitignore in 30+ repositories for a potentially infinite number >> of editors is very hard, and thankfully we have an easier way to do it. > > This is a strawman argument: noone (that I know of) has proposed > adding all editors to all repositories. There are in reality a few > very common editors and having their extensions present in per > repository .gitignores does absolutely *no harm*. There is no reason > not to have sane and sensible defaults in our repositories. > > If we are wasting time adding and removing patterns, then I think that > counts as a harm, so it is a sensible discussion to have to come to a > project standard, but the standard should be inclusive and useful, not > just useful for power users that have everything setup 'just so'. Many > contributors are using git for the first time when they contribute to > OpenStack, and getting git setup correctly is itself daunting [for new > users]. > > So I'm very much +1 on having tolerance for the top 5-10 editor > patterns in our .gitignores, -1 on *ever* having a bug open to change > this in any repository, and getting on with our actual task here of > writing fantastic code. > > If folk *really* don't want editor files in .gitignore (and given the > complete lack of harm I would -really- like a explanation for this > mindset) then we could solve the problem more permanently: we know > what files need to be added - *.rst, *.py, *.ini, [!.]* and a few > others. Everything else is junk and shouldn't be added. By > whitelisting patterns w e will support all editors except those whose > working file names match names we'd genuinely want to add. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > If we are wasting time adding and removing patterns, then I think that > counts as a harm, so it is a sensible discussion to have to come to a > project standard, but the standard should be inclusive and useful, not > just useful for power users that have everything setup 'just so'. Many > contributors are using git for the first time when they contribute to > OpenStack, and getting git setup correctly is itself daunting [for new > users]. My point exactly is that this is creating churn and there is some back and forth (see links to LP items below). Like I said, I don't have an objection, I just want to be consistent and move on. This has come up in commits in past releases as well. As I said, I see little harm in having them present, however I see significant harm in racking up commits to take them in and out as well as the ugliness in having inconsistent policies in different projects. https://bugs.launchpad.net/ceilometer/+bug/1256043 https://bugs.launchpad.net/trove/+bug/1257279 https://bugs.launchpad.net/python-cinderclient/+bug/1255876 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 1 January 2014 06:07, Joe Gordon wrote: > > > > I am not sure if this is the global .gitignore you are thinking of but this > is the one I am in favor of: > > https://help.github.com/articles/ignoring-files#global-gitignore > > > Maintaining .gitignore in 30+ repositories for a potentially infinite number > of editors is very hard, and thankfully we have an easier way to do it. This is a strawman argument: noone (that I know of) has proposed adding all editors to all repositories. There are in reality a few very common editors and having their extensions present in per repository .gitignores does absolutely *no harm*. There is no reason not to have sane and sensible defaults in our repositories. If we are wasting time adding and removing patterns, then I think that counts as a harm, so it is a sensible discussion to have to come to a project standard, but the standard should be inclusive and useful, not just useful for power users that have everything setup 'just so'. Many contributors are using git for the first time when they contribute to OpenStack, and getting git setup correctly is itself daunting [for new users]. So I'm very much +1 on having tolerance for the top 5-10 editor patterns in our .gitignores, -1 on *ever* having a bug open to change this in any repository, and getting on with our actual task here of writing fantastic code. If folk *really* don't want editor files in .gitignore (and given the complete lack of harm I would -really- like a explanation for this mindset) then we could solve the problem more permanently: we know what files need to be added - *.rst, *.py, *.ini, [!.]* and a few others. Everything else is junk and shouldn't be added. By whitelisting patterns we will support all editors except those whose working file names match names we'd genuinely want to add. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On Tue, Dec 31, 2013 at 10:07 AM, Joe Gordon wrote: > > > > On Tue, Dec 31, 2013 at 8:45 AM, John Griffith > wrote: >> >> Hey Everyone, >> >> I wanted to see where we stand on IDE extensions in .gitignore files. >> We seem to have some back and forth, one cycle there's a bug and a >> patch to add things like eclipse, idea etc and the next there's a bug >> and a patch to remove them. I'd like to have some sort of consensus >> on what we want here. I personally don't have a preference, I would >> just like to have consistency and quit thrashing back and forth. >> >> Anyway, I'd like to see all of the projects agree on this... or even >> consider moving to a global .gitignore. Thoughts?? > > > I am not sure if this is the global .gitignore you are thinking of but this > is the one I am in favor of: > > https://help.github.com/articles/ignoring-files#global-gitignore Yep > > > Maintaining .gitignore in 30+ repositories for a potentially infinite number > of editors is very hard, and thankfully we have an easier way to do it. Exactly > >> >> >> John >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
I am not sure if this is the global .gitignore you are thinking of but this > is the one I am in favor of: > > https://help.github.com/articles/ignoring-files#global-gitignore > > > Maintaining .gitignore in 30+ repositories for a potentially infinite > number of editors is very hard, and thankfully we have an easier way to do > it. > I hereby +1 this I think we should just remove all editors specifics in .gitignore and leave it to the user to set this up which would be useful for him as well on other projects (i.e: not openstack) that doesn't have such .gitignore . Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On Tue, Dec 31, 2013 at 8:45 AM, John Griffith wrote: > Hey Everyone, > > I wanted to see where we stand on IDE extensions in .gitignore files. > We seem to have some back and forth, one cycle there's a bug and a > patch to add things like eclipse, idea etc and the next there's a bug > and a patch to remove them. I'd like to have some sort of consensus > on what we want here. I personally don't have a preference, I would > just like to have consistency and quit thrashing back and forth. > > Anyway, I'd like to see all of the projects agree on this... or even > consider moving to a global .gitignore. Thoughts?? > I am not sure if this is the global .gitignore you are thinking of but this is the one I am in favor of: https://help.github.com/articles/ignoring-files#global-gitignore Maintaining .gitignore in 30+ repositories for a potentially infinite number of editors is very hard, and thankfully we have an easier way to do it. > > John > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 2013-12-31 09:45:38 -0700 (-0700), John Griffith wrote: [...] > Anyway, I'd like to see all of the projects agree on this... or even > consider moving to a global .gitignore. Thoughts?? Personal opinion, the per-project .gitignore should be reserved exclusively for autogenerated artifacts tools and scripts embedded in the source (AUTHORS, dist, cover) or ephemeral files created by tools which are part of the documented and recommended workflow (.tox, .testrepository). The place for ignoring files created by your preferred tools (editors, IDEs) is within your own ~/.gitconfig instead... you can even set core.excludesfile to something like ~/.gitignore if you want to inherit common exclusions from a separate file. As for a global .gitignore synchronized across all projects, I think this is not likely to work well. Consider, as an example, that some projects may want ChangeLog autogenerated by PBR from the Git commit log while others prefer to hand-curate their ChangeLog file instead. The first project will want ChangeLog listed in .gitignore while the second will want it to actually get checked into the repo. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
Hey Everyone, I wanted to see where we stand on IDE extensions in .gitignore files. We seem to have some back and forth, one cycle there's a bug and a patch to add things like eclipse, idea etc and the next there's a bug and a patch to remove them. I'd like to have some sort of consensus on what we want here. I personally don't have a preference, I would just like to have consistency and quit thrashing back and forth. Anyway, I'd like to see all of the projects agree on this... or even consider moving to a global .gitignore. Thoughts?? John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
