Date: Mon, 4 Jan 2021 09:27:10 -0800 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@freebsd.org> Cc: Mark Millard via freebsd-git <freebsd-git@freebsd.org> Subject: Re: Reporting context with list submittals for defects when local git branches are involved: needs a new description? Message-ID: <B664A6E4-801F-4775-96C3-905566763D22@yahoo.com> In-Reply-To: <X/NCGVQvHE7TmBue@acme.spoerlein.net> References: <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D.ref@yahoo.com> <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D@yahoo.com> <CAHgpiFzjKRAkECccUgMWzOoq=syRC9j0hwHR4U6WvJMEf0p%2B_g@mail.gmail.com> <29E9AA04-C66B-4298-B84D-6549A88C038B@yahoo.com> <X/NCGVQvHE7TmBue@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-4, at 08:28, Ulrich Sp=C3=B6rlein <uqs at freebsd.org> =
wrote:
> On Mon, 2021-01-04 at 01:41:29 -0800, Mark Millard via freebsd-git =
wrote:
>>=20
>> On 2021-Jan-4, at 00:39, Ryan Libby <rlibby at freebsd.org> wrote:
>>=20
>>> On Sun, Jan 3, 2021 at 7:23 PM Mark Millard via freebsd-git
>>> <freebsd-git@freebsd.org> wrote:
>>>>=20
>>>> I use a main context here to provide an example of the
>>>> issue. I'm not claiming main is the only context with
>>>> the issue.
>>>>=20
>>>> Taking an extremely simple case where I'm targeting the
>>>> head of what git fetch freebsd provided, with my local
>>>> patches (re)applied via rebase:
>>>>=20
>>>> # git reflog
>>>> c9819aa7b91c (HEAD -> mm-src) HEAD@{0}: rebase (finish): returning =
to refs/heads/mm-src
>>>> c9819aa7b91c (HEAD -> mm-src) HEAD@{1}: rebase (pick): mm-src =
snapshot for mm's patched build in git context.
>>>> d03fd8ede2c4 (freebsd/main, freebsd/HEAD, main) HEAD@{2}: rebase =
(start): checkout d03fd8ede2c4
>>>> . . .
>>>>=20
>>>> One could imagine that I'd picked to work from something
>>>> older than d03fd8ede2c4 (say to avoid a known problem).
>>>> Either way, uname returns the likes of:
>>>>=20
>>>> # uname -apKU
>>>> FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT =
mm-src-c255571-gc9819aa7b91c GENERIC-NODBG amd64 amd64 1300133 1300133
>>>>=20
>>>> (I've been experimenting with reproducible builds but that
>>>> does not change the point: The identification ends up being
>>>> specific to my local branch, other than the 1300133's.)
>>>>=20
>>>> Thus it appears that the:
>>>>=20
>>>> # freebsd-version ; uname -a
>>>> 13.0-CURRENT
>>>> FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT =
mm-src-c255571-gc9819aa7b91c GENERIC-NODBG amd64
>>>>=20
>>>> historically used is not sufficient when local branches are
>>>> involved.
>>>>=20
>>>> It looks like something like the partial git reflog showing a
>>>> relationship to a freebsd/main or freebsd/HEAD commit is
>>>> effectively required, or at least some wording like a "based on
>>>> freebsd/main d03fd8ede2c4" is required and no tool currently,
>>>> directly provides appropriate information: it is a manual
>>>> operation.
>>>>=20
>>>> Food for thought.
>>>>=20
>>>> . . .
>>>>=20
>>>> _______________________________________________
>>>> freebsd-git@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-git
>>>> To unsubscribe, send any mail to =
"freebsd-git-unsubscribe@freebsd.org"
>>>=20
>>> Does this show what you expect?
>>> git log --oneline --parents freebsd/main..c9819aa7b91c
>>>=20
>>> Or for just the "merge base" commit:
>>> git merge-base freebsd/main c9819aa7b91c
>>>=20
>>> Yes, we should document something like that for filing bugs.
>>>=20
>>=20
>> Avoiding the manual lookup and typing of c9819aa7b91c :
>>=20
>> # git log --oneline --parents freebsd/main..mm-src
>> c9819aa7b91c d03fd8ede2c4 (HEAD -> mm-src) mm-src snapshot for mm's =
patched build in git context.
>>=20
>> # git merge-base freebsd/main mm-src
>> d03fd8ede2c493d0c5a74b625a93a48e018515e1
>>=20
>> The first automatically identifies the commit in my mm-src
>> branch, even if mm-src later gets a new HEAD. Having such
>> recorded in a problem report could be important for the
>> originator of the report (but possibly no one else).
>>=20
>> Cool. Thanks.
>>=20
>> Showing a more complicated example that also involved
>> reverting a couple of commits so that the loader would
>> display on a amd64 machine (a default text mode context):
>>=20
>> # git log --oneline --parents =
freebsd/main..mm-src-2021-01-02.avoid_framebuffer_console_change
>> 2c557eeab90c ff4c62fe5612 =
(mm-src-2021-01-02.avoid_framebuffer_console_change) Revert "loader: =
implement framebuffer console"
>> ff4c62fe5612 33700671c435 Revert "loader: fix build on non-x86 =
platforms"
>> 33700671c435 486580c44ce2 mm-src snapshot taretting just after =
conversion to git.
>>=20
>> # git merge-base freebsd/main =
mm-src-2021-01-02.avoid_framebuffer_console_change
>> 486580c44ce29c1e3b1d9b858a08d9df9428b699
>>=20
>> Here only the last line of the "git log --oneline --parents" has an
>> identification as a freebsd/main commit hash and only the first line
>> has the long-branch-name's "at the time" HEAD identifying hash. But
>> knowing about the reverts could still be important information.
>>=20
>> Adding a named branch that would not get its history rewritten
>> to go with the defect report might be important. So in the mm-src
>> example context earlier, I might not actually use mm-src directly
>> but first create a mm-src.defect-description branch from mm-src
>> instead and then report via mm-src.defect-description . (More
>> to think about.)
>>=20
>> (I've been doing things mostly to experiment.)
>=20
> I'm a bit confused as to what you are asking here, tbh. Are you =
working on a branch of your own? In that case, a bug report needs to =
have some concrete pointers to what you've changed locally, or you need =
to revert to a clean tree or something.
Old PowerMacs do not work sufficiently based on pure FreeBSD. But my
workarounds are genrally not sufficient for committing either. (powerpc
is the primary context that lead to me having some patches. I'll use it
for illustration.) Many problems have nothing to do with what I've
patched. When I can, I instead report based on instead using
artifact.ci.freebsd.org material and its behavior, but some bugs do not
show up in debug builds or the PowerMac support problems make this not
work.
In complicated cases that allowed it, I've reported both from using
artifact.ci.freebsd.org material and from using my patched context,
in part demonstrating that a problem exists in both but providing
additional evidence.
> Or do you just want to have some minor things modified on your tree?
That would probably be a reasonable view of my patches accumulated over
the years, patches that I bring forward as I go. Adding a new one is
fairly rare.
> In that case, maybe using git stash and git rebase --autostash would =
suit you better?
A possibility, but I'm exploring alternatives. git is likely to lead to
more people having local branches involved in how they choose to =
operate.
That in turn may lead to more reports based on such contexts. My =
exploring
may be an early warning.
> Stuffing ever more information into the uname output or version string =
isn't helpful,
I did not ask for changes to uname or the version string. I just =
reported
a type of context for which some other technique seemed to be needed.
It may be that FreeBSD will ask folks to not report based on such
local-branch contexts, that is not for me to say.
So far the "git log --oneline --parents freebsd/main..BRANCH" suggestion
by Ryan Libby seems to cover what I was wondering about, including being
fairly automatic, at least if it ends up being viewed as an acceptable
procedure.
> because as soon as you're 1 commit away from mainline, who knows what =
crazy stuff has happened in your tree?
I understand this risk but the powerpc list has been dealing with my
patched-based context for years and some of what I've done has had some
variant committed to address some of the PowerMac handling oddities,
including one for avoiding frequent boot crashes on G5s, the most
significant behavior improvement adopted from my patch efforts.
In reality, even when I had local source changes never put in svn or =
such,
my patches were normally involved when I was not reporting based on
artifact.ci.freebsd.org materials: a "dirty" context. Having git =
branches
involved does not change that. I would still report based on
artifact.ci.freebsd.org materials when I can.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B664A6E4-801F-4775-96C3-905566763D22>