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 <gentoo-dev+bounces-51929-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1SXccr-0006DO-1o
for garchives@archives.gentoo.org; Thu, 24 May 2012 18:19:05 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 5611CE08B1;
Thu, 24 May 2012 18:18:51 +0000 (UTC)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175])
by pigeon.gentoo.org (Postfix) with ESMTP id 4107CE0858
for <gentoo-dev@lists.gentoo.org>; Thu, 24 May 2012 18:17:58 +0000 (UTC)
Received: by wibhn6 with SMTP id hn6so5486636wib.10
for <gentoo-dev@lists.gentoo.org>; Thu, 24 May 2012 11:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=m10zG/x0vqzJkh/l2Iyd0ahrVNU/D+EK0UiWxopN/DY=;
b=mzwybQwMTYRt20RS9FsamHEi1kN5Z/G8WV+lyED/p4kVPhOSAIrk9TTlFqVXOraXzx
qI8x3a+k9ovnBt++M95sy8HgZd1QaBD9OwO1OF4661tiINGwVR2iWdW8Avc1xNLEP9P8
dU2/Wwm74MLcyReL7RAXLiMOmCkdh+wYk9fgKIM4rp+VXq40fevQhbhmoCiavCYQUaBq
SubuoLrDKS5ouvQah9Zu56Es2MZ+JC19XjJ2eITtRN8WgA928tQbyxcEwxfWk8/vb/Rm
gi+n5nZ72p1J7VQrZEe+g1R8xSBxwlqqo3C+Zf+RgDQj2lmVNT2qv6chNIQvW6tzBXWi
YJTg==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.180.24.193 with SMTP id w1mr57049325wif.5.1337883473454; Thu,
24 May 2012 11:17:53 -0700 (PDT)
Received: by 10.194.60.167 with HTTP; Thu, 24 May 2012 11:17:53 -0700 (PDT)
In-Reply-To: <4FBE7560.4090502@gentoo.org>
References: <4FBCDB3D.1070009@gentoo.org>
<robbat2-20120523T164346-726762549Z@orbis-terrarum.net>
<1473095.PKeReGjyol@smorgbox>
<4FBD5B42.7090809@gentoo.org>
<CAATnKFCx0P+0nTP1B6LC+LDektPxqRoUCsR9jAJZx9WfV080hQ@mail.gmail.com>
<20120524164002.50092941@pomiocik.lan>
<20120524170224.728c194e@sera-17.lan>
<CAATnKFAfFAYrt=HWtU4uu68XqReVK102hh9z4BJCQ8bP-p7FyQ@mail.gmail.com>
<4FBE7560.4090502@gentoo.org>
Date: Fri, 25 May 2012 06:17:53 +1200
Message-ID: <CAATnKFADo3Hhr45J-+Ynnv5UtWqdiXAK9v6W6ZZ7vHuAiyMtdg@mail.gmail.com>
Subject: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 5d1dd059-ed26-4eb9-b112-c29e0291eebe
X-Archives-Hash: bc7ee1f07dfb3a1476b7ae1e96abf74b
>
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do?? I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> 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)
Yes, we want them to.
There is still going to be a "master" authoritative tree, forks of
that tree will exist for the purpose of adding new ebuilds to the
master tree / bumping existing packages.
If your worry is "There are copies of gentoo /usr/portage out there
that aren't GIT HEAD" , then stop worrying, as thats already the case.
As soon as somebody modifies a file in their local /usr/portage, that
happens, and as soon as a users portage tree gets older than 1 hour,
that happens.
And if your worry is "But they could be replicating it in that form",
then don't worry, they could already be doing that, nothing is
stopping people from re-providing their full (tweaked) /usr/portage
via rsync to others. In fact, if you're running in a network with a
network master, you're doing that to an extent.
But those sources are not official, and have no utility outside
development/private use scenarios, and thus, don't compete with
overlays directly.
Sure, you *could* make something like an overlay by forking gentoo
master and then maintaining that, but it would be impractical, and
you'd be better off using a plain overlay ( less noise ), or using
that fork for the purpose of getting things in master.
You /could/ do a long-lived public maintained fork, and then you'd be
Sabyon / Funtoo.
Doing this has its own difficulties, but I think long term, enabling
this is good:
Sabyon/Funtoo can fork gentoo on github, and then any improvements
made on their forks, gentoo can easily steal back, and its easier to
track the differences between them. Win/Win in my books.
Summarised:
Yes, its a good idea.
No, we shouldn't try stopping them.
Actually, really can't stop them, its already happening, Git will just
make the workflow better on top of it.
--
Kent
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
http://kent-fredric.fox.geek.nz