On 4/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Hi Robert, Thanks for taking the time to look at our precious :). Answers inline.
On 4/7/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On 3/30/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
<snip>
> minor issues > --------------- > src/release.sh looks to me like it's creative enough to need a header I think it is more of a description on how to get somewhere without any creativity. Just like you can't copyright the route going from your house to the shopping mall (turn left, 100m turn right, etc.).
some routes may have creative content. in particular, those involving an element of non-algorithmic selection. example: the best route for a shopper round a mall.
That said, I'll add the header.
i agree it's a marginal case. i wouldn't -1 a release for something like this so long as people involved understood the issues. my personal line in the sand is whether something is arguably creative. if a reasonable case could be made then i'd like to see a license header. this approach saves questions from lawyers later.
> IMHO many of the examples in src/main/java/wicket/examples are > creative enough to deserve a license header. it's reasonably common > for people to derive works from examples so licensing is important. All Java files do have the license header, just not the markup files. The markup files are also used in the unit tests.
ok
> comments > ------------ > in general the MANIFEST.MF could be improved: missing the attributes > recommended by sun. not particularly important (adhering to the > standard doesn't really do any tangible good) but looks professional > and easy to do with maven. Will look into that, but we already provide all necessary stuff in the pom's, so I'm a bit unsure what extra needs to be done for maven to put it there.
http://maven.apache.org/guides/mini/guide-manifest.html http://jakarta.apache.org/commons/releases/prepare.html contains a discussion of manifests MANIFESTs are a little controversial (there are multiple specs which are open to interpretation). i'm of the maximal school of thought: putting everything in which people think are required stops sniping.
> i'd recommend creating release notes (but i hope that these are > missing since this is only an audit release). Normally we have those as well, containing links to our documentation etc. Are the release notes part of what is voted on?
the vote is about the complete and final artifacts for distribution. if these the release notes are part of the final artifact then they are voted on as part of that process. i recommend shipping release notes as part of the release artifact. not all downstream users will download wicket from the apache site so it's a chance to reach them with the same content. apache releases have long lifespans. all releases are archived permanently. it's good to use the release notes content as a basis for a permanent summary record of the release on the website (remember to includes the release date). this is useful for users and search engines indexes this content well. it's also good to post up the documentation for each release on the website.
> BTW i see the current namespace is http://wicket.sourceforge.net/. do > you plan to change this upon (sometime)? Yep, however, we think we should only change this after graduation as we are still not officially an Apache project :).
fine
Thanks for looking into this and providing us with some solid feedback. I expect to have a new release available somewhere next week with all problems solved and questions answered.
great - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
