Perfect. Gj
On Sun, Mar 10, 2019 at 5:22 AM Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote: > Thank you guys! > > Could be a solution to mark those files as some CRAFTED_TEST_DATA in > licenseinfo.xml? I know we do not have that category (yet), but that > would be a mark in the sources that we actually care. Anyway, I'm going > to waive that issue for 11.0 and cut a vc3. > > On 3/9/19 7:22 AM, Matthias Bläsing 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. > > > > 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 > > > > > > > > --------------------------------------------------------------------- > 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 > > > >
