From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SXeB4-0006kg-2V for garchives@archives.gentoo.org; Thu, 24 May 2012 19:58:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 14D82E07F0; Thu, 24 May 2012 19:58:16 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 78BAFE077E for ; Thu, 24 May 2012 19:57:32 +0000 (UTC) Received: by obbuo19 with SMTP id uo19so202507obb.40 for ; Thu, 24 May 2012 12:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=IjSpx+H7tA7qkE0NiKnhZIXCrECv2tXwbInX4j5H/rI=; b=jqJiaH+iYgns39LPQPS+JbNrIvzNvybzhbr6iZXuOJLXrlo09H/yqtAS3PBycEqtNl HDG+2eut2/i+ZL8gSMVB+frdoMCSjgxAK1vJ0K9zv8xkmwNdfwjiyz81r4VUME1QGw5r nnwZDpVaCvfziEJt3vPSDbDkhJ+Ma9qX3fbEgbCSvYjro1+oPtU0wvzYCJWV/p4W1noG rlo7aR9R9zgX8QhTSx0rh33hEpQnGdDgfyRdUj/+pF4seMM+kJr9JOS2YBg/25iU7z0n NLHSn01PsNjdRP8HnEODHUm3L37pu2FQiwQt+PVTPGPwJKgxrS01byZ01MBV9loejfmM +55w== Received: by 10.182.167.101 with SMTP id zn5mr796982obb.13.1337889451763; Thu, 24 May 2012 12:57:31 -0700 (PDT) Received: from smorgbox.localnet (65-128-181-111.mpls.qwest.net. [65.128.181.111]) by mx.google.com with ESMTPS id af6sm234931oec.3.2012.05.24.12.57.30 (version=SSLv3 cipher=OTHER); Thu, 24 May 2012 12:57:31 -0700 (PDT) From: Dan Douglas To: gentoo-dev@lists.gentoo.org Cc: Ian Stakenvicius Subject: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver Date: Thu, 24 May 2012 14:57:24 -0500 Message-ID: <3485389.iLMx13MNW5@smorgbox> User-Agent: KMail/4.8.3 (Linux/3.3.6-pf+; KDE/4.8.3; x86_64; ; ) In-Reply-To: <4FBE8223.2010406@gentoo.org> References: <4FBCDB3D.1070009@gentoo.org> <4473416.vM7oOSmagZ@smorgbox> <4FBE8223.2010406@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3919907.AYkhkYvtTu"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: 7Bit X-Archives-Salt: f06818e9-cee3-4459-b57e-ed8901c914f8 X-Archives-Hash: 79acbeb44691084394ba45b3924ffc6a --nextPart3919907.AYkhkYvtTu Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" > On 24/05/12 02:37 PM, Dan Douglas wrote: > > On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote: > > > > Of course it's read only - just like all other public > > repositories. You don't want to accept improvments? I don't > > understand this. > > I have no problem with accepting improvements, i'm just leary of > semi-official copies of the tree that could be checked out and checked > into by non-dev's (this said, I don't know that much about git but I > assume that github users could commit to the github copy yes? that > being the way users would contribute?) > >> otherwise we're going to have a rather large mess on our hands > >> (multiple forks of the main tree != a uniform main tree + > >> overlays, the way it does now) > > > > Forking happens when it's hard to contribute. You even want to > > make overlays difficult? The only real mechanism Gentoo provides > > for user extensibility? > > Nono, I was comparing the (from my perspective) mess of multiple forks > of the main tree that hosting on github/other services could > potentially enable, with a single uniform source of the main tree plus > overlays for extended contribution (which is the system we have now). Git is about decentralized version control. When you clone a repo, you have your own "fork". When everyone has their own branch, everyone is effectively equal. So yes you can expect much much more forking. In Git land, forks are good. There's no way to enforce that people only pull from some "official" source. It works out in practice so that 99% of the time people only care about a couple branches of one repository. Counterintuitively, this comes as a side- effect of git actually doing distribution properly and making it easier for everybody's workflow. The overlay model by contrast is quite broken on its own and virtually forces creation of new overlays in order to make changes without the benifits of version control (with regards to the rsync tree at least). What Github does is facilitate making it easy to fork/branch and provide a central way to push changes back into a remote through pull requests. Pull requests and other web services around git hosting are pretty much the thing that makes github worth using. From the standpoint of accepting patches, the differenc e to you is rather than (or in addition to) accepting patches through bugzilla, you can choose to accept a push directly from someone else's copy of the repo. It isn't like a wiki - everybody commits to their own repositories and pushing to a remote is on a whitelist basis just like in centralized version control. Anyway, others are better at "selling" Git than I and there are no shortage of resources out there describing distributed development models. I think this thread is supposed to be about the technical hurdles and it looks like whether or not it's feasible to support github. I can't really comment on the latter. Aside from whatever hoops the Gentoo devs have to jump through in trying to maintain multiple repos, it's hard to see the downsides to using github in and of itself. Talk to the Gentoo Haskell guys, they've been using Github for some time. And if memory serves, KDE used to be on Github or Gitorious before moving to o.g.o -- Dan Douglas --nextPart3919907.AYkhkYvtTu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAk++kqQACgkQMmyDamdg+MzL7ACfW1La+i8qs1C5U3COn+Rrp4We Gw4AniKw2YcBMC99jyegNRLIsfokPOfM =/3kT -----END PGP SIGNATURE----- --nextPart3919907.AYkhkYvtTu--