Hi, Just catching up on this thread. Going back a bit.
>> #2 The #1 goal is achieved via mentorship. In fact mentorship is >> not even required as the case of Zest (and hopeful Yetus soon) demonstrated. Not to pick on Zest but a casual glance at the current source release shows it contains a couple of jars and the Apache LICENSE is incomplete. I know nothing about Zest and these are probably (easily fixed) minor issues, but it does show that having someone outside your project reviewing releases can be useful. If we as some people seem to be suggesting just announce podling releases on this list and not have an IPMC vote it seems to me we would be more likely to have releases with issues in them. Some of these would be minor and probably not matter but it does increase the risk. And if an issue is found what do we do about the previous releases? It seems( that checking often and early gives better results. Automated tools can certainly find some issues but they IMO are never going to find every issue. How can an automated tool easily know that cat image is under copyright? Or that the original license header has been replaced with an Apache one on a file? Tools like this do exists but are probably prohibitive cost wise and time wise to implement across Apache. I certainly think having clearer policy documentation would help and like Bertrands release checklist idea, but even having clear documentation (e.g. [1]) doesn’t seem to solve all issues. I can only assume that it comes down to we’re a bunch of volunteers and our time and focus is sometimes a little scattered so stuff sometimes gets missed. Thanks, Justin 1.http://www.apache.org/dev/licensing-howto.html --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
