Josh Awesome.
Honestly I believe we're good on the LICENSE, NOTICE, DISCLAIMER, README. All dependencies have been reviewed and checked for ASLv2 compatibility. Will submit the infra ticket now for the dist/ path for keys files and such. My guess is that the release artifact should be a tarball of all source. Could we literally just package up a clean source tree? Anyone else have views on this? Ideally with this release we'd do it all properly including maven artifacts, sources/javadocs, and so on. The Maven build does already operate now off a single command at the root to build everything (build-order is gone) and inherits from the apache parent. Will need to incorporate RAT. Thanks for all that - definitely gives some stuff to work on and look into. Thanks Joe On Wed, Jan 7, 2015 at 10:10 PM, Josh Elser <[email protected]> wrote: > Regardless of what you call it, writing down exactly what was done to make > a RC is extremely important early on (I know that I sure can't remember > what I did last week, much less last release). I'm not sure if release > guide is formally defined somewhere, but enough information that any other > committer can come by after "you get hit by a train" and make a release is > extremely important. Using the CMS and making a page on the website for > this is extremely easy to do, IMO. > > Another concern for how to actually make a release is the type of > packaging that is released. I not talking about the source/binary release > here, literally "what is Apache NiFi 0.0.1-incubating"? Is it a tarball? > Are there jars in Maven? etc. A tarball is pretty easy to make, and likely > the closest to what the build-order.sh script already does (with Maven's > help). I'm not sure if maven-released artifacts are quite as important at > this point -- if it's not, punting on that will help. If/when you get to > that point, look into the apache parent pom[1]. It is extremely well > automated to use the existing infrastructure to do it all for you. > > Without looking at official documentation (which is me being lazy, sorry), > some other things that will need to be thought about: > > Start with the releases page [2] > > * You *must* include a source artifact. It cannot have binaries. No Java > class files, no jars. A user must be able to download the source artifact > and build it all themselves. Artifacts which include binaries are for > user-convenience only and can optionally be provided as well. > > * LICENSE, NOTICE and README must all be included in the top level of the > artifact. The NOTICE is the most painful and must include any required > third-party notices. [3] > > * You will need to audit your dependencies to make sure that they are > ASLv2 compatible [4] > > * Releases must be cryptographically signed (PGP) [5]. Your public key > should be published to known sites (e.g. pgp.mit.edu) and must be listed > in NiFi's KEYS file [6] (which does not yet exist, probably needs an infra > ticket to create your dist/ directory?). > > * Verify that every source file contain the proper ASL header. The > release-audit-tool[7] (`mvn apache-rat:check`) is a wonderful tool that can > (and should, IMO) be integrated into your build process to prevent people > from accidentally committing new files between releases that do not have > the correct header. > > And suddenly, this is really long :). Short answer: decide what the > release should look like (just a tarball?), start vetting your source code > for license headers, and looking into NiFi's dependencies and their > licenses. > > [1] http://maven.apache.org/pom/asf/ > [2] http://www.apache.org/dev/release.html > [3] http://www.apache.org/legal/src-headers.html > [4] http://www.apache.org/legal/resolved.html#category-x > [5] http://www.apache.org/dev/release-signing.html > [6] http://www.apache.org/dist/incubator/nifi/KEYS > [7] http://creadur.apache.org/rat/ > > > Tony Kurc wrote: > >> I read the guide Joe linked and a lot of the sticky parts are marked >> "TODO" >> and it looks like a work in progress >> >> "Podlings can short circuit this process by starting out with written >> release documentation. It is strongly recommended that Podlings invest >> time >> looking at the best practices recommended in this document. By selection >> and modification, sections of this document can be used to quickly and >> easily bootstrap a release guide. " >> >> Is step one putting together a release guide? >> >> >> >> On Wed, Jan 7, 2015 at 9:26 PM, Joe Witt<[email protected]> wrote: >> >> Hello >>> >>> Just wanted to stir this one up a bit. Looks like all tickets pegged as >>> 0.0.1 are resolved (2 remain as of now but seem likely to be resolved >>> shortly based on their comments). So working through the release steps >>> available on apache.org and via the link Brock sent. >>> >>> Anyone interested in this part of the process or who has advice to help >>> us >>> avoid landmines we're happy to hear it. >>> >>> Thanks >>> Joe >>> >>> On Thu, Dec 18, 2014 at 1:31 PM, Joe Witt<[email protected]> wrote: >>> >>> Thanks Brock this is very helpful. >>>> >>>> On Thu, Dec 18, 2014 at 1:27 PM, Brock Noland<[email protected]> >>>> >>> wrote: >>> >>>> Hi, >>>>> >>>>> This is a decent guide which can be copied: >>>>> >>>>> http://mrunit.apache.org/pmc/how_to_release.html >>>>> >>>>> Brock >>>>> >>>>> On Thu, Dec 18, 2014 at 10:17 AM, Joe Witt<[email protected]> wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> Looking at the tickets that remain which are presently tied to 0.0.1 >>>>>> >>>>> we're >>>>> >>>>>> probably 1-2 weeks out from this initial release. Can you provide >>>>>> >>>>> some >>> >>>> pointers/references or pointers on how to get this ball rolling and >>>>>> >>>>> any >>> >>>> rocks we must move before going down this path? >>>>>> >>>>>> http://incubator.apache.org/guides/releasemanagement.html >>>>>> >>>>>> That link seems really helpful but has a lot of TODOs for areas which >>>>>> >>>>> need >>>>> >>>>>> more explanation. >>>>>> >>>>>> >>>>>> Thanks >>>>>> Joe >>>>>> >>>>>> >>
