On 2/2/07, Bob Buffone <[EMAIL PROTECTED]> wrote:
<snip>
I have posted a release candidate at: http://people.apache.org/~bbuffone/xap-release/
(this is the sort of review i do for proposals made to the incubator list) major issues --------------- the NOTICE.txt is missing. this needs to be the standard apache NOTICE (since the incubator disclaimer is in the README) minor issues --------------- the libraries (in /source/buildsystem/buildscripts/lib) should have their licenses detailed. this could be done by including all the licenses in the top level LICENSE or by creating a .LICENSE file for each library. the older style header is used in some files. may need to run the conversion script on the source (IIRC it's in committers). comments and notes ------------------------- the custom rhino jar seems ok(ish) from a legal pespective but apache dislike maintaining code with other licenses. i'm not sure about the policy in this situation. the incubation disclaimer is in the README.txt not as convention as in a NOTICE or DISCLAIMER but fine. the README reads well so that is a good home. the contents of the README are the release notes. this is less conventional than in a RELEASE_NOTES but that's fine. words good but a description of xap is missing. release notes for an open source project are a form of guerilla advertising. users will often skip the formal documentation but read short descriptions included in the release notes and on the download page. also good for indexing. full releases need to be signed (as well as summed). not a problem if your OpenPGP foo is strong but if you want me to check the signature and that your key's propagated to well known servers, you need to create a signature. suggestions (stuff to think about, my personal opinions) ------------------------------------------------------------------ linking to online document is ok from release documentation if you do this, it's best to ensure that versions of the document are preserved for each release and that this is linked to. this stops user frustration when they follow links to features which are not in the release the have. once xap is a full project, apache should always be included in the name of the release (for example apache-xap-ajax-framework-3.4.5). this gives us more traction when it comes to trademarks. the idea is that if someone else rolls an unofficial artifact, we can ask them kindly but firm to stop. the compressed archive unpacks directly into the root of a directory. a lot of users (including myself ;-) find this very annoying. it means that i have to look at the contents and then create a new directory. there are generally broad popular schools of thought. the first is that every type of distribution shipped should unpack into a different directory with a meaningful name. the second is that the should all unpack the same directory, each acting as an overlay and combining together harmoniously. first impressions matter. that's especially true with open source releases. when users download artifacts they usually haven't made a definitive choice to use it. i can usually gauge the level of expertise and maturity of a project just by looking at a release but normal users also pick up a surprising amount. by creating a directory not only do you get the chance to advertise the name of the project as you want but it also shows to the user that you have taken time and care over the software. an open source release should distribute source for a release. just a plain export of the repository. it's the right thing to do but there are number of pragmatic reasons. here a couple: a successful open source project (on the apache model) needs to attract developers as well as users. ship binaries (by which i mean anything which isn't just a simple export) to make things easy for users but also ship a source distribution for developers. many downstream repackages work from the source distribution. unless you ship a source distribution they will not pick up the project. - robert
