On Wed, Aug 12, 2015 at 07:20:54AM +, 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
>
>
