On Nov 11, 2015 1:56 AM, "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
The time is irrelevant IMO. If we cut a release, it should up to today's standard, again IMO. and call my work messy. Don't take it personally. Perhaps read "The four agreements". 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. If OSGi is important to you, then you can create a test that embeds the jar in a container. It's pain, sure, but it's doable. 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. Here we get to the bottom of it, yes, balacing work and family is a challenge for me as well. Gary > > 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 >
