This outline looks ok for me. On Tuesday, August 16, 2011 03:48:56 PM Jody Garnett wrote: > I am still troubled over the inconsistencies and had a go at resolving; > and linking between the two sets of instrucitons: > > - http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part > - http://udig.refractions.net/confluence/display/ADMIN/Contributing+changes > > This results in the following outline: > > Community Plugins > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-CommunityPlugins) Setting up a Community Plugin > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-SettingupaCommunityPlugin) Contributing your Plug-in to uDig > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-ContributingyourPlugintouDig) Publishing your Plug-in > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-PublishingyourPlugin) > > uDig Core Development > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-uDigCoreDevelopment) Join the Team > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-JointheTeam) Github Fork > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-GithubFork) > > Formal Change Control > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-FormalChangeControl) Request for Change > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-RequestforChange) Project Steering Committee > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-ProjectSteeringCommittee) > > Project Documentation > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-ProjectDocumentation) Updating and adding to the wiki > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-Updatingandaddingtothewiki) User and developer documentation > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-Useranddeveloperdocumentation) uDig tutorials > (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#How > totakepart-uDigtutorials) > > > As you can see "Github Fork" is presented as an alternative way of working > on "uDig Core Development"; and it mostly just contains a link to the > contributing changes page. Well along with my usual reminder that a > project team should have at least one committer. > > > Thanks Mauricio: looks like someone already did that. > > > > It the "fork" is the way we expect people to work we may wish to describe > > that as the usual way to do things in the set up instructions. > > > > I am still keen to set up procedures so we get more developers with > > commit access (and in position to fix errors). Saving the pull request > > procedure for the more exciting and larger changes. I admit that the > > ability to pull in a request from the web front end is very useful and > > takes out a bit of the pain for the fork based workflow. > > > > > In my understood the process is well described here > > > > > > http://udig.refractions.net/confluence/display/ADMIN/Contributing+chang > > > es > > > > > > Maybe, we could add a link to this page in a Note in: > > > > > > http://udig.refractions.net/confluence/display/ADMIN/02+Checkout+Source > > > +Code > > > > > > cheers > > > > > > On Friday, August 12, 2011 04:04:11 AM Levi Putna wrote: > > > > There seems to be two ways of contributing code back, with commit > > > > access and without. > > > > > > > > This is my workflow for member without commit access, > > > > > > > > 1. Create a personal fork on GutHub (GitHub UI) > > > > 2. Check out a clone of the uDig fork (git clone [email protected] > > > > (mailto:[email protected]): levi-putna/udig-platform.git) > > > > 3. Setup upstream to uDig (git remote add upstream > > > > > > > > https://github.com/uDig/udig-platform.git) > > > > > > > > If I need to get upstream changes (git fetch upstream; git merge > > > > upstream/master) > > > > > > > > I can then push changes back to my fork (git push) and use the GitHub > > > > pull request to contribute changes back uDig (GitHub UI). > > > > > > > > Dont know if this is the best way to do things but it seems to have > > > > worked for me in the past. > > > > > > > > This is the process GitHub seems to sugest, I volunteer to update the > > > > uDig docs to use this method for members without commit access, not > > > > sure about the best process for members with commit access. > > > > > > > > Do we need two method? GitHup Pull request seems like a good way to > > > > review code before it makes it into project core. > > > > > > > > Cheers, > > > > > > > > Mr Levi Putna > > > > [email protected] (mailto:[email protected]) > > > > www.ozblog.com.au (http://www.ozblog.com.au) > > > > > > > > On 12 August 2011 11:42, Jody Garnett <[email protected] (mailto:[email protected])> wrote: > > > > > Morning List: > > > > > I am getting a lot of questions about how uDig uses git today - and > > > > > I cannot answer all of them from our docs. > > > > > - > > > > > http://udig.refractions.net/confluence/display/ADMIN/02+Checkout+So > > > > > urce+C ode > > > > > > > > > > The instructions on the above page do not support the "pull > > > > > request" workflow; can I ask for a volunteer to update the above > > > > > page to support the pull-request workflow. It may be as simple as > > > > > linking to the github instructions ... > > > > > > > > > > ------------------------------------ > > > > > I know I end up with: > > > > > 1) a personal fork of udig-platform (called jive-udig) > > > > > 2) I have a clone of that on my machine called "origin/master" > > > > > 3) I have registered udig-platform as "upstream/master" > > > > > > > > > > So I end up with: > > > > > > > > > > git branch -r > > > > > > > > > > origin/HEAD -> origin/master > > > > > origin/master > > > > > origin/snapshot > > > > > upstream/1.1.x > > > > > upstream/1.2.x > > > > > upstream/fpagnamenta > > > > > upstream/master > > > > > > > > > > This allows me to do: > > > > > a) a pull-request from origin/master (i.e. from jive to > > > > > udig-platform) > > > > > > > > > > (yes I am supposed to make a branch so the pull request is clean) > > > > > > > > > > b) pull upstream master > > > > > > > > > > push > > > > > (to accept the latest stuff from udig-platform and push it over to > > > > > my > > > > > > > > > > fork) > > > > > c) accept changes directly on udig-platform; and work directly on > > > > > udig-platform during release cycle > > > > > > > > > > (this is only as I have commit access; something I hope we can > > > > > sort out > > > > > > > > > > for more developers) > > > > > > > > > > -- > > > > > Jody Garnett > > > > > > > > > > > > > > > _______________________________________________ > > > > > User-friendly Desktop Internet GIS (uDig) > > > > > http://udig.refractions.net > > > > > http://lists.refractions.net/mailman/listinfo/udig-devel
-- Mauricio Pazos _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
