On Wed, Aug 12, 2015 at 07:20:54AM +0000, Duncan wrote: > 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.
I agree that bisecting would typically not happen that often because usually you'd just emerge =cat/pkg-1.2.3 but there are times when updates are done without a revbump that might have broken something so it could be useful. Also eclasses would definitely be useful. There are a few useful cases when it might make things easier but probably rare, tho its good to have the tool available in case. > 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. I like the idea, but its probably easier to just git checkout $(git rev-list -n 1 --before="2015-12-01 12:00" master) and then you just change the date a month at a time or something -- Jason > --- > [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 > >
