> Aside: I don't think I yet fully comprehend the purpose of our
> developer forks. I'm using "Pro Git" as my reference book and its
> discussion of alternative work-flows for projects, developer forks are
> only mentioned in the context of very restricted access to the
> canonical repo, ie. I would commit to my fork and then make a pull
> request to the higher beings with canonical access.
>
>
I think we mostly use this because it is so very well supported by github.
By doing your "pull request" from:
a) a developer fork - it allows us to work with groups who do not want to take
part in the project directly
b) a developer fork + branch - it allows your patch to sit there out of your
way until it is reviewed an accepted
As for it being so very well supported by github, we are kind of stuck with the
"fork-me" workflow. It is such a low-effort way of taking part that projects
get forked on github when they are not looking, and even when they are not on
github. At least by going to where the action is we can have the changes easily
available to us for review/merge etc...
> Apologies for so many entry-level questions.
>
>
bah - no apologies - we need entry level questions so we can continue to beat
answers out of justin.
Jody
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
