Hi, Thanks for looking into the release!
> -1 (binding) based on the RAT check: my cursory run of RAT > (http://creadur.apache.org/rat/apache-rat/index.html) uncovered > 61 Unknown Licenses. > > Here's what I would like to suggest for cutting the new RC: > 1. make it easy to run the RAT check by integrating this somehow > into your build system and/or provide a script that does that > Is RAT a requirement, and do all other projects use it? The release guideline on [1] doesn't mention RAT at all.... > 2. review all of the files that trigger RAT. If you need to exclude some > of the files because of the format that doesn't allow comments > make sure that the exclusion file is checked into your repo and has > comments explaining the decisions for exclusion. I'll take a look into RAT and look at the files missing the info. > > And here's a couple more nits that make it easier to review: > 3. when creating an RC make it clear that this is an RC by putting > the artifacts available under the URL that looks something like this: > > https://dist.apache.org/repos/dist/dev/incubator/celix/celix-0.0.1-incubating-RCX > the file themselves should have the final names (without the RC > suffix). > That way a promotion of the RC to the release is a simple matter of > renaming the top level subdir. > Renaming a top level dir means a new release to me. We specifically decided to not do a RC. For us it is a release, as the release thread on the Celix list also points out, we all support this. I am all in favor of discussing these items on the Celix list (or maybe een here if more guides/rules are needed). At this moment I don't see this as a blocking issue for the release. > > 4. when sending an email please include the following information: > * a link to the JIRA with release notes (e.g. > http://s.apache.org/pY) > * the tag in the SCM that is being voted on > * url with PGP keys > The TAG and link to keys were forgotten, but send later in the same thread. As for a link to a JIRA release notes, we don't use JIRA actively yet. For the future I would prefer to do so. > > And finally, if you don't have a How To Release document for you project > it may be a good idea to create one. Here's a nice example of what it > should look like: > https://cwiki.apache.org/WHIRR/how-to-release.html Good point the (nearby) future. I'll look into this later on. Overall, as a new committer and the release manager of Celix, I find it really difficult to make a release that suits all personal opinions of the IPMC. The release guideline feels/is incomplete (eg RAT is missing). How am I suposed to make a release which is correct the first time? Don't get me wrong, I do really appreciate all the feedback... [1]: http://incubator.apache.org/guides/releasemanagement.html -- Met vriendelijke groet, Alexander Broekhuis
