I think the Test module should be reserved for changes to the actual testing infrastructure. If you were filing a bug for this, you'd file it under Support.
That's because we don't have "tests" component at the tracker, when i saw these two last commits, one under "Tests" and one under "Support" made me think the one of them actually changed the source and changing the source is usually a big deal, so for me, it would be more useful to instantaneously know if we changed the source or not by just looking at the commit head.
Yeah, I mixed it up a little. First, there is the Support component but not the Test one which made me mark this commit as such but then I agree with @markelog having Tests at the beginning of a commit message is helpful as it shows if the change was made purely to tests - such changes can be introduce at any time, even between RC & stable as they're safe contrary to changes in src/. It adds value to be able to quickly judge if a particular set of commits is safe in this way just by looking at beginnings of commit messages; in this way @dmethvin could quickly see if we didn't break his request to not land any code changes before the release.
Well, i wouldn't call them "safe", since in the perfect world we should release only if we all green, if we would broke the test, it would put a hold on the release, or we could fix the test and it would actually show the error, see this for reference.
I'm inclined to agree with @scottgonzalez, strangely enough. "Support" adds specificity about which module is being tested, whereas "Tests" is a generic component related to test efficiency and stability. Dave can trust you not to make source changes.
OK, maybe you're right. As for being careful, that's exactly why I landed this commit which only adds support matrices for 2 browsers and I wouldn't land #1496 by myself without consulting even if the workaround was less crappy.
Not everyone could be aware, if, at some point, Commiter and Dave would agree to make some change before the release. I'm saying if i would see "Tests" component, i wouldn't be much in the hurry to look at it, but if i would see name of some the module, i would really want to check it out right away.
@markelog I understand, but the usefulness of "Support" as the affected component outweighs the occasional usefulness of skimming commit messages before a release.
This comment has been minimized.
markelog repliedJan 23, 2014
You changed only tests here, so i guess "Tests" component would be more appropriate.
This comment has been minimized.
scottgonzalez repliedJan 23, 2014
I think the Test module should be reserved for changes to the actual testing infrastructure. If you were filing a bug for this, you'd file it under Support.
This comment has been minimized.
markelog repliedJan 23, 2014
That's because we don't have "tests" component at the tracker, when i saw these two last commits, one under "Tests" and one under "Support" made me think the one of them actually changed the source and changing the source is usually a big deal, so for me, it would be more useful to instantaneously know if we changed the source or not by just looking at the commit head.
This comment has been minimized.
mgol repliedJan 23, 2014
Yeah, I mixed it up a little. First, there is the
Supportcomponent but not theTestone which made me mark this commit as such but then I agree with @markelog havingTestsat the beginning of a commit message is helpful as it shows if the change was made purely to tests - such changes can be introduce at any time, even between RC & stable as they're safe contrary to changes insrc/. It adds value to be able to quickly judge if a particular set of commits is safe in this way just by looking at beginnings of commit messages; in this way @dmethvin could quickly see if we didn't break his request to not land any code changes before the release.@timmywil @dmethvin What do you think?
This comment has been minimized.
markelog repliedJan 23, 2014
Well, i wouldn't call them "safe", since in the perfect world we should release only if we all green, if we would broke the test, it would put a hold on the release, or we could fix the test and it would actually show the error, see this for reference.
This comment has been minimized.
timmywil repliedJan 23, 2014
I'm inclined to agree with @scottgonzalez, strangely enough. "Support" adds specificity about which module is being tested, whereas "Tests" is a generic component related to test efficiency and stability. Dave can trust you not to make source changes.
This comment has been minimized.
timmywil repliedJan 23, 2014
That said, @markelog has a point. We should still be especially careful about test changes right before a release.
This comment has been minimized.
timmywil repliedJan 23, 2014
In this particular case, landing it was the right call. Here you are adding better test coverage, which is good to verify before a release.
This comment has been minimized.
mgol repliedJan 23, 2014
OK, maybe you're right. As for being careful, that's exactly why I landed this commit which only adds support matrices for 2 browsers and I wouldn't land #1496 by myself without consulting even if the workaround was less crappy.
This comment has been minimized.
markelog repliedJan 23, 2014
Not everyone could be aware, if, at some point, Commiter and Dave would agree to make some change before the release. I'm saying if i would see "Tests" component, i wouldn't be much in the hurry to look at it, but if i would see name of some the module, i would really want to check it out right away.
This comment has been minimized.
timmywil repliedJan 23, 2014
@markelog I understand, but the usefulness of "Support" as the affected component outweighs the occasional usefulness of skimming commit messages before a release.