Hi Otavio,

the codebase does not have the release quality
after each commit. Test-driven development could
even invite devs to separately commit failing tests
as a proof they are effective.

On contrary the release-tagged commits should
be safe. Would not help you to focus
on the release-tagged commits only, pls?

  Hope it helps
  Cc.

--
  Mr. Petr Kužel, Software Engineer
  Eurofins International Support Services s.à r.l.
  Val Fleuri 23
  L-1526 LUXEMBOURG

-----Original Message-----
From: Otavio Rodolfo Piske <angusyo...@gmail.com>
Sent: Wednesday, June 21, 2023 11:17
To: dev <dev@camel.apache.org>
Subject: Some thoughts on bisecting Camel and our git commit practices


Folks,

You may have seen that PRs constantly report failures when testing changes
on core. This is almost always caused by flaky tests.

I have been trying to find the root causes of those flaky tests. Quite
often this involves going all the way to early versions of Camel 3 to find
stable executions of those tests.

The investigation itself is mostly automated by using git bisect run ...
This significantly improves the developer ability to find the root causes
of issues.

Despite all this automation, however, the task has been ... quite difficult
and lengthy. Even considering the extensive resources I have access to
(thanks to my employer), bisecting a single test failure can take several
*days*.

In particular, this investigation has been difficult because we have a huge
amount of dirty commits on the tree: partially modified work, uncompilable
changes, broken tests and more.

While it's NOT my intention to suggest introducing/discussing a full blown
clean commit policy, I do wonder if we have some room to discuss how we can
improve the way we work to ensure that the tree is compilable and somewhat
testable (and, possibly, enforce that).

We cannot fix the git history of the project, but we can ensure that future
investigation can be made much easier in the future.

So, folks, does anyone have any suggestions about how we could improve
here?

Kind regards
--
Otavio R. Piske
http://orpiske.net/

Reply via email to