On Sun, May 15, 2016 at 6:46 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > Committing without testing, as long as you don't push, is fine, even > meritorious. It's the push that uploads those commits to the gentoo > reference repo, however, and testing should *definitely* be done before > pushing, with more commits /before/ the push to fix what the tests found > to be broken, should they be necessary. >
Of course. In fact, this is often the type of workflow you'd tend to employ in a CI setup. I believe that pull requests submitted on github get automatically tinderboxed, though I have no idea whether that provides any benefits to something like an eclass (if the CI script just tests the ebuilds being modified it obviously would not). Maybe in a perfect world we'd actually have a CI testing package category with dummy packages that do nothing but run tests to cover this sort of thing. Even so, I would imagine that in most organizations CI is intended more as a sanity check than a substitute for testing your own work. Certainly where I work the expectation is that somebody would have at least compiled and run something before putting it into some kind of QA workflow, even with CI. -- Rich
