[openstack-dev] [all] sample config files should be ignored in git...

Clint Byrum clint at fewbar.com
Thu Mar 27 21:19:14 UTC 2014


Excerpts from Sean Dague's message of 2014-03-27 13:11:57 -0700:
> On 03/27/2014 02:54 PM, Joe Gordon wrote:
> > 
> > 
> > 
> > On Thu, Mar 27, 2014 at 2:21 AM, Dirk Müller <dirk at dmllr.de
> > <mailto:dirk at dmllr.de>> wrote:
> > 
> >     Hi,
> > 
> >     >> When I was an operator, I regularly referred to the sample config
> >     files
> >     >> in the git repository.
> > 
> >     The sample config files in git repository are tremendeously useful for
> >     any operator and OpenStack Packager. Having them generateable with a
> >     tox line is very cumbersome.
> > 
> > 
> > Why is it cumbersome? We do the same thing.
> 
> Because we've already got a working tox environment. Which includes
> knowing, in advance that you can't just pip install tox (as 1.7.x is
> broken), and that you need to have postgresql and mysql and libffi dev
> packages installed, and a C compiler.
> 
> Start with a pristine Linux it is a lot manual steps you have to go
> through to get a working config out of tox -e genconfig.
> 
> So I think it's a fair concern that we did just move a burden back onto
> users because we dug a hole by letting libraries declare arbitrary
> required variables in our config files.
> 

This is pretty standard in the open source world. Git trees do not have
all of the things that the user needs. Git trees have all the things
that the project provides.

If this were autotools we'd have people run 'autoreconf' and/or 'make
doc'. That would likely involve installing autotools, and might also
require some libraries to be present to build tools that are used to
generate things.

I would have a hard time supporting users who don't read the README
before trying to make use of a git tree to use/install/configure a piece
of software. As long as those steps are spelled out, and the releases
contain this generated file, I'm +1 on removing it from git.



More information about the OpenStack-dev mailing list