On Tue, Aug 21, 2012 at 11:01 AM, Marvin Humphrey <mar...@rectangular.com> wrote: > On Tue, Aug 21, 2012 at 4:59 AM, Branko Čibej <br...@apache.org> wrote: > >> It is fair to require changes for the next release. It's not fair to use >> different criteria for two successive, essentially identical releases. > > When the option to be "fair" exists, "fair" is great! > > With regards to my own vote, I'm going to try to apply Jukka's criteria on > "rights": > > http://markmail.org/message/jtj27kdlhvgocexg > > Personally I'm fine with things like missing license headers or partially > incomplete license metadata (which sounds like is the case here), as long > as those are just omissions that don't fundamentally affect our rights (or > those of downstream users) to distribute the releases and as long as > there's a commitment to fix such issues in time for the next release. > > Extraneous information in the NOTICE file imposes a burden on some downstream > distributors and consumers. Thee is almost certainly room for improvement in > the AOO NOTICE file, and we have made some progress towards a consensus on > exactly what ought to be in NOTICE since the first incubating release of AOO > -- though there is also considerable room for improvement in the ASF > documentation with regards to NOTICE. :) > > However, is there anything about the NOTICE file in this AOO release candidate > which affects _rights_, either our own or those of downstream users? I've > looked through the file, and if that's the case, I don't see it. If sebb > thinks a respin is merited, that's his call, and his review is a welcome > contribution. However, considering how much effort it takes to spin up an AOO > release, the good faith and substantial effort invested by the podling in > assembling the NOTICE file in the first place, and the good record of the AOO > podling in incorporating suggestions, my opinion is that a promise to > incorporate any NOTICE revisions into trunk suffices and that a new RC is not > required. > > In contrast, I am more concerned about extra files that were apparently > inadvertently committed and were not caught by either the primary mechanism of > PPMC members watching the commits list or by the last line of defense of > running a RAT report prior to rolling the release. If files which are
I did check on these JAR files, to see how they got into Subversion in the first place. They were checked in as part of the legacy project and brought over when we did the original svndump import of the project last June. So it would not have been found looking at commit logs. But you are right that this should have been found during the IP review and preparation of the AOO 3.4.0 release. I think the main error was in believing that since this was a minor maintenance release, with only a handful of carefully reviewed patches, and that since AOO 3.4.0 was thoroughly reviewed and approved, that we could concentrate our effort on reviewing the delta between the two releases. Of course, if we do this we'll never find pre-existing errors, and it is clear now that they can exist as well. What's the old saying? "Every new class of users finds a new class of bugs". Regards, -Rob > incompatible with our licensing end up in a distribution, that has the > potential to affect _rights_. And what with AOO's history, there is a big > target painted on the project and there is a conspicuous need to maintain > absolute control over what ends up in releases. > > It looks like the late audit has revealed that those files are OK, but it > feels like we might have dodged a bullet. > > Marvin Humphrey > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
