Open Stack

On Tue, 2019-01-22 at 17:29 +0000, Sean Mooney wrote:
> On Tue, 2019-01-22 at 15:32 +0000, Sorin Sbarnea wrote:
> > We are talking about policies not fundamental laws of the universe. 
> > 
> > Policies are created in order to simplify decisions based on previous history, so clearly there were projects that
> > existed before this policy was introduced.
> > 
> > Try to look at it via pragmatic approach: this policy tries to avoid a never ending list of reviews related to local
> > files. -- for good reasons, people have the freedom to use whatever editor they want. So what if everyone is writing
> > his own editor with his own editor config files to be ignore?
> > 
> > This is why such a policy was created. Obviously it appeared after it was observed and I am sure there are lots of
> > projects that do have .gitignore files that do not "pass" this policy.
> > 
> > Don't waste time trying to solve it, it does not worth the time.... you may endup like "someone is wrong on the
> > internet". ;) 
> > 
> > harmony sounds nice on paper but in real life is impossible (or at least impractical) to achieve.
> > 
> > If someone mentions it during a review, accept it and add the exception to your user .gitingore file.
> 
> so i personally am in the camp of just merge patches for trivial change like this when they are proposed
> but also as you said you can just set these in you users ~/.gitignore too.
by the way your user level git ignore is at this location by default $HOME/.config/git/ignore 
if you want to use a ~.gitgnore you need to override that default. using
~/.gitignore is generally not ideal if you are one of those people that like to commit there
home directory to git to be able to easily version contol it.
anyway i hope that helps.
> there is some documentation about that here https://git-scm.com/docs/gitignore however
> i have found most people are not aware that there is such a thing as a user's git ignore
> which is what propmts people to propose patches to change the projects .gitignore
> so if we do say we dont suport this becase of policy x we should try to tell people how they
> can update ther local env to have the same effect.
> 
> > 
> > Cheers
> > Sorin
> > 
> > PS. I got myself a CR rejected few months ago for the same reason, I read about it and accepted it. It makes sense.
> > 
> > > On 22 Jan 2019, at 14:32, Sean McGinnis <sean.mcginnis at gmx.com> wrote:
> > > 
> > > > Then I have started to make patch, to align OpenStack projects with this policy:
> > > > 
> > > > https://review.openstack.org/#/c/632086/
> > > > 
> > > > In nova project the patch was refused, the first reason was we have
> > > > already talk about this subject. The second reason was this policy is
> > > > only for the new projects. Oslo is not a new project and is follow
> > > > this policy.
> > > > 
> > > > I know is not a priority subject, but I just want understand. For me a
> > > > policy must be followed by all projects, to harmonize all, but maybe I
> > > > wrong. For example, in this case, I would to know what is the rules?
> > > > The new projects must follow the policy but not the old ones? In this
> > > > case, what the rules for old projects and can we defined also an
> > > > policy for it? Thanks in advance for your help.
> > > > 
> > > > My best regards
> > > > 
> > > 
> > > It is somewhat up to each project and the core teams if, when, and how they
> > > want to enforce something like this.
> > > 
> > > So while it is generally recommended not to put IDE, OS-specific, and other
> > > similar things in the per-project gitignore, there is also no real value added
> > > by going through all existing projects and removing things that are already
> > > there.
> > > 
> > > Sean
> > 
> > 
> 
>