Announcement

Collapse
No announcement yet.

Linus Torvalds Comments On Bcachefs Prospects For Linux 6.6

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by blackiwid View Post

    I never said that, I just said that some of this tests check unimportant things, so you get maybe 1000 errors where 50-200 are important and the rest is unimportant and just best practices standards. They have also a relevance but I can understand from a person that want to make big steps that has a full working schedule that might be problematic.
    Unimportant test? At work we follow a test driven approach using unit tests, behaviour tests, etc pp.:

    For a single one of our microservices there are literally up to 500-1000 specificly written tests and for example one our our applications consists of twelve microservices, just to give you an idea. (This are the figures for an intranet-only, not internet-facing application with an allowed downtime of 7 days and has redundant applications in case of failure. Once internet-facing or with more nines of uptime, you grow on these numbers and install additional measurements. In this post we only talk about one of these "not so demanding" applications)

    On top of these come the standard tests provided by frameworks, all the findings of the IDE, all of the findings of SonarLint and other code style and code format checkers.

    Only *then* the deployment pipeline does not immediately break and hand you an error state which you *have* to fix.

    Oh, and in the pipeline there are additional tests: linters for all the other programming languages you specifically did not locally test, security checks of all the included libraries, for the upstream docker images used in the compilation step, and the base images where your container later runs on.

    Only *then* the actual tests start, which hopefully (but usually, because you already tested thmen locally, didn't you) let you pass.
    Additionally here the first real integration tests fire (hundreds...), which are a little finnicky to test locally.

    And only *then* you are able to deploy on the throw-away dev environment as the very first step with an actual impact.

    Writing buggy programs? Hardly possible but we sometimes manage to. And then we add a couple of more tests to seal the hole once and forever.

    I know it sounds a bit elitist but for me this is the minimum standard of operations and once applied it is very easy to surf on this and have a good night's rest. And yeah, I love my working environment for taking stuff serious and responsibly.

    Last edited by reba; 10 September 2023, 03:16 AM.

    Comment


    • #92
      Originally posted by reba View Post

      Unimportant test? At work we follow a test driven approach using unit tests, behaviour tests, etc pp.:
      You yourself mentioned linters, and they check for "stylistic errors" which I would not even use the word error. And how much you have from what we don't know or I don't your organisation might have a high ratio of very important tests others maybe not.

      Comment


      • #93
        Originally posted by blackiwid View Post
        You yourself mentioned linters, and they check for "stylistic errors" which I would not even use the word error. And how much you have from what we don't know or I don't your organisation might have a high ratio of very important tests others maybe not.
        What is important changes project to project


        Coccinelle is a tool for pattern matching and text transformation that has many uses in kernel development, including the application of complex, tree-wide patches and detection of problematic programming patterns.
        Linux kernel sorry "stylistic errors" those are future nightmares. Part of Linux kernel development is using auto tools to process along the code and generate patches. Yes notice tree-wide patches.

        Style errors can result in semantic patches/coccinelle patches applying incorrect that may not be noticed straight away.

        Lint over code for style is highly important on any software development project using semantic patches/coccinelle patches. Style errors cannot be treated as minor problems it the side effect of using semantic patches.

        Legal and auditing is why you patches have to have correct signing those errors are not option with the Linux kernel. The one - was able to classed as close enough because there are already others merged broken the same way.

        blackiwid getting code into the Linux kernel from the Linux-next stage can take 12+ months like it or not. There is no room in the Linux kernel mainline code for minor errors because due to semantic patches minor error have habits of turning into major ones. The Linux-next branch is not a fun process there are going to be a lot bots putting out a lot code errors that you might want to say are minor but they are not getting past until they are fixed.

        Yes Kent was wanting to skip the 12 months of code review by bots and the code fixing that causes.

        Comment

        Working...
        X