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 > > >
