I agree that the CSS file does not have an AL header, however it is only one line so it is at best doubtful that it needs one. There is little or no evidence of originality / creative expression in that one line.
The daemon css file on the other hand is longer than the AL header, so needs the header. +1 to the release On 11 November 2015 at 09:56, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > On 11/10/2015 11:41 PM, Gary Gregory wrote: >> On Tue, Nov 10, 2015 at 2:22 PM, Thomas Neidhart <thomas.neidh...@gmail.com> >> wrote: >> >>> On 11/10/2015 10:52 PM, Gary Gregory wrote: >>>> Hi all: >>>> >>>> -1 >>>> >>>> Sorry, the RAT failure needs to be handled one way or another: exclude >>> the >>>> files or add headers: >>>> >>>> Unapproved licenses: >>>> >>>> data/test/NullComparator.version2.obj1 >>>> data/test/NullComparator.version2.obj2 >>>> xdocs/style/project.css >>>> >>>> >>>> I imagine the obj files can be excluded but the CSS file can just have a >>>> header added, just like >>>> >>> https://svn.apache.org/repos/asf/commons/proper/daemon/trunk/src/docs/daemon.css >>>> >>>> It's just messy to rush this through without dotting the i's and so on. >>> >>> yeah, I did not see the 2 NullComparator files as the problem appears >>> only on Windows. The same happened for the Collections 4 release, and I >>> forgot about it. >>> >>> @css: wtf, are you serious to vote with -1 because of that and complain >>> about the RC being messy? I mean, I can handle it if there are real >>> issues to be fixed, and I had planned to cancel the VOTE anyways to make >>> some more adjustments but something like that is just ridiculous. Just >>> take a look at some other published commons releases and count the >>> number of RAT errors, even for source files. >>> >> >> Sorry, two wrongs to do make a right. If other Commons components have made >> a mess of specific releases in the past, then that's sad. Either the RAT >> report is clean or it is not. If it is clean, I have to assume that >> exclusions in the POM for specific files or types of files have been done >> with careful consideration and that I can always go digging in the commit >> log to see a hopefully useful comment as to why the exclusion was made. >> >> Since this is a release to address a security issue, I would have hoped >> that all details would have been handled with extra care. >> >> I'd never get away with a sloppy release at work, and I hope I won't have >> to here either. >> >> In any case, a -1 is not a veto on a vote thread like it is on a commit, so >> this vote may yet pass. It's up to you as the RM to decide what to do. >> >> I know that cutting releases is still a pain, we have a lot of gymnastics, >> it's not like pushing a button, but that' what we're stuck with for now. > > you complain about false positives in a code base that has not been > released in 8 years and call my work messy. I have seen the css alert, > but thought I can safely ignore it, as it is anyway obsolete (pointing > to a non-existing css on the apache homepage). > > People blame Apache for not providing a fix in 9 months for a known > exploit and we are arguing about totally unimportant issues. > > I explicitly asked for review in areas that *are* important, e.g. OSGI > compatibility, as the build/release chain has changed quite a lot in the > last 8 years, and I wanted verification that the 3.2.2 release can > really be used in all areas. But no, we talk about a missing AL header > in a one line css file. > > Frankly, I am pissed because I spent the last days working on this while > my baby is teething and would have certainly better things to do. > > I will continue with the release as it is too important, but I am not > sure any more that I want to make another release for commons in the future. > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
