From: Joshua Watt <jpewhacker@gmail.com>
To: Michael Opdenacker <michael.opdenacker@bootlin.com>
Cc: bitbake-devel@lists.openembedded.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Tim Orling <ticotimo@gmail.com>
Subject: Re: [RFC][PATCH 2/3] prserv: add "history" argument to "get-pr" request
Date: Tue, 23 Apr 2024 09:02:44 -0600 [thread overview]
Message-ID: <CAJdd5GYAu=Vsx=o0kncNZLnuQu4cxhe8uN4BTmk_iiToQGKBDQ@mail.gmail.com> (raw)
In-Reply-To: <9bf63d8d-2750-4ee2-ad3d-67fbb029d61c@bootlin.com>
On Tue, Apr 23, 2024 at 6:26 AM Michael Opdenacker
<michael.opdenacker@bootlin.com> wrote:
>
> Hi Joshua
>
> On 4/20/24 at 22:45, Joshua Watt wrote:
> > On Tue, Apr 16, 2024 at 12:20 PM <michael.opdenacker@bootlin.com> wrote:
> >> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> >>
> >> This makes it possible to test the "history" mode in the
> >> future bitbake selftests, to make sure that both "history"
> >> and "no history" modes work as expected.
> > Is this useful in normal day-to-day usage? I don't generally like to
> > add functionality just for testing if it can be helped, as the closer
> > you can get to actual end user API calls, the better it covers the end
> > user experience.
> >
> > It looks like PRData has an (unused) argument to enable history mode?
> > If this is unused do we even actually care about it at all? Maybe it
> > would be better to remove an unused feature than try to test it?
>
> One version of my series actually removed that feature, but then Richard
> asked me to keep the code, because of the usefulness of the "history"
> mode for binary reproducibility. This way, we always generate the same
> package and revision if we have the same output hash as in a prior
> build. That's different from the default behavior that increases the
> revision every time we have a new output hash.
Ah, that's a different story. API used by end users (but not by
bitbake during normal execution) is fine, and a different story than
API added just for testing :)
>
> This being said, supporting both modes added substantial complexity to
> the code, and I wish I had more time to consolidate all this and reduce
> as much redundancy as possible between modes.
>
> Cheers
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
next prev parent reply other threads:[~2024-04-23 15:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 17:19 [RFC][PATCH 0/3] Call for help for prserv selftests michael.opdenacker
2024-04-16 17:19 ` [RFC][PATCH 1/3] prserv: add "upstream" server support michael.opdenacker
2024-04-16 17:19 ` [RFC][PATCH 2/3] prserv: add "history" argument to "get-pr" request michael.opdenacker
2024-04-20 20:45 ` Joshua Watt
2024-04-23 12:26 ` Michael Opdenacker
2024-04-23 15:02 ` Joshua Watt [this message]
2024-04-16 17:19 ` [RFC][PATCH 3/3] prserv: start bitbake selftests michael.opdenacker
[not found] ` <17C6D263417A3CF2.12347@lists.openembedded.org>
2024-04-17 14:34 ` [bitbake-devel] " Michael Opdenacker
[not found] ` <17C717ED8D67DB97.20815@lists.openembedded.org>
2024-04-17 14:42 ` Michael Opdenacker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJdd5GYAu=Vsx=o0kncNZLnuQu4cxhe8uN4BTmk_iiToQGKBDQ@mail.gmail.com' \
--to=jpewhacker@gmail.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=michael.opdenacker@bootlin.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=ticotimo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).