4 ms·

I'd very much like to have some more information about how the article author gathered this data - are these all master branches of said projects, numbered rele

by hurin 12y ago

I'd very much like to have some more information about how the article author gathered this data - are these all master branches of said projects, numbered releases? How does the data account for variation in development procedures (e.g. some projects use master as their bleeding edge branch)?

scott2449 12y ago
The data is not really relevant for the reasons you state + failed build does not equal published artifacts. How long were the builds in that state? etc.
mirashii 12y ago
Also consider that if its checked on a commit by commit basis that doesn't collapse merges in somehow, then you actually check every commit that was made during incremental work on a different branch. If you're doing TDD or any test first methodology, that's going to often mean you intentionally commit broken tests to fix them. Also if its a commit by commit basis, the percentage of time comparison is completely invalid.
- chrismcb 12y ago
  The author is talking about broken builds, not broken tests.
  - sciurus 12y ago
    In this context they're synonymous. A broken build is defined by the tests failing.
lambda 12y ago
How does the data account for variation in development procedures (e.g. some projects use master as their bleeding edge branch)? That shouldn't matter. You should always be able to successfully check out, build, and pass all tests on master. Otherwise, how are people expected to get development done? If you aren't able to build and run tests because you need to be fixing something that someone else committed broken, it will be a lot harder to ever make real progress. Even if it's "bleeding edge", master should always build and always pass at least the minimal "fast" test suite; some projects may have more thorough "full" test suites that take many hours to run, and requiring that those be run on every change would slow down development too much, but at the very least, the quick "sanity check" test suite should always pass before something can land on master.

by hurin 12y ago

scott2449 12y ago

The data is not really relevant for the reasons you state + failed build does not equal published artifacts. How long were the builds in that state? etc.

mirashii 12y ago

Also consider that if its checked on a commit by commit basis that doesn't collapse merges in somehow, then you actually check every commit that was made during incremental work on a different branch. If you're doing TDD or any test first methodology, that's going to often mean you intentionally commit broken tests to fix them. Also if its a commit by commit basis, the percentage of time comparison is completely invalid.

chrismcb 12y ago
The author is talking about broken builds, not broken tests.
- sciurus 12y ago
  In this context they're synonymous. A broken build is defined by the tests failing.

lambda 12y ago

How does the data account for variation in development procedures (e.g. some projects use master as their bleeding edge branch)? That shouldn't matter. You should always be able to successfully check out, build, and pass all tests on master. Otherwise, how are people expected to get development done? If you aren't able to build and run tests because you need to be fixing something that someone else committed broken, it will be a lot harder to ever make real progress. Even if it's "bleeding edge", master should always build and always pass at least the minimal "fast" test suite; some projects may have more thorough "full" test suites that take many hours to run, and requiring that those be run on every change would slow down development too much, but at the very least, the quick "sanity check" test suite should always pass before something can land on master.