On Wed, Oct 19, 2011 at 1:45 PM, Jacob Burbach <jmburb...@gmail.com> wrote:
> Seems like most people are just banging their heads against the wall
> trying to make a new system the same as the old, which is counter
> productive and unfortunate. It is highly unlikely ANYONE needs every
> single aircraft from git that they were previously forced to take,
> which is the whole point of the change. If people are honest with
> themselves I think they would realize they only need such aircraft
> that they plan to use or do development on. Personally I am extremely
> happy that I will no longer need to pull down hundreds of aircraft I
> have no intention of ever touching just so I can work on and test
> development new development in flightgear.
>
> In the end this will make it much, much easier for new developers and
> testers to get up and running and get to work.
>
A developer that needs to make download packages for every available
aircraft?
A developer that wants to check if a source code change will impact the
available aircraft (or gauge what the level of impact would be if they made
a particular change.)
A developer that needs to update code, and also fix all the associated
aircraft to track a code change.
A user who likes to be a collector and have everything available to browse
through whether they plan to use a particular aircraft today or not.
I could probably think of many more if I thought for a while longer.
We can't be short sighted here and do a major regression that causes
problems for a lot of people, just because there are some vocal people who
don't have a personal need for every usage case.
I know we all worship at the alter of git, but isn't the main problem here
is that we are forcing everyone to download the complete binary history of
everything in the data package, and this is not scaling well for us? If we
put it to a vote, I wonder how our general user population would respond to:
Do you want (a) the entire binary history of everything (b) the entire set
of aircraft.
We are committed to git, I'm not suggesting otherwise, but the entire binary
history of the data tree is pushing 10Gb. My understanding is that
splitting off the aircraft wouldn't reduce the total size, but would allow
us to deal with smaller chunks and optionally cherry pick just the parts we
want. But if the result is that it is an immense effort or very difficult
to get all the data and all the aircraft for people that want it (for any
reason) then we have a problem. Telling them they don't need it and
shouldn't download it is not really a good answer.
Here's another way to look at it. We need to keep policy and capability as
separate as possible. If we end up with significantly reduced capability,
just redefining our policy is going to make a lot of people unhappy.
Ideally we should find a solution that offers the required capabilities to
support different policies. People that just want a few aircraft can
establish that policy for themselves, people that want all the aircraft can
establish that policy for themselves.
We can't go around telling people what they should want or what they should
do in response to taking something away from them and implying there's
something wrong with them if they think otherwise.
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
