Thanks Nitin! AFAIK we need new JIRA’s for those issues. Anthony
> On May 11, 2016, at 11:49 AM, Nitin Lamba <nla...@apache.org> wrote: > > Sorry missed this thread last week. > > +1 on package-renaming to be picked-up after 1.0 release. > > However, the community should try to fix any visible Gemfire references. > Following are a few I know of: > (a) Rename Gemfire to Geode on gfsh commands and help (global replace in > CliStrings class; cleaner way is to use 'format' text using > GemFireVersion.getProductName) > > (b) Rename Gemfire to Geode on JMX end-points (probably rework on JMX, > management REST, and Pulse) > > (c) Renaming gemfire.properties to geode.properties > > Does anyone know if there are existing JIRAs for these? If not, I'll create > new ones and happy to drive at least a few of these for M3. > > Thanks, > Nitin > > > On Tue, May 3, 2016 at 9:19 PM, William Markito <wmark...@pivotal.io> wrote: > >> Great discussion... >> >> On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap <bdunla...@gmail.com> wrote: >> >>> R1 without package renaming sounds good. >>> >> >> Cool. >> >> >>> >>> Along with the R1 release info, it would be uber-helpful to clarify >>> cheese-moving public (and internal) API munging that's cooking with R2. >>> >>> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328142#GeodeModularizationProposal(workinprogress)-Packagenamingscheme >>> >>> >> Some things in this proposal sort of happened with the new layout of the >> artifacts and sub-modules in Geode, transparent to end users >> through geode-dependencies.jar, but a lot would be a work in progress while >> we refactor the code base and may require multiple releases... IHMO. >> >> >>> For example: >>> Will 2.0 require existing Gemfire clients to bite the >> com.gemstone.gemfire >>> bullet? (no yucky package passthrough mappers?) >>> >> >> Now the package rename (and not the artifacts renaming like jar files) >> could indeed affect GemFire clients but we, at Pivotal, are working on a >> solution to mitigate (or even completely avoid) that impact. >> >> >>> Does 2.0 include refactored Native Client stuff too? >>> >>> >> That is a good question and I would say that it does make sense given that >> we would then have a faster release of 1.0.0 without Native Client. - In >> fact we've started the work /process already and given that the community >> does accept it we should consider including it on 2.0. But for now, we >> should probably wait until that process is concluded. >> >> >>> >>> Thanks, >>> Brian - >>> >>> >> Thanks for feedback! >> >> >>> >>> On Tue, May 3, 2016 at 7:07 PM, William Markito <wmark...@pivotal.io> >>> wrote: >>> >>>> @Anthony, what if we did: >>>> >>>> # M3 >>>> GEODE-1028 Broken website link >>>> GEODE-1133 SeparateClassloaderTestRunner >>>> GEODE-1260 Source distribution version info >>>> >>>> # 1.0.0 >>>> GEODE-1191 HDFS references >>>> GEODE-612 Update Jackson version since current version is not on >> Maven >>>> central >>>> >>>> Reasoning here being that we'd be working on other JSON related items >> for >>>> 1.0 as well and to not add much to M3. If you strongly believe it all >>>> should be in M3, fine as well.. I'm just trying to get M3 out sooner. >>>> >>>> @Brian, the current thinking would be to tackle package renaming (and >> all >>>> the testing related to it) in the next major release for Geode, making >>> 1.0 >>>> the release to finalize the migration to ASF - And we would take all >> the >>>> lessons learned and efforts to 2.0 which would then come much faster >>> given >>>> that we wouldn't have to deal with licensing/clean up, while we learn >> how >>>> to release and iterate on new features. 2.0 would also be focusing on >>>> graduation from incubation... What do you think ? >>>> >>>> >>>> On Tue, May 3, 2016 at 4:50 PM, <bdunla...@gmail.com> wrote: >>>> >>>>> Did Kirk's note about package renaming make the M3 scope? I think it >>>> would >>>>> be great to start Geode's 1.0 on a consistent naming standard. >>>>> :) >>>>> >>>>> Pro-Geode!!! >>>>> Brian - >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On May 3, 2016, at 6:09 PM, Anthony Baker <aba...@pivotal.io> >> wrote: >>>>>> >>>>>> William, >>>>>> >>>>>> What do you think about including these in M3? >>>>>> >>>>>> GEODE-612 Update Jackson version since current version is not on >>>>> Maven central >>>>>> GEODE-1028 Broken website link >>>>>> GEODE-1191 HDFS references >>>>>> GEODE-1133 SeparateClassloaderTestRunner >>>>>> GEODE-1260 Source distribution version info >>>>>> >>>>>> Anthony >>>>>> >>>>>> >>>>>>> On May 3, 2016, at 3:49 PM, William Markito <wmark...@pivotal.io> >>>>> wrote: >>>>>>> >>>>>>> Guys, restarting this thread to get a discussion going about M3, >>> 1.0.0 >>>>> and >>>>>>> next - As the release manager for M3 here is what I'd like to >>>> propose. >>>>>>> >>>>>>> Any feedback is welcome and let's also reuse this thread to talk a >>>>> little >>>>>>> bit about roadmap as well ? >>>>>>> >>>>>>> # Current M3 Scope ( >>>>>>> >>>>> >>>> >>> >> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release >>>>>>> ) >>>>>>> >>>>>>> GEODE-33 >>>>>>> GEODE-823 >>>>>>> GEODE-835 >>>>>>> GEODE-919 >>>>>>> GEODE-1146 >>>>>>> GEODE-1168 >>>>>>> GEODE-1203 >>>>>>> GEODE-1259 >>>>>>> GEODE-1278 >>>>>>> GEODE-1293 >>>>>>> GEODE-1316 >>>>>>> GEODE-1256 >>>>>>> GEODE-1267 >>>>>>> >>>>>>> == Proposed scope & roadmap == >>>>>>> >>>>>>> I'd like to breakdown the release a little bit and already start >>>>> planning >>>>>>> the next releases. >>>>>>> >>>>>>> # Geode 1.0.0-incubating M3 >>>>>>> >>>>>>> GEODE-1316 Update @since tags to include GemFire or Geode in the >>>> version >>>>>>> name >>>>>>> GEODE-1293 Align code and docs for modules >>>>>>> GEODE-1278 AbstractPeerTXRegionStub should throw >>>>>>> TransactionDataNodeHasDeparted when remote cache is closed >>>>>>> GEODE-1267 NOTICE file improvements >>>>>>> GEODE-1256 Geode website - Unapproved licenses >>>>>>> GEODE-1203 gfsh connect --use-http reports a >> ClassNotFoundException >>>>>>> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, >>>> asc.sha1) >>>>>>> GEODE-835 Replace joptsimple source with a binary dependency >>>>>>> GEODE-823 RC Feedback: Fix build artifacts >>>>>>> GEODE-33-1 Create project examples >>>>>>> >>>>>>> # Geode 1.0.0-incubating >>>>>>> >>>>>>> GEODE-33-2 Create project examples >>>>>>> GEODE-1331 gfsh.bat on Windows is incorrect >>>>>>> GEODE-1168 geode-dependencies manifest is missing jars that are >>>> present >>>>> in >>>>>>> the lib directory >>>>>>> GEODE-629 Replace use of org.json with Jackson JSON library >>>>>>> GEODE-607 the offheap package needs better unit test coverage >>>>>>> GEODE-136 Fix possible NullPointerException in Gfsh's 'list >> regions' >>>>>>> command's GetRegionsFunction. >>>>>>> >>>>>>> # Geode 1.X.0-incubating >>>>>>> >>>>>>> GEODE-17 Provide Integrated Security >>>>>>> GEODE-11 Lucene Integration >>>>>>> GEODE-33-3 Create project examples >>>>>>> >>>>>>> # Geode 2.0.0-incubating >>>>>>> >>>>>>> GEODE-72 Remove deprecated APIs from Geode >>>>>>> GEODE-37 Package renaming >>>>>>> --------------------------- >>>>>>> >>>>>>> Comments: >>>>>>> >>>>>>> GEODE-33 would be broken into 3 different tasks, where on M3 we >>> would >>>>> start >>>>>>> with the example structure and a few examples, and incrementally >> add >>>>> more >>>>>>> examples in the next releases. >>>>>>> >>>>>>> GEODE-37 is the package rename which due to the huge effort in >>> testing >>>>> and >>>>>>> with the goal to complete the removal of deprecated API's >> (GEODE-72 >>>> and >>>>>>> it's sub-tasks) would be pushed to 2.0. This would also allow >> faster >>>>>>> releases in 1.0.0 series. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton < >>>>> niall.pember...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <dsm...@pivotal.io> >>>>> wrote: >>>>>>>>> >>>>>>>>> I'm not sure if the docs are a prerequisite for graduation. I >>> don't >>>>> think >>>>>>>>> there are specific requirements about the level of documentation >>> for >>>>>>>>> graduation, just about community involvement - which docs could >>> help >>>>>>>>> encourage :) >>>>>>>> >>>>>>>> I think this is a grey area with the user docs being on a vendor >>>> site. >>>>>>>> Theres a requirement that "every podling site sources should be >>>>> maintained >>>>>>>> in the podling's site SVN or git directory"[1]. Clearly geode >> meets >>>>> this to >>>>>>>> the letter of the law and I've seen other projects websites point >>> to >>>>>>>> external resources that are useful. Since theres a plan to donate >>>> them >>>>> at >>>>>>>> some point, my guess is it wouldn't be an issue. >>>>>>>> >>>>>>>> [1] http://incubator.apache.org/guides/sites.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In any case we don't need to graduate or even be graduation >> ready >>> to >>>>>>>>> release 1.0. The version number 1.0 has no special meaning to >> the >>>> ASF >>>>> as >>>>>>>>> far as I can tell. But I think having regular releases and >> having >>> an >>>>>>>>> official non-milestone release will help us grow the community. >>>>>>>> >>>>>>>> A release without a milestone/alpha/beta qualifier is going to >>>> indicate >>>>>>>> this community thinks its ready for serious use - so while you're >>>> right >>>>>>>> from a ASF perspective, it will have a special meaning for the >>> wider >>>>> geode >>>>>>>> community. And while keeping the existing package names makes the >>>>>>>> transition easier for existing gemfire users, a package rename >> in a >>>>> later >>>>>>>> version will add pain to the new vast(hopefully!) user base for >>>> geode. >>>>> So I >>>>>>>> would say do it now rather than later. >>>>>>>> >>>>>>>> However, if you're going to change the package name, then its >> also >>> a >>>>> good >>>>>>>> time to remove any deprecated features and correct/change any >> API's >>>>> that >>>>>>>> you're not 100% happy with - which may be alot more work than >> just >>>>> changing >>>>>>>> the package name. >>>>>>>> >>>>>>>> Niall >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> This page has some information on what's required for >> graduation: >>>>>>>> >>>>> >>>> >>> >> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements >>>>>>>>> >>>>>>>>> -Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes < >> dbar...@pivotal.io >>>> >>>>> wrote: >>>>>>>>>> >>>>>>>>>> We plan at some point to donate the docs so they'll be >>> incorporated >>>>>>>> into >>>>>>>>>> the repo. Is this a prerequisite to graduating from incubation? >>>>>>>>>> >>>>>>>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io >>> >>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> The package renaming would most likely break some backwards >>>>>>>>> compatibility >>>>>>>>>>> between 1.0 and 2.0. I'd prefer to see the packages get >> renamed >>>>>>>> before >>>>>>>>>> 1.0 >>>>>>>>>>> so we can change the packages of Message classes, etc in the >>> same >>>>>>>>> release >>>>>>>>>>> that introduces the new JGroups. >>>>>>>>>>> >>>>>>>>>>> The packages are currently a mess of com.gemstone.*, >>> com.vmware.*, >>>>>>>>>>> joptsimple.*, org.json.* (would we change all four or just the >>>>>>>>>>> gemstone/vmware packages?). >>>>>>>>>>> >>>>>>>>>>> I'm probably biting off more than I should, but I'd be willing >>>> head >>>>>>>> up >>>>>>>>>> the >>>>>>>>>>> package renaming effort. >>>>>>>>>>> >>>>>>>>>>> I think maintaining backwards compatibility (rolling upgrades >>>>>>>> included) >>>>>>>>>> for >>>>>>>>>>> releases following Geode 1.0 is a definite requirement. I'd >> like >>>> to >>>>>>>> see >>>>>>>>>> the >>>>>>>>>>> other discussion thread about defining the Geode protocol(s) >>>>> converge >>>>>>>>>> with >>>>>>>>>>> this thread. Officially defining the communication protocols >>>>>>>> (cluster, >>>>>>>>>>> client/server, etc) would ideally happen in conjunction with >> 1.0 >>>> so >>>>>>>>> that >>>>>>>>>>> it's concrete and less ambiguous for 2.0 and later releases. >>>>>>>>>>> >>>>>>>>>>> -Kirk >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith < >> dsm...@pivotal.io> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> We've been releasing milestones of 1.0, but at some point we >>>>>>>> actually >>>>>>>>>>> have >>>>>>>>>>>> to release a real geode 1.0 :) >>>>>>>>>>>> >>>>>>>>>>>> What is keeping us from releasing geode 1.0 at this point? >> Just >>>> the >>>>>>>>>>> issues >>>>>>>>>>>> currently marked with Fix Version M3? I think we should nail >>> down >>>>>>>> the >>>>>>>>>>> scope >>>>>>>>>>>> of 1.0 and track our progress to the 1.0 release. >>>>>>>>>>>> >>>>>>>>>>>> From the apache process perspective, I don't think 1.0 is any >>>>>>>>> different >>>>>>>>>>>> from the milestone releases we've done so far. The only >>>> difference >>>>>>>>> with >>>>>>>>>>> 1.0 >>>>>>>>>>>> is what it means to the geode community. >>>>>>>>>>>> >>>>>>>>>>>> Gemfire maintained backwards compatibility with previous >>> releases >>>>>>>> for >>>>>>>>>>>> persistent files, client/server, WAN, and P2P messaging. I >>> think >>>>>>>> once >>>>>>>>>> we >>>>>>>>>>>> release 1.0 we should provide that same guarantee that the >> next >>>>>>>> geode >>>>>>>>>>>> release will be backwards compatible with 1.0. >>>>>>>>>>>> >>>>>>>>>>>> We do still have the package renaming (GEODE-37) on the >>> horizon. >>>> My >>>>>>>>>>>> suggestion is that in the interests of getting 1.0 out the >>> door, >>>> at >>>>>>>>>> this >>>>>>>>>>>> point we should just release geode 1.0 with the old packages >>> and >>>>>>>>> rename >>>>>>>>>>>> packages in geode 2.0. >>>>>>>>>>>> >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>>> -Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ~/William >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> ~/William >>>> >>> >> >> >> >> -- >> >> ~/William >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
