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 1SbgFG-0003Uf-7l for garchives@archives.gentoo.org; Mon, 04 Jun 2012 22:59:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 01E58E0687; Mon, 4 Jun 2012 22:59:06 +0000 (UTC) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 63DBEE0B6B for ; Mon, 4 Jun 2012 22:57:32 +0000 (UTC) Received: by dadg9 with SMTP id g9so7647120dad.40 for ; Mon, 04 Jun 2012 15:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nahbhcGyvPguWmqtlsZc+kb5HcILFw5WdwCx4xsIBNo=; b=AyincxF9VWBtHTydNH4eg051LZwpR2xKHN7PN+Bl0JezwwTp7aSez92rmc5Ie82nmP s8PkJjDPGyZpdiwgoXj47cZapBURbNDaUl1hk5sy9+E7HJ+IWzE4RVjl7BM02X8D4/r5 aXUnO+A1FRnmLEjCKLGZlFBwQ0x5ka6C+tarOIUoOJcD9HavJTAdRT2G0cl8rbDAmyN0 ozdmzpzo3ng9g20+XhtdS+ePouAZCmokULF+xZNRNHG0uAp77GL7HYR8/8MQW3N46If1 3c1dgI83iYX1AiCH/6kYW8AJDqcN9zCtu5w5Qlzhj3h8Re0I9Wu5rR1ivoJBl7gXxlYY muOg== Received: by 10.68.138.166 with SMTP id qr6mr43951433pbb.43.1338850651742; Mon, 04 Jun 2012 15:57:31 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id np8sm94797pbc.71.2012.06.04.15.57.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 15:57:30 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Mon, 04 Jun 2012 15:57:53 -0700 Date: Mon, 4 Jun 2012 15:57:53 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators) Message-ID: <20120604225753.GC3692@localhost> References: <20120604132505.GB23002@localhost> <4FCD3854.8030203@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FCD3854.8030203@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 66fc3295-c860-4f42-ad33-e029adc0c492 X-Archives-Hash: aee8c3fa6b7780114d2770ba3f2b2581 On Tue, Jun 05, 2012 at 12:36:04AM +0200, Michael Weber wrote: > On 06/04/2012 03:25 PM, Brian Harring wrote: > > While I do grok the potential issue of someone being a hog > > (specifically via blasting commit by commit rather than building up > > work locally, then pushing it in chunks), frankly... I'm not that > > concerned about it, and would rather deal w/ it if/when it occurs. > > The nature of our commits for the most part are standalone from > > others- that's not true of the kernel/mozilla, thus why I don't > > think their issues are necessarily ours. > True. > > We already have maintainers and herds as responsible (sole editors) > entities for locations (packages). > > But, we have arch teams editing ebuild/KEYWORDS, which alters > Manifest/EBUILD lines. Resulting in potential clashes (not > fast-forwardable), if the herd or maintainer does bumps or cleanups. > > Will these Manifest lines (and the arch team inflicted Manifest changes)? Converting to git, we'll switch over to thin manifests- they're *just* the checksums for the distfiles, no need for the rest since git already provides that verification implicitly. That just leaves conflict w/in ebuilds, which is a valid "the dev needs to deal with this themselves" scenario imo. > According to robbat2 data (gentoo-commit tarball) we have ~400k > commits in gentoo-x86 (w/o proj,xml) in 4.7 years, that's 6.2 per hour > averaged. > But I've to look into the data to see trends (# developers, daylight). One thing to note- that's *individual* commits, and probably a mildly jacked up number due to the double tap requirement of commiting manifests to CVS. What I'm driving at is that there's a difference between commits/revisions, and pushs; I expect our push rate to be less; I'd be surprised if we're doing 1:1 commit/push rate. The conflict rate should be less painful for people in that light, or at least has been in my experience thus far. Btw, good catch on package.mask. Hhadn't thought of that, that *will* be the most contentious point. That can be dealt w/ via having git on portage-1 profile format so we'd have package.mask as directories (which Ciaran will validly hate, and I won't like due to having to write the portage-1 -> PMS translater for rsync distribution), or coming up w/ a different way to split the commits across multiple files, rather than a single. That's assuming package.mask becomes a significant conflict point also. Frankly I'd rather deal w/ that problem when it arrises, rather than trying to optimize for it now. ~harring