On Sat, Mar 9, 2019 at 4:22 PM Matthias Bläsing <mblaes...@doppel-helix.eu> wrote:
> Hi, > > Am Samstag, den 09.03.2019, 13:59 +0100 schrieb Jan Lahoda: > > Hi, > > > > On Sat, Mar 9, 2019 at 11:50 AM Matthias Bläsing < > mblaes...@doppel-helix.eu> > > wrote: > > [snip] > > > > > > > NETBEANS-1819 Incorrect License Headers in Test Sources > > > > > (https://issues.apache.org/jira/browse/NETBEANS-1819) > > > > > > > > > > > > > It was our decision to treat license related issues as blockers. If > > > > > > > Nothing against that - but what *exactly* is the license related issue > > here? I mean, the policy allows test data without the headers. And for > the > > IDE, some of the test data may resemble source code files. > > I read the policy as: for test files we tolerate missing license > headers, but it would be great if they are there. > > > possible we should see, that also the test sources contain correct > > > license headers. It would be great if the unittests for java.editor > > > could be fixed, then the addition of license headers to the data files > > > is a chore, but doable. > > > > > > > Well, is it really so simple? No doubts we should fix the tests for > > java.editor (and other modules!), but is that really the main problem > here? > > When all the tests (for java.editor, as requested here!) are fixed, what > is > > next? Add the license header to all .java files in > > java.editor/test/unit/data, run tests and adjust tests to pass? Ok, that > is > > a chore, but not that bad. But probably by far not enough: there are > tests > > that verify something does not happen (an error is *not* reported, list > of > > proposals is empty, etc.) These may vacuously pass when the license > header > > is added (i.e. the test may pass even if the problem is not fixed). So, > it > > may be necessary to check every single testcase to see if it still tests > > what it should test. This starts to sound scary. > > > > Moreover, is there a particular reason to believe this relates to the > > java.editor module only? If yes, then OK, we can invest some effort to > > resolve this for this particular module. But I don't see a reason to > > believe this applies to only this module. There are many more > Java-related > > modules in a similar situation. But, even worse, is there a reason to > > believe this applies only to Java modules? I see test data files without > > license headers in javascript2.editor, php.editor. Are these for some > > reason OK? Or is it that so far these were not brought up on the review, > > and when they are brought up in some future round of review, we will be > in > > the same positions as we are now with java.editor? > > > > Frankly, if I thought this can be resolved in few hours, I wouldn't push > > back. But I don't think that's the case - I think this can easily cost us > > thousands (or at least hundreds) of man-hours. And it is not clear to me > if > > we can afford that. > > > > I think this is a fair assessment of the situation. I admit, that I was > focused on one/two modules and the assumption, that working (not > failing) tests are enough prove for correct working tests. > > Having said this, adding that summary to the issue, it could be closed > as "Won't fix". At least I would be willing to defend that decision. > > It should be made clear though, that when working on tests it is > expected, that at least an effort is made to work with license headers. > My POV: Noone can claim that there are existing unittest without > license headers and do the same for new code. > Ok, I think we can handle that. (Unless we can guarantee the license header won't ever change - which we can't, I think, it means we need to be extra careful when using the datadirs, or better avoid using them, but that' we can handle that, I think.) Jan > Greetings > > Matthias > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >