-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/15/2015 01:27 PM, PatrickD Garvey wrote: > On Thu, Jan 15, 2015 at 1:14 PM, Jim Perrin <jperrin at centos.org> > wrote: >> >> >> On 01/15/2015 01:38 PM, PatrickD Garvey wrote: >>> On Thu, Jan 15, 2015 at 5:08 AM, Jim Perrin >>> <jperrin at centos.org> wrote: >>>> >>>> The repository has been cloned to github for community >>>> use/improvement. If I made a couple minor changes and updated >>>> the README (along with wolfy) so please feel free to >>>> review/contribute to >>>> https://github.com/CentOS/Community-Kickstarts >>>> >>>> - -- Jim Perrin >>> >>> Please forgive the intrusion, but why >>> https://github.com/CentOS/Community-Kickstarts and not >>> https://git.CentOS.org/Community-Kickstarts ? >> >> >> Because more people have github accounts than git.centos >> accounts. I'll look into mirroring between them. >> >> -- Jim Perrin > > > Thank you. > > I think I'll wait to ask more penetrating questions until after > I've made use of git for a while. I just have some ideas based on > sketchy information about git that duplicate files in the two have > no added value. Git (and other DVCS systems) takes a bit of a different mental approach than a traditional hub-and-spoke model. Each Git repo contains a complete history of all changes from each other repo, so the changes and history are distributed rather than centralized. In that case, it's all duplicates, from my local git checkout to each other checkout. Where we say e.g. git.centos.org is a central repository, that is more a convention we choose rather than a limitation (feature) of the Git software. The reason for using GitHub is that it has become something akin to "social coding". It is now a normal behavior to fork a GitHub repo, make changes, and offer them back via a pull request. It's a very low barrier for people interested in offering subtle-to-big code changes, documentation changes, etc. (vs joining a mailing list to submit a patch.) However, there is a risk to an open source project to put all the code in a closed source application as the central repository, e.g. putting all ones eggs in one basket. For this reason, the recommendation is to have the project's git repository be primary (canonical), and use GitHub for the ease-of-use, by mirroring changes back-and-forth between the two git repos. http://bit.ly/TOSWOpenTooling [1] ... I've been pondering putting in a specific guideline that speaks to GitHub, but I prefer to keep the guidelines more generic than specific where possible. Regards, - - Karsten [1] Long URL: http://www.theopensourceway.org/wiki/How_to_loosely_organize_a_community#Use_lightweight.2C_open_collaboration_tools_-_wikis.2C_mailing_lists.2C_IRC.2C_version_control.2C_bug_trackers_-_and_give_out_access - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlS4lMsACgkQ2ZIOBq0ODEFjcACdGZF5bpBPixPfvMD7cEp4vBK5 6u8AoLIHznXl+AXSedG3+LK/DtSYzUXw =t/g6 -----END PGP SIGNATURE-----