Yeah, I'm there. I misunderstood the original statement. Thanks for the clarification.
Adam On Wed, Jan 14, 2015 at 5:37 PM, Benson Margulies <[email protected]> wrote: > I made the necessary tweaks to the pom so that the plugin is an > independent artifact that happens to co-reside in the git repo with > the rest of NiFi. I'm not sure that that moving it to another git repo > would make much of a difference; it would delete one line of XML from > the pom. > > On Wed, Jan 14, 2015 at 5:32 PM, Adam Taft <[email protected]> wrote: > > Does it make sense to consider the maven plugin as a separate artifact, > > potentially with its own git repository? I think this was discussed > > already? It would be ideal to get the plugin released and out there, > this > > would likely ease building the rest of the project. > > > > Adam > > > > > > On Wed, Jan 14, 2015 at 3:40 PM, Joe Witt <[email protected]> wrote: > > > >> Team, > >> > >> Looks like the procedural hurdles and remaining infrastructure steps > have > >> been addressed. So we can proceed with the release process. Benson has > >> offered to RM the nar maven plugin release so we can produce a good set > of > >> steps/guide to follow. Then we can do the same for the remainder of the > >> application. Will try to do a very good job on this process > documentation > >> so that others are aware of the steps and processes applicable to > release > >> of nifi. > >> > >> Thanks > >> Joe > >> > >> On Fri, Jan 9, 2015 at 10:40 AM, Mark Payne <[email protected]> > wrote: > >> > >> > I'm going to agree with this sentiment as well. > >> > > >> > Thanks > >> > - Mark > >> > > >> > Sent from my iPhone > >> > > >> > > On Jan 9, 2015, at 10:28 AM, Joey Echeverria <[email protected]> > >> wrote: > >> > > > >> > > +1 to deploying NARs to Maven. If it becomes a problem in the > future, > >> > > we could revisit but keeping the maven configuration as simple as > >> > > possible is a huge plus. > >> > > > >> > > -Joey > >> > > > >> > >> On Thu, Jan 8, 2015 at 8:07 PM, Joe Witt <[email protected]> > wrote: > >> > >> I agree we need to be mindful of this. That said I am not actually > >> sure > >> > >> there is a problem. > >> > >> > >> > >> To provide some specific data to consider here are the Nars and > their > >> > sizes > >> > >> today (smallest to largest): > >> > >> > >> > >> 29K > >> > >> > >> > > >> > ./standard-services/standard-services-api-nar/target/standard-services-api-nar-0.0.1-SNAPSHOT.nar > >> > >> 158K > >> > >> > >> > > >> > ./volatile-provenance-repository-bundle/nar/target/volatile-provenance-repository-nar-0.0.1-SNAPSHOT.nar > >> > >> 537K > >> > >> > >> > > >> > ./standard-services/ssl-context-bundle/nar/target/ssl-context-service-nar-0.0.1-SNAPSHOT.nar > >> > >> 628K > >> > >> > >> > > >> > ./standard-services/distributed-cache-services-bundle/distributed-cache-services-nar/target/distributed-cache-services-nar-0.0.1-SNAPSHOT.nar > >> > >> 1.1M ./hadoop-bundle/nar/target/hadoop-nar-0.0.1-SNAPSHOT.nar > >> > >> 4.3M > >> > >> > >> > > >> > ./monitor-threshold-bundle/nar/target/monitor-threshold-nar-0.0.1-SNAPSHOT.nar > >> > >> 4.4M > >> > >> > >> > > >> > ./update-attribute-bundle/nar/target/update-attribute-nar-0.0.1-SNAPSHOT.nar > >> > >> 4.5M ./jetty-bundle/target/nifi-jetty-bundle-0.0.1-SNAPSHOT.nar > >> > >> 4.6M > >> > >> > >> > > >> > ./persistent-provenance-repository-bundle/nar/target/persistent-provenance-repository-nar-0.0.1-SNAPSHOT.nar > >> > >> 12M ./kafka-bundle/kafka-nar/target/kafka-nar-0.0.1-SNAPSHOT.nar > >> > >> 12M > ./standard-bundle/nar/target/nifi-standard-nar-0.0.1-SNAPSHOT.nar > >> > >> 26M > >> > >> > >> > > >> > ./hadoop-libraries-bundle/nar/target/hadoop-libraries-nar-0.0.1-SNAPSHOT.nar > >> > >> 28M > >> ./framework-bundle/nar/target/nifi-framework-nar-0.0.1-SNAPSHOT.nar > >> > >> > >> > >> Having the nars in a proper central repository would definitely > make > >> > easier > >> > >> for people to build their own assemblies of NiFi. We definitely > want > >> > all > >> > >> the Jar artifacts there. > >> > >> > >> > >> I am not convinced the added complexity (of modifying the build to > >> > >> distinguish) is necessary. > >> > >> > >> > >> A quick look through Maven central for things like Wars (which is a > >> very > >> > >> analogous concept to Nars) suggests what we'd be doing is not at > all > >> > >> uncommon and the sizes are reasonable as well. > >> > >> > >> > >> I am of the view that we go as plain/keep it simple as we can here > and > >> > if > >> > >> it becomes an identifiable problem then we address it. > >> > >> > >> > >> Thanks > >> > >> Joe > >> > >> > >> > >> On Thu, Jan 8, 2015 at 8:19 PM, Benson Margulies < > >> [email protected] > >> > > > >> > >> wrote: > >> > >> > >> > >>> To expand, > >> > >>> > >> > >>> On the one hand, people dump an amazing variety of crud onto > Central. > >> > >>> There's no special reason for NiFi to have more of a conscience > than > >> > anyone > >> > >>> else. > >> > >>> > >> > >>> On the other hand, if you want to use Maven to build things but > not > >> > have > >> > >>> them push to central, you control: > >> > >>> > >> > >>> the install plugin > >> > >>> the deploy plugin > >> > >>> > >> > >>> and the 'attach' parameters of some other plugins, like the war > >> plugin > >> > and > >> > >>> the assembly plugin. Roughly, if you want to avoid treating the > >> primary > >> > >>> artifact of a project as a maven artifact, you have to mess with > >> > install > >> > >>> and deploy. > >> > >>> > >> > >>> It would be good to sort this out before tackling any other > release > >> > issues. > >> > >>> > >> > >>> > >> > >>> > >> > >>> On Thu, Jan 8, 2015 at 6:32 PM, Benson Margulies < > >> > [email protected]> > >> > >>> wrote: > >> > >>> > >> > >>>> If you don't want to release it you need to not deploy it. That > is a > >> > pom > >> > >>>> change unrelated to the staging repo. > >> > >>>>> On Jan 8, 2015 5:37 PM, "Adam Taft" <[email protected]> wrote: > >> > >>>>> > >> > >>>>> Benson, > >> > >>>>> > >> > >>>>> Quite a bit of NIFI's artifacts are more like application > bundles > >> of > >> > >>> other > >> > >>>>> common libraries. Most of the NIFI nars aren't really useful > for > >> > >>>>> application developers to bind to in their own code. These nars > >> are > >> > >>> more > >> > >>>>> part of the application and less useful as a shared common > library. > >> > >>>>> > >> > >>>>> One of my concerns was accidentally releasing unneeded nars into > >> > maven > >> > >>>>> central. It sounds like the "purgatory" area solves this? Can > you > >> > >>> speak > >> > >>>>> to this a little more? > >> > >>>>> > >> > >>>>> There's been discussion on whether we care that application nars > >> > escape > >> > >>>>> into maven central - I'm not trying to weigh in on that topic > >> > (though, I > >> > >>>>> think you can read my thoughts between the lines). I'm just > asking > >> > for > >> > >>>>> more clarity on the options when using the maven release plugin. > >> > >>>>> Purgatory > >> > >>>>> might very well allow us to have our cake and eat it too. > >> > >>>>> > >> > >>>>> Thanks, > >> > >>>>> > >> > >>>>> Adam > >> > >>>>> > >> > >>>>> > >> > >>>>> On Thu, Jan 8, 2015 at 5:07 PM, Benson Margulies < > >> > [email protected] > >> > >>>> > >> > >>>>> wrote: > >> > >>>>> > >> > >>>>>>> On Thu, Jan 8, 2015 at 4:53 PM, Joe Witt <[email protected]> > >> > wrote: > >> > >>>>>>> > >> > >>>>>>> Benson, > >> > >>>>>>> > >> > >>>>>>> Well I think we have all the groundwork laid as far as I know > for > >> > >>> the > >> > >>>>>>> release plugin. To be honest though (speaking for myself at > >> least) > >> > >>>>> I'm > >> > >>>>>> not > >> > >>>>>>> sure what the steps would be that the release plugin would do. > >> I'd > >> > >>>>> love > >> > >>>>>> it > >> > >>>>>>> to be as you describe but am also concerned about how much > we'd > >> be > >> > >>>>>> bugging > >> > >>>>>>> you to figure that out. I looked at what other projects seem > to > >> do > >> > >>>>> and > >> > >>>>>> it > >> > >>>>>>> seemed shockingly manual. > >> > >>>>>>> > >> > >>>>>>> If you don't mind laying out the steps in more detail when you > >> have > >> > >>>>> time > >> > >>>>>>> would love to learn from you on it. I can also try toying > around > >> > >>> with > >> > >>>>>> it a > >> > >>>>>>> bit more off-line. > >> > >>>>>>> > >> > >>>>>> > >> > >>>>>> I don't know what projects you're looking at, but it shouldn't > >> look > >> > so > >> > >>>>>> manual for any project that has a Maven top-level build. > >> > >>>>>> > >> > >>>>>> Here's the basic workflow of the maven-release-plugin: > >> > >>>>>> > >> > >>>>>> release:prepare: > >> > >>>>>> > >> > >>>>>> 1. edit poms to contain 'release version'. > >> > >>>>>> 2. make a commit. > >> > >>>>>> 3. make a tag. > >> > >>>>>> 4. edit poms to contain 'next snapshot' > >> > >>>>>> 5. make a commit. > >> > >>>>>> 6. push the whole business (unless you turn that off). > >> > >>>>>> > >> > >>>>>> release:perform: > >> > >>>>>> > >> > >>>>>> 7. check out from tag in target/checkout (using extra git > clone) > >> > >>>>>> 8. build > >> > >>>>>> 9. deploy results to target of deploymentManagement > >> > >>>>>> > >> > >>>>>> Now comes the next trick. > >> > >>>>>> > >> > >>>>>> Apache runs a copy of Sonatype Nexus, that serves as a 'staging > >> > >>>>>> repository'. So, when step 9 pushes things to the repository, > >> it's > >> > >>>>> pushing > >> > >>>>>> them to a special 'purgatory' staging area. That area is > available > >> > for > >> > >>>>>> people to look at for testing, but does not propagate along to > >> Maven > >> > >>>>>> central. > >> > >>>>>> > >> > >>>>>> Given all this, then we add one ingredient: an additional maven > >> > module > >> > >>>>> that > >> > >>>>>> uses the maven-assembly-plugin to build a tarball that > satisfies > >> the > >> > >>>>>> requirements of an Apache source release. This is not the same > >> thing > >> > >>> as > >> > >>>>>> what the maven-source-plugin does at all. Since it will have > >> > >>>>>> <attach>true</attach>, the resulting tarball swims upstream to > the > >> > >>>>> staging > >> > >>>>>> repo with everything else. > >> > >>>>>> > >> > >>>>>> The vote email points people to that location, and supplies a > sha1 > >> > for > >> > >>>>> the > >> > >>>>>> source ball. Voters download the source release from the > staging > >> > repo, > >> > >>>>> do > >> > >>>>>> what they need to do, and vote. Three +1's later, and then you > get > >> > to > >> > >>>>>> publish. > >> > >>>>>> > >> > >>>>>> Does this help? The only manual steps are really copying to > svn to > >> > >>> push > >> > >>>>> to > >> > >>>>>> the Apache dist area. CXF and all the Maven plugins are > examples. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>> > >> > >>>>>>> Thanks > >> > >>>>>>> Joe > >> > >>>>>>> > >> > >>>>>>> On Thu, Jan 8, 2015 at 4:49 PM, Benson Margulies < > >> > >>>>> [email protected]> > >> > >>>>>>> wrote: > >> > >>>>>>> > >> > >>>>>>>> On Thu, Jan 8, 2015 at 4:41 PM, Joe Witt <[email protected] > > > >> > >>>>> wrote: > >> > >>>>>>>> > >> > >>>>>>>>> Benson, > >> > >>>>>>>>> > >> > >>>>>>>>> Yes that would be much appreciated. > >> > >>>>>>>>> > >> > >>>>>>>>> Here is a rough gamplan of what I *think* will be needed to > do > >> > >>> the > >> > >>>>>>>> release: > >> > >>>>>>>>> > >> > >>>>>>>>> - Branch from develop against a ticket for the overall > release > >> > >>>>>> process > >> > >>>>>>>>> - Update the version of all the artifacts and dependencies > to > >> > >>>>>>>>> 0.0.1-RC1-incubating or something like that > >> > >>>>>>>>> - Create the tar.gz of the clean source tree. Sign that and > >> > >>> place > >> > >>>>>> both > >> > >>>>>>>> the > >> > >>>>>>>>> signed file and the tar.gz into my people's dir (if i have > one > >> > >>> of > >> > >>>>>>> those) > >> > >>>>>>>>> - Notify folks that this is available so they can pull it > and > >> > >>>>> attempt > >> > >>>>>>> to > >> > >>>>>>>>> build from that and validate the signature > >> > >>>>>>>>> - Once folks agree it is good to merge that to master > >> > >>>>>>>>> - Create a tar.gz of that and a signed file. Call a vote > >> within > >> > >>>>> the > >> > >>>>>>>> team. > >> > >>>>>>>>> If that is good call a vote within IPMC. > >> > >>>>>>>>> - IF NO - fix whatever is wrong. > >> > >>>>>>>>> - If all good then do a maven deploy of the binary > artifacts, > >> > >>>>> source > >> > >>>>>>>>> bundles, and javadocs > >> > >>>>>>>>> - Upload the tar.gz of source and the signed file to our > dist > >> > >>> dir. > >> > >>>>>> And > >> > >>>>>>>>> upload convenience binary build tar.gz and zip with sigs to > our > >> > >>>>> dist > >> > >>>>>>>>> folder. Then create links to these from our downloads page. > >> > >>>>>>>>> - Update JIRA that the release is closed. > >> > >>>>>>>>> - Wash/Rinse/Repeat > >> > >>>>>>>>> > >> > >>>>>>>>> <note this all is with the understanding that we've done all > >> the > >> > >>>>>>>> necessary > >> > >>>>>>>>> review of dependencies, licenses, properly documented them, > >> have > >> > >>>>> our > >> > >>>>>>>>> ECCN/encryption stuff properly filed> > >> > >>>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> Sure, except that I think we can make the > maven-release-plugin > >> do > >> > >>> a > >> > >>>>> lot > >> > >>>>>>> of > >> > >>>>>>>> the work. > >> > >>>>>>>> > >> > >>>>>>>> The idea is that you run the release plugin, and it delivers > all > >> > >>>>> these > >> > >>>>>>>> goodies to repository.apache.org. Then you call the vote. If > >> the > >> > >>>>> vote > >> > >>>>>>>> passes, you (a) push the promote button to push to Maven > >> Central, > >> > >>>>> and > >> > >>>>>> (b) > >> > >>>>>>>> check the official source release tarball into the svn area > for > >> > >>>>>>>> distribution. > >> > >>>>>>>> > >> > >>>>>>>> I will take a whack at a PR for point (a). > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> Might be missing a detail or two but does that sound > roughly on > >> > >>>>> the > >> > >>>>>>> right > >> > >>>>>>>>> rack? > >> > >>>>>>>>> > >> > >>>>>>>>> I had though the maven release plugin would be useful but > looks > >> > >>>>> like > >> > >>>>>>>> we'll > >> > >>>>>>>>> just be able to use the versions plugin to update them and > can > >> > >>> do > >> > >>>>> the > >> > >>>>>>>> other > >> > >>>>>>>>> simple steps manually. > >> > >>>>>>>>> > >> > >>>>>>>>> Thanks > >> > >>>>>>>>> Joe > >> > >>>>>>>>> > >> > >>>>>>>>> On Thu, Jan 8, 2015 at 3:46 PM, Benson Margulies < > >> > >>>>>>> [email protected]> > >> > >>>>>>>>> wrote: > >> > >>>>>>>>> > >> > >>>>>>>>>> Typically people set the maven assembly plugin for this and > >> > >>>>> include > >> > >>>>>>> it > >> > >>>>>>>> in > >> > >>>>>>>>>> the build. Would you like me to pitch this in? > >> > >>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>>> On Thu, Jan 8, 2015 at 2:48 PM, Mike Drob < > >> > >>> [email protected]> > >> > >>>>>>> wrote: > >> > >>>>>>>>>> > >> > >>>>>>>>>>> On Wed, Jan 7, 2015 at 9:22 PM, Joe Witt < > >> > >>> [email protected]> > >> > >>>>>>> wrote: > >> > >>>>>>>>>>> > >> > >>>>>>>>>>>> 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? > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> git archive -o [nifi-0.0.1-incubating.tar.gz] > [release-tag] > >> > >>>>> is a > >> > >>>>>>>>>> perfectly > >> > >>>>>>>>>>> reasonable thing to do. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> 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 > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>> > >> > >>>>> > >> > >>>> > >> > >>> > >> > > > >> > > > >> > > > >> > > -- > >> > > Joey Echeverria > >> > > >> >
