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#Howtotakepart-CommunityPlugins) Setting up a Community Plugin (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-SettingupaCommunityPlugin) Contributing your Plug-in to uDig (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-ContributingyourPlugintouDig) Publishing your Plug-in (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-PublishingyourPlugin) uDig Core Development (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-uDigCoreDevelopment) Join the Team (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-JointheTeam) Github Fork (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-GithubFork) Formal Change Control (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-FormalChangeControl) Request for Change (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-RequestforChange) Project Steering Committee (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-ProjectSteeringCommittee) Project Documentation (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-ProjectDocumentation) Updating and adding to the wiki (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-Updatingandaddingtothewiki) User and developer documentation (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-Useranddeveloperdocumentation) uDig tutorials (http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part#Howtotakepart-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. -- Jody Garnett Aside: I got on to this as I am looking for the instructions on how to set up a fork; and also point to udig "upstream" in order to keep the two in sync. On Monday, 15 August 2011 at 4:17 PM, Jody Garnett wrote: > 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. > > > -- > Jody Garnett > > > On Friday, 12 August 2011 at 6:00 PM, Mauricio Pazos wrote: > > > In my understood the process is well described here > > > > http://udig.refractions.net/confluence/display/ADMIN/Contributing+changes > > > > 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+Source+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
