Sorry for the delay. Seems one JIRA is already present so created a few more, as follows:
(a) gfsh help (GEODE-985) (b) JMX end-points (GEODE-1465) (c) properties file (GEODE-1466) (d) servlet names for Dev and Admin REST (GEODE-1467) Please feel free to update these issues, as appropriate. I could start with GEODE-985 unless someone is already working on it. Thanks, Nitin On Wed, May 11, 2016 at 12:33 PM, Anthony Baker <[email protected]> wrote: > Thanks Nitin! AFAIK we need new JIRA’s for those issues. > > Anthony > > > On May 11, 2016, at 11:49 AM, Nitin Lamba <[email protected]> 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 <[email protected]> > wrote: > > > >> Great discussion... > >> > >> On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap <[email protected]> > 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 <[email protected]> > >>> 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, <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> > >>>>> 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 < > >>>>> [email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <[email protected]> > >>>>> 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 < > >> [email protected] > >>>> > >>>>> 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 <[email protected] > >>> > >>>>> 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 < > >> [email protected]> > >>>>>>>> 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 > >> > >
