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 1SXBPX-0002Ev-QG for garchives@archives.gentoo.org; Wed, 23 May 2012 13:15:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 48482E05C1; Wed, 23 May 2012 13:15:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 0C205E055C for ; Wed, 23 May 2012 13:14:34 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thev00d00) by smtp.gentoo.org (Postfix) with ESMTPSA id 075441B4033 for ; Wed, 23 May 2012 13:14:33 +0000 (UTC) Received: by bkcjk13 with SMTP id jk13so6818075bkc.40 for ; Wed, 23 May 2012 06:14:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=bNPGcspU11Iz02zBC/rmCLIQUNrzmLPKx/onGh9jul4=; b=mDuPFDKNFhndrH2qnAcb9+Y5nVLriwq/kkK4+hwMVxlEYPoCo5HmC77jZlzglEHcE8 MfRlmq74UxoH9V2gtcCC4qlWCNUFGY6SDeL9qsr/dL5BiSpD5VQKYDoGAHoG6WpAR/zW Ji6MsP3/N06eTjEcXE9FAzije/FSZJOZa02l4SWqJl5dadyHy4muuzY3Y/3goWfFuvgT o8vPYlqptc3eMKgOQuytFSoOyjKO9OfYzztl6dOi+gY0g8atWQq9cCheyvNaDN4r7W0P CiElv3h+AwUeg5aKveW5j/FCzGMwdGch4DvphQKpxv41hLmS9Ca1T4ZqvQJAVpV36fFk Iu1Q== 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 Received: by 10.204.154.18 with SMTP id m18mr12207706bkw.23.1337778871375; Wed, 23 May 2012 06:14:31 -0700 (PDT) Received: by 10.204.225.77 with HTTP; Wed, 23 May 2012 06:14:31 -0700 (PDT) X-Originating-IP: [92.40.253.7] Received: by 10.204.225.77 with HTTP; Wed, 23 May 2012 06:14:31 -0700 (PDT) In-Reply-To: <2427401.lzvKUfhUMv@marin> References: <4FBCDB3D.1070009@gentoo.org> <2427401.lzvKUfhUMv@marin> Date: Wed, 23 May 2012 14:14:31 +0100 Message-ID: Subject: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver From: Ian Whyman To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=00151748e0ec6a98f304c0b3ea39 X-Gm-Message-State: ALoCoQn9v1HOgFHugZ3frklHRbMjNJ7vsEpnHv0cKAEjzbvQlCUoOp5oZ6NFvrL5wYtDWNrxbaw8 X-Archives-Salt: 46e912ba-5ab9-458d-b79f-45568cfbcce8 X-Archives-Hash: 5bde03c5f1955cb211963eda64889e86 --00151748e0ec6a98f304c0b3ea39 Content-Type: text/plain; charset=UTF-8 On May 23, 2012 1:55 PM, "Johannes Huber" wrote: > > Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > Hi, > > > > > > i've looked at the blockers of "[TRACKER] portage migration to git" > > > [1] and want to discuss "testing git-cvsserver" [2]. > > > > > > There are two proposed scenarios how to migrate the developers write > > > access to the portage tree. > > > > > > "Clean cut" turns of cvs access on a given and announced timestamp, > > > rsync-generation/updates is suspended (no input -> no changes), some > > > magic scripts prepare the git repo (according to [3], some hours > > > duration) and we all checkout the tree (might be some funny massive load). > > > > > > "testing git-cvsserver" proses "Clean cut" with the additional ability > > > to continue using cvs update/commit, - in best case - on the old > > > checkout w/o alteration on the developers side. > > > > > > "Clean cut" forces us to clean up out dirty checkouts (I have some > > > added directories, added ebuilds i hesitated to `repoman commit`). > > > Plus we have to alter all our hot-wired portage mangling scripts from > > > cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs > > > checkout + egencache for checkout) and have an automated google-chrome > > > bump script). But this can be accomplished on a per developer basis, > > > and slackers don't stall the process. > > > > > > "testing git-cvsserver" forces us all to test these cvs'ish scripts > > > and behaviours against a git-cvsserver and report. > > > We all know that this test-runs will never happen, stalling this bug > > > till infinity. > > > Plus infra/"subset of devs marshalling the migration" get stuck > > > between fixing git issues and git-cvsserver. > > > > > > *if you still read this* *wow* > > > > > > Please discuss my arguments and come to the conclusions to > > > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove > > > this bug from the blockers of "[TRACKER] portage migration to git". > > > > > > My lengthy 2 cents. > > > > > > [1] https://bugs.gentoo.org/333531 > > > [2] https://bugs.gentoo.org/333699 > > > [3] https://bugs.gentoo.org/333705#c2 > > > - -- > > > Gentoo Dev > > > http://xmw.de/ > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v2.0.17 (GNU/Linux) > > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > > > iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd > > > VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW > > > =jXLQ > > > -----END PGP SIGNATURE----- > > > > I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. > > > > Clean cut++ > > > > Cheers > > -- > > Johannes Huber (johu) > > Gentoo Linux Developer / KDE Team > > GPG Key ID F3CFD2BD > > Another vote for clean cut from me. --00151748e0ec6a98f304c0b3ea39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 23, 2012 1:55 PM, "Johannes Huber" <johu@gentoo.org> wrote:
>
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
>
> > Hash: SHA256
>
> >
>
> > Hi,
>
> >
>
> > i've looked at the blockers of "[TRACKER] portage migrat= ion to git"
>
> > [1] and want to discuss "testing git-cvsserver" [2]. >
> >
>
> > There are two proposed scenarios how to migrate the developers wr= ite
>
> > access to the portage tree.
>
> >
>
> > "Clean cut" turns of cvs access on a given and announce= d timestamp,
>
> > rsync-generation/updates is suspended (no input -> no changes)= , some
>
> > magic scripts prepare the git repo (according to [3], some hours<= br> >
> > duration) and we all checkout the tree (might be some funny massi= ve load).
>
> >
>
> > "testing git-cvsserver" proses "Clean cut" wi= th the additional ability
>
> > to continue using cvs update/commit, - in best case - on the old<= br> >
> > checkout w/o alteration on the developers side.
>
> >
>
> > "Clean cut" forces us to clean up out dirty checkouts (= I have some
>
> > added directories, added ebuilds i hesitated to `repoman commit`)= .
>
> > Plus we have to alter all our hot-wired portage mangling scripts = from
>
> > cvs'ish to git'ish (I use my read/write checkout as porta= ge tree (cvs
>
> > checkout + egencache for checkout) and have an automated google-c= hrome
>
> > bump script). But this can be accomplished on a per developer bas= is,
>
> > and slackers don't stall the process.
>
> >
>
> > "testing git-cvsserver" forces us all to test these cvs= 'ish scripts
>
> > and behaviours against a git-cvsserver and report.
>
> > We all know that this test-runs will never happen, stalling this = bug
>
> > till infinity.
>
> > Plus infra/"subset of devs marshalling the migration" g= et stuck
>
> > between fixing git issues and git-cvsserver.
>
> >
>
> > *if you still read this* *wow*
>
> >
>
> > Please discuss my arguments and come to the conclusions to
>
> > RESO/WONT-FIX "testing git-cvsserver", make a "cle= an cut" and remove
>
> > this bug from the blockers of "[TRACKER] portage migration t= o git".
>
> >
>
> > My lengthy 2 cents.
>
> >
>
> > [1] https://bugs.gento= o.org/333531
>
> > [2] https://bugs.gento= o.org/333699
>
> > [3] https://bugs.ge= ntoo.org/333705#c2
>
> > - --
>
> > Gentoo Dev
>
> > http://xmw.de/
>
> > -----BEGIN PGP SIGNATURE-----
>
> > Version: GnuPG v2.0.17 (GNU/Linux)
>
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> >
>
> > iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd<= br> >
> > VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW<= br> >
> > =3DjXLQ
>
> > -----END PGP SIGNATURE-----
>
> =C2=A0
>
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it w= as opened it is obvious out of interest. There is no reason to support jura= ssic software.
>
> =C2=A0
>
> Clean cut++
>
> =C2=A0
>
> Cheers
>
> --
>
> Johannes Huber (johu)
>
> Gentoo Linux Developer / KDE Team
>
> GPG Key ID F3CFD2BD
>
> =C2=A0

Another vote for clean cut from me.

--00151748e0ec6a98f304c0b3ea39--