I went through it over the weekend and only had one thought but haven't yet come up with the exact text that I think you should use....
In the MINA README file, you mention that the source can be obtained at mina.apache.org and give the rev #, which is nice. However, I was thinking that the typical user might not know what to do with that info from there. I was thinking it would be good to give a link to some info on where the actual MINA repository is and maybe the svn command to checkout the exact rev. I haven't tested this yet., but it might be: "You can get the corresponding source for the included snapshot of MINA though Subversion with the following command: svn checkout https://svn.apache.org/repos/asf/mina/trunk/ -r 463149 " Ideally, there might also be a link to some page we already have somewhere on how to get svn and how to set it up for reading asf repos, but that could probably wait until next release. So, that's the only thing I thought about when I did another review of RC3. It would be good to hear if the other two mentors have any issues. Unless one of them is unavailable for a while, we should really have +1s from all three mentors when we do the release vote on this list. Cliff On 11/27/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Cliff, any updates on the new RC3 ? Rajith On 11/27/06, Cliff Schmidt <[EMAIL PROTECTED] > wrote: > On 11/25/06, Marnie McCormack < [EMAIL PROTECTED]> wrote: > > Cliff, > > > > Just to check on the license issue for Apache products - when you say we > > must include a license, do you mean copy the apache license beside the jar ? > > > > (Just asking as I'd followed the pattern in other project's release dists > > and only seen one Apache license includes even if several products.) > > yeah...there's no one solid rule on this. However, to me it makes > sense that you would want to place a copy of the applicable license(s) > in each lib/ subdirectory along side the associated product, *whether > the product come from the ASF or not*. In fact, if it comes from the > ASF, it might have multiple licenses associated with it, just like > Qpid -- so they should all be there. While one could try to argue > that unless it says otherwise every directory is under the Apache > License; however, I think that gets tricky with ASF and non-ASF > included products, each with one or more licenses. > > Cliff > > > > On 11/24/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote: > > > > > > On 11/24/06, Rajith Attapattu < [EMAIL PROTECTED]> wrote: > > > > Hi Folks, > > > > > > > > Did anybody find any issues with the RC2 ? > > > > > > > > Folks please double check and let us know so that we can move towards > > > the > > > > final release ? > > > > > > > > Regards, > > > > > > > > Rajith > > > > > > > > > > > > On 11/22/06, Rajith Attapattu < [EMAIL PROTECTED]> wrote: > > > > > Hi Folks, > > > > > > > > > > The RC2 is available for download, please give it spin and let us > > > know. > > > > > http://people.apache.org/~rajith/qpid-release/RC2/ > > > > > > > > > > This includes > > > > > ----------------------------- > > > > > modified amqp license > > > > > roberts qpid script fix to allow arguments to be passed through to the > > > > qpid process > > > > > martins fixes to build scripts > > > > > > Here are the issues that I think MUST be fixed before a release: > > > > > > 1. We need to either include MINA source code or have note in the > > > directory or a rev# in the file name that gives user ability to get > > > source. At the moment, I don't think it's obvious (or even possible?) > > > for a user to get the source associated with the included binary, and > > > this is a big problem. Should be a simple fix but must be done. From > > > Leo's email: > > > > > > (4) failing that, custom builds of all dependencies > > > SHOULD be clearly identified as such and traceable > > > to their exact origin, eg > > > > > > qpid-1.1.4-incubating.zip > > > lib/ > > > mina-r2475690.qpid-1.1.4-incubating.jar > > > > > > You may have thought this wasn't necessary because you had a > > > "project-sanctioned snapshot" (from Leo's (3)), but the idea there was > > > that there was something that the project has released with associated > > > source to go with the binary. > > > > > > 2. Every third-party component (including the ones that happen to come > > > from another ASF project) must include a license. For instance, I'm > > > not seeing any license anywhere in the logging-log4j component (not > > > even buried in the .jar). > > > > > > Here are the issues that would be nice to fix in either this release > > > or the next: > > > > > > 1. I'm still seeing the duplicate LICENSE file in the /java dir of > > > qpid-java-1.0-incubator-M1-RC2-src.tar.gz that does not include the > > > same list of third-party licenses as the one at the root does. Not > > > sure why this duplicate LICENSE/NOTICE/README is even here. > > > > > > 2. It would be nice if the licenses mentioned in #2 of the MUST-fix > > > section above were in a top level directory of each component of lib/ > > > dir, rather than inside a .jar that doesn't need to be unzipped to be > > > used. We have no official policy on this at the moment, but I think > > > we should generally make it easy for someone to glance at a component > > > in /lib and easily see how it is licensed. > > > > > > 3. The top-level LICENSE file now meets the release requirements, but > > > it might be nice to name the license that is referenced in each line > > > at the bottom of the file (e.g . "MPL v1.1: > > > java/common/lib/saxon/license.saxon.txt" or > > > "java/common/lib/saxon/license.saxon.txt (MPL v1.1)" ) > > > > > > I will +1 a vote on a release that fixes the two MUST-fix issues; it's > > > up to you all whether you want to make it a little nicer by adding any > > > of the 1-3 nice-to-have items above. > > > > > > Cliff > > > > > > > >
