[CentOS-devel] kickstart extra minimal

Fri Jan 16 04:34:19 UTC 2015
Karsten Wade <kwade at redhat.com>

-----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-----