From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D16D3139737 for ; Tue, 11 Aug 2015 15:21:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC426141CD; Tue, 11 Aug 2015 15:21:30 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C0F3B141A2 for ; Tue, 11 Aug 2015 15:21:29 +0000 (UTC) Received: from localhost (AMontpellier-655-1-318-6.w86-202.abo.wanadoo.fr [86.202.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 43EBC340D03 for ; Tue, 11 Aug 2015 15:21:28 +0000 (UTC) Date: Tue, 11 Aug 2015 17:21:22 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Developer branches on proj/gentoo Message-ID: <20150811172122.07c79e90@gentoo.org> In-Reply-To: <55CA10AF.1000204@gentoo.org> References: <20150811135216.GG21010@sigkill.axestech.net> <20150811160105.5e3ceb08@pomiot> <55CA10AF.1000204@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e97b1385-8481-4b48-a262-6a14f2968229 X-Archives-Hash: 723119105386f071a85c56c03b7620da On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 11/08/15 10:01 AM, Micha=C5=82 G=C3=B3rny wrote: > > Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement > > napisa=C5=82(a): > >=20 > >> Hi there > >>=20 > >> According to > >> https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, > >> > >>=20 > "there may be developer-specific, task-specific, project-specific > branch es > >> etc". As far as I understand, it means I can go and create my own > >> branch on the main repository and push it and it gets spread all > >> over the place. Is that correct? > >>=20 > >> Could someone explain to me the rationale behind this decision? > >>=20 > >> Truth to be told, I kinda dislike the fact any developer can do > >> this. > >=20 > > As long as it's used with caution, I don't see a problem. Of course > > it would be bad if everyone pushed branches for any minor change. > > However, if there is a long-term work going on a branch, I don't > > see a problem with keeping it public. > >=20 >=20 > Examples in particular I can think of for something like this being > useful would be for, say, major EAPI-bump-related feature > implementations (ie, EAPI5 and slot-operators/subslots), or major > across-tree impementation changes like what we saw with the > multilib-eclass porting. >=20 > These are large projects touching most if not all ebuilds, that a > great many developers would or should be involved in. Something like > this could be done in a separately hosted repo instead of in the main > gentoo repo, but then all developers would need to subscribe to this > other repo, while having it in a branch in the main one i think would > make it easier for everyone to get involved once they're ready, and > would still allow the changes to stay out of the master branch until > the project is ready to launch. For me, this is actually a reason to prohibit it :) EAPI bumps should be done package by package, not at a major scale: otherwise, let's just scrap EAPI entirely and update the API as we see fit with p.masked package managers :) multilib eclasses conversions should also be done one by one to be done properly (otherwise using multilib-portage is probably a better idea) and each conversion touches one package (two if you count emul-*). Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit?