I was about to reply with my concerns, but since Robert just offered a good set of comments, I'll integrate mine into his.
See below. Cliff On 2/5/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
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)
yes - the NOTICE file should include what is described here: http://apache.org/legal/src-headers.html#notice
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.
In the latter option, there still needs to be some pointer to all applicable licenses in the top-level LICENSE file. Right now, there's nothing in the LICENSE file except the Apache License, which might imply that those are the only terms of the software. For me, this is a major issue that must be fixed prior to release. In other words, a single, top-level LICENSE file must give all the information a user needs to know what the terms are of the Apache product -- whether that info is copied into the file or pointed to by reference. See the last two sentences in the this section: http://apache.org/dev/apply-license.html#new: "Otherwise, you should append their license(s) to the LICENSE file at the top of the distribution, or at least put a pointer in the LICENSE file to the third-party license. In all cases, be sure to obey the licensing constraints of the original author. If that is not possible, then do not redistribute their work." Note that the rest of this doc has been outdated, but this particular part is still required. I need to get this particular page cleaned up soon.
the older style header is used in some files. may need to run the conversion script on the source (IIRC it's in committers).
yep -- that would be good (and is required). Most committers are probably aware of this, but for those who are not, you can read more at http://apache.org/legal/src-headers.html.
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.
If this comes from MPL code, it's important to make sure all those requirements are met. This includes making sure that the entire source is included with the binary or pointed to in a note. It's also important to make sure whatever customizations were distinguished from the original code for copyright purposes and as is required by the license, and if/how they are differently licensed.
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.
Actually, I disagree with Robert on this, but I don't think it makes a difference to this release. The first location ever used for an incubation disclaimer was the README file, and that is what I still often see (although I'm not seeing where that is doc'd right now). I've also seen a DISCLAIMER file, which is fine. However, I do NOT think it should be in the NOTICE file. The NOTICE file has one specific purpose, which is to place copyright and attribution notices as required by third-party notices and for the ASF notice. See http://apache.org/legal/src-headers.html#notice. I think it's a bad idea to also throw in the incubation notice.
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.
This wasn't in my list of notes, but I generally agree with Robert's note on this.
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.
+1 and actually, I also generally agree with all of Robert's suggestions below. Cliff
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
