Talk:Development workflow

As a new git user and flightgear enthusiast, I have an idea about what I would need on this page and am prepared to help.

I'm reading PRO GIT. The Amazon pdf download is free.

PRO GIT Chapter 3: Git Branching has some nice diagrams that explain various branching scenarios. I'm thinking that the style and layout of the chapter with diagrams and specific git commands to cover a scenario would fit well for the purpose of the Development Workflow page.

It would be helpful to have diagrams and git commands adapted to specific steps a contributor needs to take to make a change to a specific file, and then submit it for consideration by developers. It would also be useful if the page could explain the workflow used by the development team in preparing for each step in their release cycle.

Would it be helpful to first develop a set of user stories or use cases?

• http://en.wikipedia.org/wiki/User_story
• http://en.wikipedia.org/wiki/Use_case

Development Scenarios:

• developer with commit privilege to main flightgear git archives with changes one or more files
• developer without commit privilege to main flightgear git archives with changes one or more files
• developer with commit privileges accepts a request to merge one or more files
• developer with commit privileges accepts a git merge request
• comment on a merge request
• files are delivered as a set of diffs
• files are delivered as an archive of complete files
• files are delivered in a merge request from a personal or team clone
• files are delivered in a merge request in the main repository

Referemce Scenarios: New git user: refer to an esternal page on using git and other reference material such as https://github.s3.amazonaws.com/media/progit.en.pdf

User just wants to build flightgear: refer to http://wiki.flightgear.org/Scripted_Compilation_on_Linux_Debian/Ubuntu and http://wiki.flightgear.org/Building_Flightgear

--callahanp Morning, 9 June 2013

Hi, I wasn't even aware this page existed - it looks like a good start, but could definitely use some contributions. Your plan sounds good, so I'd suggest to just go ahead. It's currently really just a stub, and the original author is currently not an active FG contributor. Regarding diagrams, some users have contributed Inkscape drawings, see Git#Work-flow Overview.--Hooray 08:48, 10 June 2013 (UTC)

Hi Hooray, I'm wondering if there may be more pages related to various aspects of flightgear development. Does this area need some review and cleanup? Callahanp 10:06, 10 June 2013 (UTC)

Well, there's the Category:Core developer documentation category for development related pages - so it'd probably be a good idea to check the page stats (number of views) vs. article maturity (stubs) to identify areas that could use some TLC. Also, we have the dedicated Portal:Developer and a bunch of related categories like Category:Developer Plans. The entry point for new developers should be the section titled "Core" at Portal:Developer, which links to Howto:Start core development. As the original author of that introduction, I'd welcome and appreciate any contributions related to the article or the developer portal in general. So please feel free to get involved, no need to be shy about it :) --Hooray 11:41, 10 June 2013 (UTC)

Hi,

nice to see you're interested in improving the development documentation! I've started cleaning the Git articles lately to do just that. My plan is to have the following articles:

• FlightGear Git basic intro to Git as used by the FlightGear project (basically the first section of the current FlightGear and Git article.
• FlightGear Git: data developers for aircraft, GUI, Nasal developers that don't need to build FlightGear themselves, but only need the up to date Git data.
• FlightGear Git: core developers for any developer that needs to compile FG/SG from source.
• FlightGear Git: gitiquette, some (unwritten) "rules" that anyone working with FlightGear Git should (try to) adhere to.
• FlightGear Git: tips, listing additional commands that can be useful to improve your workflow, or perform special actions.

I'd like to keep the two "main" articles (the "... developers" ones) as simple as possible, covering just the basics. Anyone interested in doing trickier stuff is better of reading Git tutorials/manuals. We just cannot cover everything, without loosing the novice user.

My focus is on those not having direct commit access, because one should show decent Git skills before being granted acces anyway ;-)

Gijs 12:11, 10 June 2013 (UTC)

Thinking about it, I have come to the conclusion that this would not need to be very much work, as long as we're using templates - because git instructions are usually the same, and only need to be parametrized for different repositories, use cases - i.e. we could use wikimedia templates and variables, which would only require 3-5 different templates (which could share markup) and we could cater for the most important scenarios. In fact, with some wikimedia addons like dot/graphviz support, we could even create the diagrams procedurally, and would not need to create them by hand. For example:

git clone --recursive git://gitorious.org/fg/simgear.git

git clone --recursive git://gitorious.org/fg/flightgear.git

git clone --recursive git://gitorious.org/fg/fgdata.git

git clone --recursive git://gitorious.org/fg/terragear.git

We could have a bunch of such templates (glone, pull, rebase, merge) and then build higher-level templates on top of these "building blocks", i.e. for creating/handling merge requests. And the nice thing is that this would be totally scalable, because the primitives could be based on CLI/terminal commands, while we could also support a GUI mode, just by using a different argument and by adding corresponding screen shots.--Hooray 06:18, 11 June 2013 (UTC)