Daniel Campbell posted on Sun, 15 May 2016 04:16:30 -0700 as excerpted: > On 05/15/2016 03:29 AM, Michał Górny wrote:
>> However, is it that much of >> an effort to test eclass changes using ebuilds *before* committing it? >> It wasn't that hard even in times of CVS (esp. that we're talking about >> separate directories), and it is even easier in times of git. >> > One can't coddle someone who's breaking the tree, especially > when we expect people to test before committing. Orthogonal to the general discussion, but could be critical for some... Both the above comments reflect legacy CVS thought patterns in regard to commits. In git, commit != push , and here it's the push, not the commit, that's critical and that testing needs done before. 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. (Tho in keeping with the principle of ultimately atomic commits that don't break bisections, if a commit is found to be broken and is then fixed by another commit, a rebase to combine the two into one should be considered, thus avoiding breakage of bisections ending up with a commit between the break and its fix. Not that bisection is particularly practical in the gentoo repo context anyway, but that's a separate discussion, and good habits here will carry over to repos where bisection is actually practical and critically important.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
