Hi Core (and the rest of the entire organism of course)
Why not splitting up the Aircraft folder into hangars as collection of
aircrafts as plug-ins, collection of big teams or small but heavy
industries ?
--- fgdata
|
---- Aircraft
| |
| ---- Hangar 1 (i.e. Emmanuels Hangar)
other | |
fgdata | Aircraft 1
stuff | |
| Aircraft 2
| |
| etc.
|
|
---- Hangar 2 (i.e. Canadian FG Group Hangar)
| |
| Aircraft 1
| |
| Aircraft 2
| |
| etc.
.
.
.
|
---- DEFAULT (fgdata-core-devs-only hangar)
| |
| generic
| |
| instruments
| |
| etc.
Hangars:
- are created under gpl2 upon request on gitorious, by core developers,
so they are creator/owners with admin rights
- the hangars are submodules of fgdata/Aircrafts and separate repos
– beside the hangar as repo developers create a "hangar team" on
gitorious and give review and commit rights to the new team
- so the hangar team gets access to review/commit the hangar, but no
admin rights. Group members can not delete the hangar, nore can they
change licence or add contributors directly, but team leaders can give
commit rights another way:
- one person or more members of the group get access to administrate the
group (they can give commit rights by adding other members to the hangar
group)
- there is a "default hangar" which contains default stuff like
instruments etc. and official deployment content i.e.
- there will be a huge hangar called "waiting for maintainer"
- All aircrafts gets tags for compatibility
This way hangars are collections of "plug-ins", it is all under one
licence, "main contributors" can manage their teams and get more
autonomy, they can give commit rights without having access to the repo
administration, or they can work alone in a single group, fgdata core
team keep control, hangars can not be deleted, etc. etc.
I know this needs some changes in fgfs core with aircraft paths, and
maybe also a new aircraft-meta-data.xml. But selecting aircrafts by
multiple hangars like for the scenery and update servie by hangars/tags
will probably also be a lot of new comfort for deployment.
Just a thought. I am sure I forgot the most important things ;-)
Cheers, Yves
Am 20.10.11 00:10, schrieb ThorstenB:
> Hi FlightGear,
>
> there was little input on the fgdata split and few people speaking up
> when things were started. We do see a lot of responses now - many being
> in favor of the change, but also concerns about remaining issues.
> Indeed, setting up the new repo isn't as simple as it seemed initially,
> and there are issues which need to be resolved. We also need common
> acceptance of the new structure, tools and processes.
>
> Unfortunately, the call for "split completed" was communicated ahead of
> time - even before fgdata itself was switched. And we still do see a
> need for a proper testing phase before switching - including a chance
> for everyone to give input, raise concerns, etc.
>
> So, after long discussions tonight, including Gijs, Jorg, James,
> TorstenD, ThorstenB& Curt, we agreed to the following:
>
> * We hereby announce a longer testing phase for the proposed changes,
> which will at least last 4 weeks (at least until November 17th). We will
> try to get all tools/scripts and processes in place and test how things
> work for everyone. We will also see how we can preserve the existing
> workflow for people who wish to stick with their current process (i.e.
> use a "super-repo", possibly using "git submodules").
>
> * Meanwhile, we do _REOPEN_ the existing fgdata repository - which for
> the time being remains the master repository. This was chosen to relieve
> the new repository, tools and manuals of immediately working for
> everybody - and to also allow possibly rewriting the new repository, if
> necessary. We still do invite everyone for testing the new setup.
>
> * We will try to sync changes from the master repository into the new
> split repositories, so these can be used for syncing and testing.
>
>
> We are really sorry for any inconvenience and misunderstandings this
> further change may cause. But now, as we have everybody's attention on
> the subject, we're looking forward to many people testing the proposed
> changes. We also invite everyone to speak up on which kind of repository
> they prefer. And we are still collecting issues and topics in the Wiki:
>
> http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata
>
> Finally, please be aware that, while we welcomed his input on the
> splitting process, some of Cedric's switch announcements do not reflect
> the opinion of the others involved, neither were they fully agreed upon
> (in content and timing).
>
>
> Best regards,
>
> Gijs, Jorg, TorstenD, ThorstenB, James& Curt
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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@Cisco 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
