On 12/4/2024 2:17 PM, Christopher Clark wrote:
On Wed, Dec 4, 2024 at 7:24 PM Gundlupet Raju, Sandeep
<[email protected]> wrote:
On 12/4/2024 11:35 AM, Bruce Ashfield wrote:
On Wed, Dec 4, 2024 at 1:07 PM Gundlupet Raju, Sandeep
<[email protected]> wrote:
Hi Bruce, Chris,
Do you have any more comments on patches? If there are no
comments can
we get this patches merged?
I haven't reviewed them yet and probably won't until next week.
Generally speaking it isn't wise to attempt to rush a merge, in
particular when it has been 5 days with an extended weekend in
the middle.
Ok sounds good.
I do have a general comment on the series that I would like to see
improved: as posted, it isn't bisectable and my view is that it should
be made to be.
Patch 3 introduces a file defining variables that are already defined
elsewhere, and then patch 4 removes them from their previous
definition site. Since these are not combined into a single patch, the
layer is temporarily broken, when patch 3 is applied, and then fixed
as patch 4 is added, and there are lasting consequences for consumers
of the layer for this class of breakage.
[Sandeep]: Chris sorry about that looks like my scripts didn't generate
the patches with right branch settings. I will take a look. Bruce will
you accept new bbclass patch for scarthgap release?
A simple negative consequence is that it adds complexity to the work
of managing other branches where commits are selected from the primary
development branch: the second commit must _always_ be taken whenever
the first is - that's not a terribly unusual constraint when working
with series of patches though, and many patches make more sense in
groups. This is not the primary issue.
A more serious and expensive consequence is that it blocks the ability
to use bisection to hunt difficult bugs in the system. If testing
indicates that a defect is introduced somewhere between two distant
commits to the layer, an efficient way to identify which commit
introduces the fault is to iteratively bisect between the two points
on the branch, and test a build at each - if it the fault is not
present, retain the patches applied and bisect the remaining ones to
apply more, and if not, drop the most recently applied set and bisect
it to apply fewer of them, and then retest. Iterating this way to
quickly find a single problematic commit is a deterministic process
and often automatable - see "git bisect" - but that depends on each
commit on the branch being viable, and not introducing intermittent
breakage along the way - if that constraint isn't satisfied then the
build or testing process is frustrated and the process of steering the
iterative bisection becomes more difficult, often requiring informed
engineering expertise rather than simple automation, and so much slower.
Builds are expensive, testing is expensive and engineering time is
expensive, so doing the work to support bisection when patch series
are developed and merged is a valuable contribution to support the
engineering environments that consume the layer, improving their
efficiency and assisting the development of better quality software
and systems.
[Sandeep]: I totally understand on merge and build time.
Christopher
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9042):
https://lists.yoctoproject.org/g/meta-virtualization/message/9042
Mute This Topic: https://lists.yoctoproject.org/mt/109841154/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
