Open Stack

On 11 January 2014 15:39, Jeremy Stanley <fungi at yuggoth.org> 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud