Policy regarding support repositories

[peabody124]

So this branch https://github.com/PhoenixPilot/PhoenixPilot/pull/41 is used in conjunction with https://github.com/peabody124/AircraftVisualization to visualize the UAV.  I'm curious what our policy should be with regard to making additional repos in the Phoenix github.  I would suggest being fairly liberal so for example this visualization could move there.  The same would be true for the support repositories for the overo.

[Kenn Sebesta]

So I'm going to say that this is probably better off in a separate git tree of PhoenixPilot. I love and depend on this code for my research, but it's got some work to go before it's a tight fit into GCS. Furthermore, there are advantages to having this in a separate tre, which we lose when it gets merged. For instance, you can have a detailed readme.md file describing how to set up and use the aircraftvisualization. Then this is a fully functioning, supported, and visible aspect of what you can do with PhoenixPilot.

I think ultimately this will be a great replacement for the model viewer widget, which I have always felt is superfluous and confusing.

[Lilvinz]

I think what james means is not MERGE it into PhoenixPilot/PhoenixPilot but have it live aside in its own repo like PhoenixPilot/AricraftVisualization

[Kenn Sebesta]

I think that's a great idea. FYI, the merge request might have been accidentally borked, as it's into next. Or maybe I'm misunderstanding github.

[peabody124]

The module is intended to go into the main repository because it integrates with the main code base.  It can easily live in a branch though if needed.

My point was the standalone visualization software should be in a separate repository.  Same for the software for the Gumstix etc.

[Kenn Sebesta]

Can we get Modules/Simulation/module_name, instead of putting it into Modules? I see the advantage of having this in the sim, but I can also see that we might get lots more sim modules as the unit testing idea develops.

[peabody124]

I don't oppose that on principle but in practice but that breaks the existing structure.  If we were going to start doing something like that I'd almost suggest a root level simulation directory and make that Makefile take two types of modules

MODULES += NormalModuleName

SIM_MODULES += Visualization Sensors

and sim modules come from simulation/Modules

[Kenn Sebesta]

That could be better, but we want to make sure that it's understood that those are modules that are additionally included, not just a list of all modules that will be used in simulation.

[Angus]

I think that any relevant project which has more than 1 committer working on it should definitely be added to the main account as a master.