Paul Winkler wrote:
> On Wed, Apr 09, 2008 at 03:31:37PM -0500, Ian Bicking wrote:
>> Paul Winkler wrote:
>>> Many of the config files we build have templates living in *-files
>>> subdirectories of
>>> https://svn.openplans.org/svn/fassembler/trunk/fassembler/
>>> e.g.
>>> buildbot-files/
>>> opencore-files/
>>> supervisor-files/
>>> ...
>>> But I just discovered at least one exception that took me a while to
>>> find:
>>> http://codespeak.net/svn/z3/deliverance/DeliveranceVHoster/trunk/fassembler_config.ini_tmpl
>>> I would argue that since this file is specific to TOPP, it belongs in
>>> svn.openplans.org.  Any reason I should not move it?
>> This same pattern is true for stuff like TaskTracker ini files, and some 
>> stuff in opencore.  Developing them alongside the product being configured 
>> felt more straight forward to me, and allows the -req files to control the 
>> checkout and thus configuration of the product in our stack.  Fassembler 
>> natively only really supports a single branch of development (well, you can 
>> branch it, but it's seldom necessary as long as this more volatile stuff 
>> like configuration isn't in fassembler directly).
> 
> Okay, that's a good rationale for keeping them separate from
> fassembler.
> 
> But it still smells odd to me:
> 
> - to most non-TOPP people checking out from codespeak, a
>   fassembler-specific template is meaningless clutter.
> 
> - new TOPP employees would need somebody at codespeak to give them
>   checkin rights even if all they want to do is tweak our build
> 
> - to find fassembler config templates, we have to look in N places
> 
> What if we had something like
> https://svn.openplans.org/svn/fassembler/skel ?
> 
> So what's currently at
> https://svn.openplans.org/svn/fassembler/trunk/fassembler/opencore-files
> could move to e.g.
> https://svn.openplans.org/svn/fassembler/skel/trunk/opencore-files
> 
> This could be branched independently of fassembler itself.
> 
> Disadvantage: need to modify the builds to check those out, I guess
> this would be done by adding a line to each -req file and modifying
> the fassembler Project subclasses that look for them.

We could do that.  We could also use requirements/config/, and so we'd 
keep the config templates alongside the requirements files.  That 
perhaps seems a bit easier to me, as it doesn't add a new hierarchy to 
keep track of.

   Ian