From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from <gentoo-dev+bounces-22262-garchives=archives.gentoo.org@gentoo.org>) id 1HYjlo-0005T4-IN for garchives@archives.gentoo.org; Tue, 03 Apr 2007 14:14:01 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l33ED0XE002185; Tue, 3 Apr 2007 14:13:00 GMT Received: from smtp01.atlngahp.sys.nuvox.net (smtp-out1.atlngahp.sys.nuvox.net [70.43.63.18]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l33EB9j6032385 for <gentoo-dev@lists.gentoo.org>; Tue, 3 Apr 2007 14:11:09 GMT Received: from [10.3.23.140] (216.215.202.4.nw.nuvox.net [216.215.202.4]) (authenticated bits=0) by smtp01.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with ESMTP id l33EB3ZT025824 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <gentoo-dev@lists.gentoo.org>; Tue, 3 Apr 2007 10:11:05 -0400 Subject: Re: [gentoo-dev] Re: SCM choices From: Chris Gianelloni <wolf31o2@gentoo.org> To: gentoo-dev@lists.gentoo.org In-Reply-To: <460E2F68.6000807@gentoo.org> References: <1174788467.4883.29.camel@bruichladdich> <200703280938.19798.csawtell@paradise.net.nz> <20070327225321.2cad4182@snowflake> <200703281030.57196.csawtell@paradise.net.nz> <20070327234305.7760e0a7@snowflake> <460A43AF.3090105@gentoo.org> <1175083139.10622.9.camel@inertia.twi-31o2.org> <20070328152313.786dd81c@c1358217.kevquinn.com> <460E2F68.6000807@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zm4rbge+5B1vxCHDfDfb" Date: Tue, 03 Apr 2007 10:11:03 -0400 Message-Id: <1175609463.8202.29.camel@inertia.twi-31o2.org> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 X-Archives-Salt: 188fb48d-7b9f-4aab-8d02-0f883f09b313 X-Archives-Hash: 6a0866ac5197d07d2bb77f278e62a6f5 --=-zm4rbge+5B1vxCHDfDfb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2007-03-31 at 11:52 +0200, Marijn Schouten (hkBst) wrote: > So in light of all that I don't think it is wasteful to restart this disc= ussion. I do. Want to bring it back up? Go perform some tests and report back with some data if you feel prior efforts weren't done properly or reproducible. My *entire* point was that *discussion* of this issue is worthless compared to numbers and data. I see no need to hear 300+ people tell everyone else their *opinion* on what they *think* is better. Seeing some actual data, though, should be definitely encouraged. > 1) get commit access to the repository and start a branch in there. Mergi= ng may not be too hard, I > don't really know. However CVS commit access is not something that is giv= en lightly. It would vice > versa also mean that you would have commit access to my stuff, which I mi= ght not like. Release Engineering has its own space for officially-released and in-progress media. Your stuff wouldn't really fall under that category, so there's no need for you to have commit access to the repository. Release Engineering holds final say on all changes and they need to go through Release Engineering for testing before they will be accepted. This is how all of our changes work and it's worked pretty well for us. > 2) file bugs with patches attached. But maybe you just want to forget abo= ut releases until 2007.1 > comes along once 2007.0 is finished. You are correct. Release Engineering is not concerned with the interim state of the tree, and therefore has no need for constantly updating the spec files. We focus our attention on the release snapshots and make changes based on said snapshot, not on the current state of the tree. We all have better things we would like to do than constantly update spec files. Now, if you're talking about working with Release Engineering during release times, that would be grand, but anything off-cycle wouldn't be of much interest for us. Also, remember that there's really no point in refreshing media on a constant basis. I could see refreshing it after a new kernel version goes stable, and that's about it. Anything else seems like a terrible waste of time and resources for minimal gain. In most cases, your CD wouldn't change at all from day to day. For QA purposes, I run builds year-round. I just don't release them because I don't test them thoroughly. > 3) fork the code or convert the repository into a repo of my own. Even if= I choose to use the same > kind of repo (CVS in this case), then how hard will merging be? Again, th= is goes both ways. You don't merge. You would file a bug with the changes and we would either accept or deny the changes on a case-by-case basis. > I hope I missed something here, but of the three the third looks the most= appealing and likely with > me forking into darcs probably. I don't think this issue would be here if= the code were in a > distributed SCM, but maybe by the time 2007.1 is due I will have amassed = enough interesting changes > that it is easier for you to then just clone my distributed repo ;P. Again, it is *very* unlikely. If you look at the changes in the minimal CD set between releases, you will see that it is extremely minimal, if changes are even made. We simply don't change things that work. The only changes that really go in are bug fixes. Are you saying that you're going to be tracking all of the release bugs and fixing only those? Are you planning on adding features? The former would be helpful to Release Engineering, the latter would not be nearly as useful to us unless they were absolutely compelling. > So can we please discuss what distributed SCM is best for the tree or lik= ely to be in the future and > what hard data obtained with what tests should be gathered to rank SCMs a= nd what feature differences > there are and how much we should care about them? I don't get why you discuss a distributed SCM, then proceed to talk about minimal CD + releases stuff which has nothing to do with the main tree. We keep our spec files in CVS, but it isn't the same repository as the tree. If you're talking about changing the tree, then yes, you should be filing bugs and getting them fixed in the tree. I'm honestly not sure what exactly it is that you're trying to accomplish. Some additional explanation would be great. Again, if you want to see the tree converted to something else, you need to show compelling reasons and data *why* it should be done. Discussing it doesn't really show those things and lends itself to giving only beliefs, political or personal, about given SCM software. I honestly don't care what anybody *thinks* about any particular SCM. I am interested in the facts and numbers. I don't have much preference myself other than that I already know CVS/SVN. If we were to make a change, even to SVN, I'd like to see some well-thought-out reasons why and some numbers to back it up. --=20 Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation --=-zm4rbge+5B1vxCHDfDfb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQBGEmB2kT4lNIS36YERAh6MAJwNjUFTGZlswNUw9u8s6uGTbMLEsACgwlnJ 3lGIyw5vtBkH2mmr2+B7jHw= =Mx7E -----END PGP SIGNATURE----- --=-zm4rbge+5B1vxCHDfDfb-- -- gentoo-dev@gentoo.org mailing list