From: James T. <zak...@ma...> - 2015-02-27 22:42:21
|
> On 27 Feb 2015, at 21:56, AJ MacLeod <aj-...@ad...> wrote: > > And this is how I had imagined fgdata / aircraft development would work with the switch to git in the first place. It seems to make perfect sense to me (assuming I've followed correctly) - the actual main author/s of each aircraft maintain their own repo and a branch of this is (semi?)automatically pulled into the "official" fgdata as some kind of submodule. The fact that someone has already done the donkey work to prove that it's a valid solution and done it in a very short space of time suggests to me it probably has a great deal of merit. > > Obviously as I am sadly for the time being mostly an ex-contributor my opinion doesn't count for much, but I have had a fair bit of experience of both the old and newer workflows and the one mentioned above seems by far the best option in my opinion. No combination of suggested mishmash of git and SVN repos has seemed anything but utterly confusing to me, and I'm quite used to dealing with confusing IT mishmashes in real life... For the record, the hybrid SVN / Git suggestions have always been borne of necessity, not elegance. Which brings me to: I’m not sure it /has/ been proved as a valid solution. The reason being, before the current split was proposed, someone (Gijs?) tried exactly the same split a few years ago and the community comprehensively rejected it. I don’t recall all the arguments, but essentially this statement is where it falls down: " the actual main author/s of each aircraft maintain their own repo “ We have lots of contributors who’ve never had to do that before, and will regard that as disruptive. I agree from a ‘coder’ perspective it would be ideal, and plenty of people *are* doing it external to fgdata already, but the fact remains that other folks have essentially been relying on ‘us’ (the project) to solve their file hosting for their work. And secondly, I still remain unconvinced the Jenkins timeout issues are actually solved. The problem is we can’t find out without doing all the steps to make large enough repo to actually break - I’m sure it will work with a small / young test repo! I *am* sure such a repo can only live on SourceForge. We need to get off Gitorious, period, for the data files. (It might be worth moving the code repos to SF just to having everything in one place, but it’s more disruption) Kind regards, James |