117
edits
FlightGear Git: splitting FGData: Difference between revisions
Jump to navigation
Jump to search
FlightGear Git: splitting FGData (view source)
Revision as of 10:02, 12 December 2011
, 12 December 2011→Comments on the new plan
| Line 102: | Line 102: | ||
--[[User:ThorstenB|ThorstenB]] 17:57, 11 December 2011 (EST): It's a huge improvement to split aircraft from the main fgdata repo. Any change to an aircraft will only affect a single aircraft. But changes to the rest of fgdata (the central Nasal, Shader, GUI directories etc) can have a massive impact: on all other aircraft, on the simulator core, or on the design/direction/structure of core parts. So, it's good to have these things separated. And I think we can allow a lot more people direct commit access once aircraft are separated - even if they all share a repo. I don't think we would see many (or any) cases of authors messing with other people's work. | --[[User:ThorstenB|ThorstenB]] 17:57, 11 December 2011 (EST): It's a huge improvement to split aircraft from the main fgdata repo. Any change to an aircraft will only affect a single aircraft. But changes to the rest of fgdata (the central Nasal, Shader, GUI directories etc) can have a massive impact: on all other aircraft, on the simulator core, or on the design/direction/structure of core parts. So, it's good to have these things separated. And I think we can allow a lot more people direct commit access once aircraft are separated - even if they all share a repo. I don't think we would see many (or any) cases of authors messing with other people's work. | ||
And I think the rules are fine and simple enough - actually almost "common sense" when working in a collaborative environment. | And I think the rules are fine and simple enough - actually almost "common sense" when working in a collaborative environment. | ||
--[[User:Durk|Durk]] 05:02, 12 December 2011 (EST) I would also like to mention that we don't consider the initial split to be the final stage. Additional splits are possible, but we need to carefully evaluate how we should do that. Once we do have a decent plan we can continue with phase b) of the operation. I will add that to the plan later. | |||
(hvengel comments) | (hvengel comments) | ||
| Line 114: | Line 116: | ||
--[[User:T3r|T3r]] 15:06, 11 December 2011 (EST): Absolutely - however: as most commiters are as lazy as I am, they do not regularly check for merge requests. Picking your most trustworthy commiter from the list and asking him to handle the requests for you is probably a good idea. Reminders by PM are always welcome. | --[[User:T3r|T3r]] 15:06, 11 December 2011 (EST): Absolutely - however: as most commiters are as lazy as I am, they do not regularly check for merge requests. Picking your most trustworthy commiter from the list and asking him to handle the requests for you is probably a good idea. Reminders by PM are always welcome. | ||
--[[User:Durk|Durk]] 05:02, 12 December 2011 (EST) Which is actually why we introduced the notion of a mentor. The primary purpose is that more one-to-one work relations between committers and contributers will be established. This will certainly benefit the overall workflow. | |||
{{Appendix}} | {{Appendix}} | ||