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 808971386F3 for ; Wed, 12 Aug 2015 07:21:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C21AC141CD; Wed, 12 Aug 2015 07:21:20 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B3A9FE07E8 for ; Wed, 12 Aug 2015 07:21:19 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZPQLU-0004sB-KM for gentoo-dev@lists.gentoo.org; Wed, 12 Aug 2015 09:21:08 +0200 Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Aug 2015 09:21:08 +0200 Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Aug 2015 09:21:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Bisecting Was: Referencing bug reports in git Date: Wed, 12 Aug 2015 07:20:54 +0000 (UTC) Message-ID: References: <55C75F19.90201@gentoo.org> <20150809215605.27ae6427@pomiot> <20150810004409.59637bea9aefd3f045b67614@gentoo.org> <20150810004044.76dda6e6@pomiot> <20150810021601.cdcae7226373ecd0d284086a@gentoo.org> <21959.62847.967959.705319@a1i15.kph.uni-mainz.de> <55C7F833.6040408@gentoo.org> <20150810181730.3ef13778@caribou.gateway.pace.com> <20150811085732.GA128486@skade.schwarzvogel.de> <55C9E35C.3070406@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=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip98-167-165-199.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT af87825) X-Archives-Salt: e5a895fa-8e5a-42ac-8ac4-1e4e76312994 X-Archives-Hash: f25b273322bc967f7ba7618a756a5e5e hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted: > In addition, we just took the freedom to add the clause "all commits > must be repoman-valid": > https://wiki.gentoo.org/index.php? title=Gentoo_git_workflow&diff=352978&oldid=352858 > > That will be necessary too for the CI work mgorny is doing and will also > make bisecting and cherry-picking easier. The mention of bisect got me thinking... I'm not exactly sure I'm wording this right, but hopefully the question is clear enough... What are the practical implications of and reasons for doing a bisect, on a package-tree repo, where it's typically the out-of-tree package sources where most functionality-bisection would happen, and in-tree commits tend to result in atomic package updates, or at least atomic USE flag, etc, changes on a package? The typical reason for a bisect is to find the commit where a bug originated, but that's upstream package/project bisects. I don't quite see how that maps to distro package tree repo bisects, as it seems to me there's nothing really to bisect -- problems should be with specific package versions or with USE flag or similar changes within an ebuild/ eclass, and it seems to me that's known along with awareness of the problem in the first place, leaving no reason to bisect to find the problem. Tho arguably eclass change issues are an exception, and bisectable in the usual sense for the usual purpose. Actually, that could make troubleshooting eclass updates MUCH simpler than it was before. Luckily, at least I as a user didn't end up with too many direct eclass issues to troubleshoot. Tho I can definitely think of a non-traditional use for bisect. While I update my workstation more or less weekly, I updated my 32-bit netbook[1] far less frequently, every year or two. It occurs to me that using git bisect to automate working out the resulting update issues might be far easier than some of the manual tricks and workaround I used to end up doing, to finally get an updated to current, working system once again. Bisect start, immediately declare bisect bad, inner looping until I got to about a three-month update, update to it, bisect reset, outer-looping on the bisect to another 3-4 month update... until I was caught up. Of course one can't go back past our current switch to git, but in five years, one could in theory pull the old laptop out that was last updated yesterday, and roll back gentoo's now five-years-future tree four years and nine months, and start the update process, ultimately bringing it upto date without starting with a new stage tarball install, as would have been the only really feasible pre-git alternative for a five-year-outdated system. Not that a new stage tarball wouldn't be faster after five years in any case, but at least the incremental update- in-place should now be possible. --- [1] 32-bit netbook: Now gone and not yet replaced, but I intend to get another, tho amd64 this time so I can mostly build once for both, one for three if I setup an amd64-based router as I intend to as well, and hopefully avoid the year-plus update period issue as I can just binpkg- update after the first one. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman