On Fri, Jun 24, 2016 at 5:51 PM, Joey McAllister wrote:
> Regarding the repo: Do Apache projects usually use the same repo for code
> and for documentation, or do they separate them so that adding to or
> editing the docs doesn't necessitate kicking off an application build?
You can do it either
Ok, great. Thanks, Jens!
On Mon, Jun 27, 2016 at 8:30 AM Jens Deppe wrote:
> Joey,
>
> We can configure CI to ignore changes to doc files so that they won't
> trigger a build; so that shouldn't be a concern here.
>
> --Jens
>
> On Fri, Jun 24, 2016 at 5:51 PM, Joey McAllister
> wrote:
>
> > Hi a
Joey,
We can configure CI to ignore changes to doc files so that they won't
trigger a build; so that shouldn't be a concern here.
--Jens
On Fri, Jun 24, 2016 at 5:51 PM, Joey McAllister
wrote:
> Hi all,
>
> Pivotal currently is working through the process of converting the existing
> Geode man
Hi all,
Pivotal currently is working through the process of converting the existing
Geode manual from DITA to the more open-source-friendly markdown. The value
in this is that anyone will be able to contribute, rather than just folks
who have access to DITA editors.
Our automated conversion intro
>From a technology readiness perspective, hosting the docs on a different
(Apache) site should not be too hard; I've built the docs locally and on
AWS without any major issues.
Irrespective of the hosting location, the content license needs to be fixed
- as per the current github repo [1], it stil
This is an interesting topic.
I've noted Planet Cassandra has free high quality vendor support on behalf
of the Apache Cassandra project.
What is appropriate in terms of core content in the community versus
adjunct members of the community such as companies to create derivative
works?
I could im
On Fri, Apr 29, 2016 at 10:28 PM, Dave Barnes 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?
>
What is the status of the docs being donated? I raise this because the
Cassandra project was recentl
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 co
Thanks Nitin! AFAIK we need new JIRA’s for those issues.
Anthony
> On May 11, 2016, at 11:49 AM, Nitin Lamba 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 reference
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
Great discussion...
On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap 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
R1 without package renaming sounds good.
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)
Seems fine. I just double-checked and jackson v2.2.0 does seem to be still
available on maven central so perhaps GEODE-612 can be closed entirely.
Anthony
> On May 3, 2016, at 5:07 PM, William Markito wrote:
>
> @Anthony, what if we did:
>
> # M3
> GEODE-1028 Broken website link
> GEODE
@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-612Update Jackson version since current version is not on Maven
central
Reasoning here being that
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 wrote:
>
> William,
>
> What do you think about including these in
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
Anthon
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/co
On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith 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 th
Ahh, my misunderstanding...I thought '1.0' was synonymous with
'post-incubation'.
We're hoping to convert our docs from DITA to Markdown before contributing
to ASF, still in the early stages of that conversion.
We'll keep plugging away and keep our eye on the software releases.
On Fri, Apr 29, 201
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 :)
In any case we don't need to graduate or even be graduation ready to
rele
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 wrote:
> The package renaming would most likely break some backwards compatibility
> between 1.0 and 2.0. I'd prefe
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.g
+1
--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Apr 29, 2016 11:59 AM, "Dan Smith" 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 po
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
24 matches
Mail list logo