You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@doris.apache.org by li...@apache.org on 2018/10/12 03:19:03 UTC
[incubator-doris-website] branch master updated: updated menu,
homepage, faq and sql_reference
This is an automated email from the ASF dual-hosted git repository.
lide pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new a86fc58 updated menu, homepage, faq and sql_reference
a86fc58 is described below
commit a86fc5857b19f9ce3ca1e128d56fa83abbce768b
Author: lide <li...@baidu.com>
AuthorDate: Fri Oct 12 11:18:47 2018 +0800
updated menu, homepage, faq and sql_reference
---
assets/images/architecture.png | Bin 0 -> 97686 bytes
jbake.properties | 4 -
pages/community.ad | 114 +++++
pages/downloads.ad | 66 +++
pages/{faq.md => faq.ad} | 39 +-
pages/guides/branding.ad | 117 -----
pages/guides/chair.ad | 97 ----
pages/guides/committer.ad | 114 -----
pages/guides/community.ad | 191 --------
pages/guides/entry.ad | 81 ---
pages/guides/graduation.ad | 444 -----------------
pages/guides/ip_clearance.ad | 94 ----
pages/guides/lists.ad | 69 ---
pages/guides/mentor.ad | 269 ----------
pages/guides/names.ad | 266 ----------
pages/guides/participation.ad | 119 -----
pages/guides/pmc.ad | 34 --
pages/guides/podling_sourcecontrol.ad | 118 -----
pages/guides/ppmc.ad | 256 ----------
pages/guides/press-kit.ad | 108 ----
pages/guides/proposal.ad | 899 ----------------------------------
pages/guides/releasemanagement.ad | 49 --
pages/guides/retirement.ad | 105 ----
pages/guides/sites.ad | 112 -----
pages/guides/sql_reference.md | 2 +-
pages/guides/transferring.ad | 234 ---------
pages/guides/transitioning_asf.ad | 161 ------
pages/guides/tutorial.md | 706 ++++++++++++++++++++++++++
pages/guides/website.ad | 50 --
pages/index.ad | 53 ++
pages/index.md | 33 --
templates/menu.gsp | 26 +-
32 files changed, 969 insertions(+), 4061 deletions(-)
diff --git a/assets/images/architecture.png b/assets/images/architecture.png
new file mode 100644
index 0000000..1201bee
Binary files /dev/null and b/assets/images/architecture.png differ
diff --git a/jbake.properties b/jbake.properties
index 6900a2f..7f0294e 100644
--- a/jbake.properties
+++ b/jbake.properties
@@ -4,7 +4,6 @@ render.tags=false
render.sitemap=true
template.homepage.file=homepage.gsp
template.simplepage.file=simplepage.gsp
-template.retired.file=retired.gsp
template.archive.file=archive.gsp
template.tag.file=tags.gsp
template.sitemap.file=sitemap.gsp
@@ -12,9 +11,6 @@ template.post.file=post.gsp
template.page.file=page.gsp
template.feed.file=feed.gsp
template.guide.file=guide.gsp
-template.proposalGuide.file=guide.gsp
-template.pmcGuide.file=guide.gsp
-template.policy.file=policy.gsp
render.index=false
index.file=index.html
content.folder=pages
diff --git a/pages/community.ad b/pages/community.ad
new file mode 100644
index 0000000..52745c2
--- /dev/null
+++ b/pages/community.ad
@@ -0,0 +1,114 @@
+//Licensed under the Apache License, Version 2.0 (the "License");
+//you may not use this file except in compliance with the License.
+//You may obtain a copy of the License at
+//
+//http://www.apache.org/licenses/LICENSE-2.0
+//
+//Unless required by applicable law or agreed to in writing, software
+//distributed under the License is distributed on an "AS IS" BASIS,
+//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+//See the License for the specific language governing permissions and
+//limitations under the License.
+= Apache Doris Community
+Apache Doris Community
+2018-09-29
+:jbake-type: simplepage
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+Most discussion about Doris happens over email and GitHub.
+
+= 1. Doris Community
+
+**WiKi** link:https://github.com/apache/incubator-doris/wiki[Wiki On Github]
+
+**Development mailing list** dev#doris.apache.org for discussion about project development link:mailto:dev-subscribe@doris.incubator.apache.org[(Click here to subscribe this email list)]
+
+**Issues** link:https://github.com/apache/incubator-doris/issues[GitHub Doris Issues and Pull Requests]
+
+**Meetups Doris** meetups for different meetup groups around the world.
+
+= 2. Contributing
+Doris is a community-led project and we are delighted to receive contributions of anything from minor fixes to big new features.
+
+== 2.1 What to work on
+
+If you have an itch to scratch, then by all means do that! Fixing bugs you run into, or adding features you need, are both immensely helpful.
+
+If you're looking for some starter projects, we maintain a list of issues suitable for new developers.
+
+There are plenty of ways to help outside writing Doris code. Code review of pull requests (even if you are not a committer), feature suggestions, reporting bugs, documentation and usability feedback all matter immensely.
+
+== 2.2 Getting your changes accepted
+
+Patches to Doris are done through GitHub pull requests.
+
+In general please follow the contributing guidelines when sending in pull requests. This will help review proceed as quickly as possible.
+
+For code contributions, we require that you agree to a Contributor License Agreement (CLA) before we can accept your code.
+
+= 3. Mentors
+
+* David Fisher (wave@apache#org)
+* Luke Han (lukehan@apache#org)
+* Willem Ning Jiang (ningjiang@apache#org)
+
+= 4. PPMC
+
+* Ruyue Ma (https://github.com/maruyue, maruyue@apache#org)
+
+* Chun Zhao (https://github.com/imay, zhaoc@apache#org)
+
+* Mingyu Chen (https://github.com/morningman, morningman@apache#org)
+
+* De Li (https://github.com/lide-reed, lide@apache#org）
+
+* Bin Lin (https://github.com/lingbin, lingbin@apache#org)
+
+* Hao Chen (https://github.com/chenhao7253886, chenhao@apache#org)
+
+* Chaoyong Li (https://github.com/cyongli, lichaoyong@apache#org)
+
+* Sijie Guo (sijie@apache#org)
+
+* Zheng Shao (zshao@apache#org)
+
+
+= 5. Committers
+Committers are collectively responsible for Doris's technical management. This involves setting the direction of the project, contributing code, and reviewing code contributed by others.
+
+You don't need to be a committer to contribute- pull requests are welcome from anyone.
+
+All committers are members of the PPMC.
+
+== 5.1 Becoming a committer
+
+If you'd like to become a committer, that's great! Please contact one of the existing committers for a walk through the process. Basically, what we're looking for is an interest in ongoing contributions to Doris.
+
+= 6. General committer guidelines
+
+If you are an official Doris committer then congratulations! You are part of a fantastic group of people. Here are some guidelines to follow to help ensure the Doris project continues to grow and improve:
+
+You can merge your own pull request if it fits the rest of the criteria. A common thing to see is "+1 after travis" from other committers.
+
+A pull request should have at least one +1 from a committer who is not the author, on the "code/textual" level of review.
+
+Pull requests which have just one +1 from a committer couldn't be merged earlier than after 3 working days since PR submission.
+
+A pull request with just one +1 could be merged only by (or in coordination with) the committer who provided the review. Because the reviewer may think that the PR is complex or risky enough that needs another pair of eyes to look at it. If this is the case, the first reviewer should indicate this in the PR approval message.
+
+If a pull request has two or more +1's from committers who are not the author, it could be merged immediately and by any committer. But still, enough time since the PR submission should pass to give folks a reasonable chance to indicate a desire to comment on the pull request. AKA: don't merge a pull request that was submitted Friday evening until at least 1~2 regular work days have passed. Use good judgement here.
+
+= 7. Governance
+The PMC (Project Management Committee) is responsible for the administrative aspects of the Doris project. The responsibilities of the PMC include:
+
+* Approving releases
+
+* Nominating new committers
+
+* Maintaining the project's shared resources, including the github account, mailing lists, websites, social media channels, etc.
+
+* Maintaining guidelines for the project
+
diff --git a/pages/downloads.ad b/pages/downloads.ad
new file mode 100644
index 0000000..155c868
--- /dev/null
+++ b/pages/downloads.ad
@@ -0,0 +1,66 @@
+//Licensed under the Apache License, Version 2.0 (the "License");
+//you may not use this file except in compliance with the License.
+//You may obtain a copy of the License at
+//
+//http://www.apache.org/licenses/LICENSE-2.0
+//
+//Unless required by applicable law or agreed to in writing, software
+//distributed under the License is distributed on an "AS IS" BASIS,
+//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+//See the License for the specific language governing permissions and
+//limitations under the License.
+= Apache Doris Downloads
+Apache Doris Downloads
+2018-09-29
+:jbake-type: simplepage
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+= Stable release
+The current Doris stable release is 0.8.2. This version is recommended for production use.
+
+* link:https://github.com/apache/incubator-doris/releases/download/v0.8.2/palo-0.8.2-release-20180824.tar.gz[palo-0.8.2-release-20180824.tar.gz] 184 MB
+
+* link:https://github.com/apache/incubator-doris/archive/v0.8.2.zip[Source code (zip)]
+
+* link:https://github.com/apache/incubator-doris/archive/v0.8.2.tar.gz[Source code (tar.gz)]
+
+== Change Log
+
+1. Performance improvement
+ * Support vectorized execution engine.
+ * Support aggregation operator parallelization.
+ * Optimized storage engine for more efficient data fetching.
+
+2. Table-level privileges support
+ * User can grant fine-grained privileges on specified tables to specified user from specified host.
+
+3. Backup and restore
+ * User can backup snapshot of data to HDFS and restore snapshot to other Palo cluster.
+
+4. Broker supports HDFS HA and Hadoop kerberos authentication.
+
+5. Using [BRPC](https://github.com/brpc/brpc) instead of the old RPC framework.
+
+6. A lot of bugs fixed.
+
+7. Other changes:
+
+ * Rewrite http server in Backend using Libevent to replace Mongoose.
+ * Remove mysql code to avoid copyright problem.
+ * More metrics to expose internal situation of Palo system.
+ * Same Frontend can be removed and added again without the changing port.
+ * Change the format of Frontend's audit log for parsing it more conveniently.
+
+== Compatibility
+
+**This release version DOES NOT support rolling upgrade, and CAN NOT rollback after upgrade. So it is HIGHLY RECOMMENDED to backup your data and meta data before upgrading to this release version. Or upgrade it in your test/pre-online Palo cluster to make sufficient test.**
+
+|Item|Content|
+|---|---|
+|Forward Compatibility | 0.8.1, 0.8.0 |
+|Rolling Upgrade | No |
+|Rollback | No |
+
diff --git a/pages/faq.md b/pages/faq.ad
similarity index 92%
rename from pages/faq.md
rename to pages/faq.ad
index 1aa781a..c9f09a8 100644
--- a/pages/faq.md
+++ b/pages/faq.ad
@@ -1,11 +1,24 @@
-title=Apache Doris FAQs
-date=2018-09-28
-type=simplepage
-status=published
-imagesdir=/images/
-~~~~~~
-
-# 建表
+//Licensed under the Apache License, Version 2.0 (the "License");
+//you may not use this file except in compliance with the License.
+//You may obtain a copy of the License at
+//
+//http://www.apache.org/licenses/LICENSE-2.0
+//
+//Unless required by applicable law or agreed to in writing, software
+//distributed under the License is distributed on an "AS IS" BASIS,
+//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+//See the License for the specific language governing permissions and
+//limitations under the License.
+= Apache Doris FAQs
+Apache Doris FAQs
+2018-09-29
+:jbake-type: simplepage
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+= 1. 建表
**Q:建表报错：Float or double can't be used as a key, use decimal instead**
@@ -47,7 +60,7 @@ A:没有
A:Palo只支持utf8编码，对gbk不支持
-# 表的属性和信息查看
+= 2. 表的属性和信息查看
**Q:如何看一个表占了多少物理存储？**
@@ -69,7 +82,7 @@ A:desc table_name all;
A:show partitions from table_name;
-# 修改表
+= 3. 修改表
**Q:palo可以对已有的表增加列吗？**
@@ -151,7 +164,7 @@ A:delete执行之后目前是会影响性能，建议少发delete
A:是的
-# 导入
+= 4. 导入
**Q:show load能按照一些条件查询么，能部分匹配么**
@@ -261,7 +274,7 @@ A:在columns参数中指定表和数据中列的对应关系，并且在需要
A:超过7天的历史数据会被清空
-# 查询
+= 5. 查询
**Q:查询报错：memory limit exceeded**
@@ -307,7 +320,7 @@ A:由create view时的as select决定的，具体可以通过执行explain selec
A:可以通过palo查询mysql库，palo本身不存储mysql的数据，也不能使用palo往mysql中导入数据
-# 其它
+= 6. 其它
**Q:报错：Sql parsing error, check your sql.**
diff --git a/pages/guides/branding.ad b/pages/guides/branding.ad
deleted file mode 100644
index a363798..0000000
--- a/pages/guides/branding.ad
+++ /dev/null
@@ -1,117 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Incubator Branding Guide
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-Podlings are, by definition, not yet fully accepted as part of the
-Apache Software Foundation. Therefore, they are subject to additional
-branding constraints, on top of the
-link:http://www.apache.org/foundation/marks/responsibility[branding guidelines for top-level projects]
-
-== Publicity throughout the Incubation Process
-
-There are three stages in a podling's life-cycle that have an impact
-on the types of publicity seeking that are permitted. We refer to
-"publicity seeking" as issuing press releases or otherwise affirmatively
-seeking publicity (seeding news stories, etc.).
-
-*Podling is in proposal/or pre-code-drop process*: No publicity
-seeking is permitted. A podling is not allowed to be called Apache
-_Podling-Name_ name until the podling is officially in
-Incubation, public mailing lists are announced, and code has been
-submitted into our repositories.
-
-*Podling has been approved for incubation, podling has launched
-public mailing lists, and podling has dropped code into
-repository*: A podling *MUST* now be called Apache
-_Podling-Name_ (see link:#Naming[Naming] below).
-A podling and affiliated persons can issue press releases that
-reference the podling, but cannot issue press releases with the
-specific intent of announcing the Podling. Podling can conduct
-informal pr activities, such as media outreach, blog publicity, etc.
-The ASF will not issue any press releases for any podling at this
-stage. However, the
-link:http://www.apache.org/press/index.html#whoweare[Apache Press Team]
-*MUST* review any releases by affiliated
-organizations or groups to ensure they comply with these branding
-guidelines.
-
-*Podling has graduated from the Incubator*: The Apache Public
-Relations Committee is willing to issue formal press releases for all
-podlings who successfully graduate from the Incubator and are
-interested in issuing a press release. Or, the ASF may enter into a
-joint press release with any other affiliated organizations or groups.
-
-== Naming
-
-After a podling has been approved, the lists are created, and the initial
- code drop has commenced, the podling *MUST* be referred to as Apache
- _Podling-Name_ *AND* mention that the project is
- under Incubation. Suitable mentions include:
-
-- Inclusion of the http://_podling-name_.incubator.apache.org/ URL
-- Apache _Podling-Name_ is currently undergoing Incubation at the Apache Software Foundation.
-
-Other references may only be used upon prior approval by the Incubator PMC. These statements only need to be disclosed upon the first reference in a document.
-
-== Disclaimers
-
-Podling web sites MUST include a clear disclaimer on their
-website and in all documentation (including releases) stating that
-they are in incubation. Podlings SHOULD use the following text for
-all disclaimers (replace the underlined phrases as appropriate):
-
-[quote]
-====
-Apache [.underline]#Podling-Name# is an effort
-undergoing incubation at The Apache Software Foundation (ASF),
-sponsored by the [.underline]#name of Apache TLP sponsor#. Incubation is required of all
-newly accepted projects until a further review indicates that the
-infrastructure, communications, and decision making process have
-stabilized in a manner consistent with other successful ASF projects.
-While incubation status is not necessarily a reflection of the
-completeness or stability of the code, it does indicate that the
-project has yet to be fully endorsed by the ASF.
-====
-
-Podlings wishing to use a different disclaimer message MUST have the
-disclaimer approved by the Incubator PMC prior to use.
-
-For releases, the text SHOULD be included in a separate DISCLAIMER file
-stored alongside the NOTICE and LICENSE files.
-
-== Incubator Logo
-Podlings websites should follow the logo description from link:press-kit.html[Press Kit for Podlings].
-
-== Publicity activities
-Podlings MUST coordinate with the Apache Public Relations Committee on
-all publicity activities by a podling.
-
-The open source space can be difficult
-to negotiate even for experienced professionals. The Apache Public Relations
-Committee understands this space and it is in the best interests of all
-that they are consulted.
-
-== Response to Unapproved Statements
-The Apache Public Relations Committee SHALL affirmatively and publicly
-respond to any unapproved statements surrounding podlings which are factually
-incorrect.
-
-== Termination
-The Incubator PMC MAY consider the termination of a project for
-violation of these branding guidelines.
\ No newline at end of file
diff --git a/pages/guides/chair.ad b/pages/guides/chair.ad
deleted file mode 100644
index a68b728..0000000
--- a/pages/guides/chair.ad
+++ /dev/null
@@ -1,97 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Incubator Chair Guide
-Apache Incubator PMC
-2002-10-16
-:jbake-type: pmcGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Adding New Incubator PMC Members
-
-For a new PMC member being voted in, follow the link:http://www.apache.org/dev/pmc.html#newpmc[standard procedure].
-
-For an ASF Member exercising their prerogative to join the IPMC by request, the only change in procedure
-is to alter the text of the NOTICE sent to the Board:
-
-[literal]
---
-To: board at apache.org
-CC: private at incubator.apache.org
-Subject: [NOTICE] *Jane Doe* for Incubator PMC
-Body:
-
-Apache Member *Jane Doe* has requested to join the Incubator PMC.
---
-
-After the NOTICE period expires, a welcome message should be sent to the new IPMC member.
-
-[literal]
---
-Welcome to the Apache Incubator Project.
-
-Here is some information to get you started as a PMC member.
-
-please subscribe to the incubator mailing lists:
-- general-subscribe at incubator.apache.org
-- private-subscribe at incubator.apache.org
-- cvs-subscribe at incubator.apache.org
-
-You may find it useful to use https://whimsy.apache.org/committers/subscribe to manage your subscriptions
-
-- the base incubator SVN URL is https://svn.apache.org/repos/asf/incubator
-
-- all the public information, rules and policies about the
-Apache Incubator is in
-https://git-wip-us.apache.org/repos/asf/incubator.git,
-and thus published on https://incubator.apache.org/
-
-- https://home.apache.org/phonebook.html?ctte=incubator
-lists all PMC members. This is periodically regenerated from
-https://svn.apache.org/repos/private/committers/board/committee-info.txt.
-
-- the Incubator website is maintained and published according to the
-instructions at http://incubator.apache.org/guides/website.html
-
-- status documents about Incubating projects are under
-incubator/public/trunk/content/project/ directory;
-please keep the ones you are mentoring updated
-
-- all committers on all incubating projects have access to
-the 'incubator/public' repository, so they can
-participate in the general Incubator Project as committers
-
-- please read our work documents; they are
-published under https://incubator.apache.org/policy/incubation.html
-
-Thanks for helping us!
---
-
-== Board Report
-
-The Incubator link:http://www.apache.org/foundation/board/reporting[reports] monthly to the Apache
-link:http://www.apache.org/foundation/board[Board of Directors]. The report itself is the collaborative effort of
-many Incubator contributors, but the Chair is ultimately responsible for ensuring that it is filed.
-
-The Board appreciates receiving the IPMC report:
-
-- on time
-- in a consistent format
-- with an accurate summary of the state of the reporting podlings
-
-The "runbook" for managing the preparation of the report is implemented as a script which prints out documentation,
-instructions, literal commands, due dates, etc in link:https://svn.apache.org/repos/asf/incubator/public/trunk/report_runbook.py[report_runbook.py]
-
-Many of the tasks documented in the runbook may be attended to by either the Chair or a designee such as a "Report
-Manager", but it's the Chair who is accountable for overseeing the process.
diff --git a/pages/guides/committer.ad b/pages/guides/committer.ad
deleted file mode 100644
index 44030e6..0000000
--- a/pages/guides/committer.ad
+++ /dev/null
@@ -1,114 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Committers
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-The link:/policy/incubation.html#Committers[Roles and Responsibilities] document describes the general role of a
-committer on an incubating project. This page provides links to more information to help new committers get started.
-
-== Mailing Lists
-Everything -- but *everything*-- inside the Apache world
-occurs or is reflected in email. As some people say, 'If it isn't
-in my email, it didn't happen.' Decisions only get made on public
-Apache mail lists -- not anywhere off list, such as IRC, IM, or private
-emails.
- Each project has a set of lists, which are typically called
-dev@*project*, user@*project*, and
-commits@*project*. A few link:http://www.apache.org/foundation/mailinglists.html[Apache-wide lists] cross all boundaries, including:
-
-- *committers*: sends important messages to all
-Apache committers; it's not used for discussions;
-- *community*: where all Apache committers can
-discuss things that are about Apache;
-- *infrastructure*: where the roots and the
-infrastructure team discuss and work on the Apache
-infrastructure needs;
-- *legal-discuss*: where Apache committers can
-ask questions that have a legal aspect;
-- *repository*: discussions about the Apache artifact repository;
-- *party*: where people plan how to have fun. :-)
-
-=== Action items for committers include:
-
-- Become familiar with Apache developer link:http://www.apache.org/dev/contrib-email-tips.html[Tips for email contributors].
-- Subscribe to the user, dev, and commits lists for your project.
-- Become aware of what else is going on in the Incubator by subscribing to the Incubator's general list.
-- Become aware of what else is going on at the ASF by subscribing to the link:http://www.apache.org/foundation/mailinglists.html#foundation-community[community], link:http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure[infrastructure], and link:http://www.apache.org/foundation/mailinglists.html#foundation-legal[legal-discuss] Apache-wide lists.
-
-Apache also has private lists. For example, your project will
-probably have a private mail list named private@*project*.incubator.apache.org,
-which your Podling PMC will use for sensitive discussions. Never
-mix public and private mail lists in the same post -- see the
-section titled link:http://www.apache.org/foundation/how-it-works.html#management[Balancing confidentiality and public discussion]
-in link:http://www.apache.org/foundation/how-it-works.html[How it Works]. For example, never include both your dev and private
-lists in the same post. Posting to the dev list is sufficient
-because each member of your Podling PMC will also be on that
-list.
-
-== Project Web Site
-The Incubator link:sites.html[Podling Websites] guide documents how to get your project web site going.
-
-== Committer Resources
-
-- The link:http://www.apache.org/dev/new-committers-guide.html[Guide for New Committers ]is a great place to start and points to additional committer-only resources.
-- Browse the pages at link:http://www.apache.org/dev[http://www.apache.org/dev/] often.
-- Subscribe to the link:http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure[infrastructure] list, then raise awareness on your project on what goes on behind the scenes.
-
-Be proactive about responding to infrastructure issues on your project mailing lists. Does the web server seem to be down? Is Jira or Subversion down? Check the link:http://www.apache.org/dev/#status[status of servers]
-and explain the reason to your project lists (as you can see, no need to alert the ASF infrastructure people).
-
-
-== Podling PMC (PPMC)
-If you are a member of your PPMC, become familiar with the link:/policy/incubation.html[Incubation Policy] and see the link:ppmc.html[Podling PMC Guide].
-
-== Orientating New Committers: Understanding Apache
-
-When a committer is elected by a typical top level project, the nominator
-and other PMC members educate the new committer about Apache. In the Incubator, this
-inductive must be performed by the Mentors. This process is one of the most important
-for the long term health of a project.
-
-Apache works on the principle that discussions should happen on the most open forum
-available. Unless the matter involves a sensitive matter (such as security or
-personal issues), it should be raised on an open mailing list (typically the podling dev list
-or the incubator general list). Use of the incubator private list should be reserved
-for official notifications and sensitive topics.
-
-Mentors need to take care. During the initial bootstrapping a habit may develop
-of emailing private list. It is important to break this habit as soon as the mailing
-lists are available.
-
-Netiquette about the correct use of *cc*'s may also be difficult to
-effectively impart. During the bootstrap process there are a number of occasions
-where *cc*'s are required. The typical usage is to copy in a private
-listing to indicate that the action has the lazy permission of the committee.
-*cc*'s are very commonly used to create inefficient ad-hoc mailing lists in
-the commercial world. Except for a small number of defined processes, *cc*'s
-are frowned upon at Apache. Mentor need to encourage questions to be asked first
-on the public lists of the project then raised (if necessary) to the general
-incubator list.
-
-== Questions?
-If you have any questions, please ask on the Incubator's
-general mail list.
-Don't forget to check the information at:
-
-- link:http://www.apache.org/dev[http://www.apache.org/dev/]
-** it is one of the most current resources for committers.
-- link:general.html#FAQ[Incubator General FAQ]
-
diff --git a/pages/guides/community.ad b/pages/guides/community.ad
deleted file mode 100644
index 907ed1b..0000000
--- a/pages/guides/community.ad
+++ /dev/null
@@ -1,191 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Guide to Successful Community Building
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-Help to improve the system by posting a patch for
-this document to the incubator section of JIRA or a
-comment to the link:lists.html[general] list at
-incubator.
-
-== Abstract
-
-The intent of this document is to help podlings the
-importance of building an open and diverse community for
-their project. It gives guidelines on how to accept new
-committers and PPMC members, and how to enable more
-community involvement, taking off the burden of answering
-every question yourself.
-
-== What is an open and diverse community?
-
-A major criterion for graduation is to have developed an open
-and diverse link:http://www.apache.org/foundation/glossary.html#Meritocracy[meritocratic]
-community. Time has demonstrated that these kinds of
-communities are more robust and productive than more closed
-ones.
-
-=== People
-
-As a project grows, it needs to renew itself by accepting new
-committers. A project needs to learn how it can recruit new
-developers and committers into the community. Accepting new
-committers usually increases the diversity of the project. So,
-this process is very beneficial. link:#notes-community[Community building] requires energy
-which could have been spent on code development but this cost
-is an important investment for the future of the project.
-
-The openness of the community is not only measured by the
-number of contributors. Open and respectful discussions on the
-mailing lists are vital. Ways to resolve technical conflict
-without destroying personal relationships must be learned.
-
-=== Communication
-
-
-Mailing lists are the life blood of Apache communities. They
-are the primary mode of discourse and constitute a public and
-historic record of the project. Other forms of communication
-(P2P, F2F, personal emails and so on) are secondary. There are
-well founded fears about use of these media for project
-communication. Though many projects successfully blend other
-forms of communications, care needs to be taken since
-out-of-band communications have led to difficulties in the
-past. The reason is that communications on other than the
-public mail aliases exclude parts of the community. Even
-publicly advertised IRC chats can be exclusionary due to time
-zone constraints or conflicting time commitments by community
-members who might want to participate.
-
-Apache project mailing lists are public, well indexed and well
-archived. This allows anyone to monitor (both in real time and
-by browsing the archives) what's happening. Opinions expressed
-are public and poor behavior risks a poster's reputation.
-
-Private communications tend to be more candid but also more
-likely to be ill-judged. Back channel communication tend to be
-divisive, excluding some members of the group. This tends to
-have a corrosive effect on the collective spirit of the
-community. Mistrust builds when opinions backed by blocks of
-developers arise fully formed on list.
-
-Communication through other channels also reduces the chance
-of link:http://en.wikipedia.org/wiki/Serendipity[serendipity].
-As with most social networks, most subscribers to a mailing
-list never post and most posts come from a tiny minority of
-subscribers. Some passive subscribers are just interested in
-where the project is going but others understand related
-fields and have a limited intersection of interest. This
-second group will often post when this topic arises on list.
-Using public mailing lists to develop designs allows the
-chance encounter of ideas which often results in innovation.
-
-If alternative forums are used by a project, it is important
-to try to minimize the chances of problems arising. All
-matters of substance need to be moved back to the mailing
-lists. Public records should be kept and posted back to the
-list. Regular reminders should be posted to remind people that
-other secondary forms of communication exist.
-
-There are a limited number of topics such as security issues
-and discussions about people which are best handled in
-private. As much business of the project as possible should
-take place on public lists but the private list is available
-for those matters of a sensitive nature. Good netiquette
-requires that permission from the poster should be sought
-before making public, posts made to a private list. Try to
-avoid cross-posting between public and private forums. Take
-care not to post a reply to a private post to a public forum
-without permission.
-
-Learning to use mailing lists effectively is very important.
-If this can be achieved, then you have shown to be a lively,
-active and successful community. The future looks bright.
-
-=== Community Building
-
-Before a podling graduates, it must create a diverse and
-self-sustaining community. Community building is tough: it
-takes time, effort and more than a little magic. There is no
-secret recipe, just hard work. In order to overcome this
-obstacle, committers may need to devote more time to community
-building and less to development.
-
-The link:mailto:community@apache.org[community mailing list] is open to all Apache committers. This is the right
-list for questions about community and on community building.
-Subscriptions should be from an Apache email address.
-
-==== Raising The Profile
-
-Sometimes, a podling is just not well-enough known. There
-are simply not enough users to allow new developers to be
-recruited. Overcoming this means finding ways to raise the
-profile of the podling. Some ideas:
-
-- Improve the website
-- Improve the information provided within each release and release more often
-- Committers who blog should join link:http://www.apache.org/dev/committers.html#planetapache[PlanetApache]
-- Use grassroots media
-- Encourage downstream distributions to include a packaged version
-- Submit talks to conferences
-- link:http://www.feathercast.org[Feathercast]
-- Write articles
-
-==== Building a community by stepping back a little
-
-
-If the podling has lots of users but very few new
-developers then this means that more work is required to
-encourage users to become developers. A common cause of
-this is that committers are too quick to create code to
-solve user problems. It's good to respond quickly to
-requests by users. However, once a project gains momentum,
-it may be more productive for the long term health of a
-project to encourage users to become more involved at the
-expense of user satisfaction.
-
-Try to encourage expert users to answer questions. This
-may mean intentionally allowing a time gap before
-answering user questions. Encourage users to post by
-taking the time to deal politely and positively with
-misunderstandings and by replying to threads which have
-been answered well by a user to confirm that they are
-right. Avoid engaging in flame wars on user lists. Ignore
-trolls.
-
-Try to encourage users to become developers. When they
-give a good answer that isn't covered in the
-documentation, ask them to submit a patch. When users
-suggest a good design or extension, ask for volunteers to
-help implement rather than just coding it up.
-
-==== Helping Developers Become Committers
-
-If a podling has no trouble attracting developers but
-trouble retaining them long enough for them to become
-committers then this highlights an issue with the
-recruitment process. To become an Apache committer, a
-developer needs to hang around long enough to accumulate a
-track record of contributions. This often requires
-encouragement and help from existing committers.
-
-Promptly reviewing patches is important. The way that
-patches are applied is also important. Provide credit in
-the commit message and when closing the JIRA. It's also
-good to encourage developers by suggesting new related
-work they may like to volunteer for.
diff --git a/pages/guides/entry.ad b/pages/guides/entry.ad
deleted file mode 100644
index 50be73b..0000000
--- a/pages/guides/entry.ad
+++ /dev/null
@@ -1,81 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Enter The Incubator
-Apache Incubator PMC
-2002-10-16
-:jbake-type: proposalGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-This document is under link:#help-wanted[development]. At the moment, this
-is just a skeleton outline.
-
-== Background
-
-This document is descriptive not normative. It discusses and describes
-the process of incubator entry and offers some views about how to approach it.
-It is not an inflexible standard but
-represents a consensus condensed from previous discussions on the
-incubator general list.
-
-=== Help Wanted!
-
-Help to improve the system by posting a patch for this document to the
-incubator section of JIRA or a comment to the general list at incubator.
-
-== Understanding The Acceptance Process
-
-The acceptance process is simple in theory but complex in practice.
-
-The theory is that candidates are accepted or rejected by a vote on a mailing lists.
-Anyone can vote (and are link:participation.html#general-list[encouraged] to do so)
-but only eligable votes are binding on Apache. For candidates
-link:/incubation/Roles_and_Responsibilities.html#Sponsor[Sponsored]
-by the *Incubator* this means members of the
-link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[Incubator PMC].
-
-In practice, the process is more complex for candidates who want to give themselves
-the best chance of being accepted.
-
-Apache policy is set by the Board either directly or through it's special committees.
-The incubation PMC is responsible to the board and so it is the duty of each PMC member
-to vote against a proposal that does not adhere to this policy.
-
-All policy is decided by PMC vote and so represents an active consensus. Though PMC members
-are free to vote in whatever way they choose, it is reasonable to expect PMC members
-to vote against a proposal that does not satisfy policy.
-
-However, satisfying current policy is not sufficient. Acceptance is a democratic process
-requiring positive approval by the electorate. The guides and other documentation are not
-policy. They are approved only through lazy consensus.
-
-See:
-- [links to posts and threads]
-
-== Notes On The Process
-
-=== The Proposal
-
-=== The Vote
-
-When the proposal seems finished and some sort of consensus has emerged, the
-proposal can be put to the vote.
-
-The right time is a matter for judgement. Ask the
-link:/incubator/Roles_and_Responsibilites.html#Champion[Champion] for advice
-or ask on the mailing list. It is usually best to ensure that the discussions
-and debates surrounding the proposal are complete before moving to a vote. This may
-mean move discussions which are not about the proposal to separate threads.
-
-The right duration for the vote is also a matter for judgement [link].
\ No newline at end of file
diff --git a/pages/guides/graduation.ad b/pages/guides/graduation.ad
deleted file mode 100644
index de3acc1..0000000
--- a/pages/guides/graduation.ad
+++ /dev/null
@@ -1,444 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Guide to Successful Graduation
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-The intent of this document is to help podlings
-understand the process of
-graduation and offer some views about how to approach it.
-It also links to the Incubator
-link:http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating_from_the_Incubator[exit policies].
-It is not an inflexible standard but represents a
-consensus condensed from previous discussions on the
-incubator general list. It also describes some of
-the first steps that should be taken after
-graduation.
-
-*This is just a guide. Policy is stated link:/policy/incubation.html[here].*
-
-Help to improve the system by posting a patch for
-this document to the incubator section of JIRA or a
-comment to the link:lists.html#general_at_incubator.apache.org[general] list at
-incubator.
-
-== What is Graduation?
-
-Graduation is the act of a podling becoming either a
-subproject under an already existing Apache project, or
-becoming a top level Apache project. Graduating is a
-democratic process: in the end, it comes down to a *link:http://www.apache.org/foundation/voting.html[VOTE]*. Note
-that during your stay in the incubator, you are already busy
-with the process of Graduating: by adopting Apache procedures,
-growing and fostering your community, having (civil) fights
-concerning code style (tabs versus spaces), cutting releases
-and so forth. All these acts have an influence on your
-projects graduation.
-
-The road to graduation is pretty clear: depending on whether your
-project wants to become a top level project, or join as a
-subproject under an already existing project the steps are
-fairly simple but do take time and effort. This document
-provides guidelines for making this process run smooth.
-
-This document is offered for guidance and education only.
-Actual policy is documented in the link:../incubation/Incubation_Policy.html[Incubation PolicyGuide] in
-link:../incubation/Incubation_Policy.html#Graduating_from_the_Incubator[this]
-section. Please post any questions about graduation
-to the link:lists.html#general_at_incubator.apache.org[general incubator list].
-
-== Whether to Graduate to Subproject or to Top Level Project
-
-Each proposal has a link:/incubation/Roles_and_Responsibilities.html#Sponsor[Sponsor].
-The identity of the Sponsor indicates the natural
-destination. For proposals sponsored by the link:/policy/roles_and_responsibilities.html#the_board[Board] or by
-the
-link:/policy/roles_and_responsibilities.html#incubator_project_management_committee_ipmc[IncubatorPMC (IPMC)], this is a top level project. For others,
-this is as a subproject of the sponsoring project. However, the
-destination is fixed only on graduation, not entry. Projects
-grow and evolve during the graduation process. As
-graduation approaches, this original preference should be
-reviewed based on where the project is now.
-
-Graduation as a subproject is only possible if the
-subproject still falls within the scope of the project and
-requires the consent of the project link:http://www.apache.org/foundation/how-it-works.html#structure[PMC].
-Graduation as a project requires the formation of the new
-project by the link:/incubation/Roles_and_Responsibilities.html#board[Board].
-
-The link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[IPMC]
-will also express a democratic opinion. For those seeking
-to graduate to a subproject this *link:http://www.apache.org/foundation/voting.html[VOTE]*
-is to approve the
-transfer. For those seeking to graduation as a top level
-project, this will be a recommendation to the link:/incubation/Roles_and_Responsibilities.html#board[Board].
-Expect IPMC-ers to ask questions about the project
-including about the choice of destination. This is part of
-the normal process.
-
-== Before You Graduate
-
-Before you start thinking about graduation, you need to make
-sure you are ready and meet the requirements imposed on Apache projects.
-This section will provide a shortlist for podlings to
-determine if they meet the criteria for asking graduation.
-
-=== Graduation Check List
-
-The following is a short checklist giving an overview, not
-a substitute for reading the content below.
-
-* Preparations
-** Complete (and sign off) tasks documented in the link:#notes-status[status file]
-** Ensure link:#notes-names[suitable names] for project name and product names
-** Demonstrate ability to link:#releases[create Apache releases]
-** Demonstrate link:#community[community readiness]
-** Ensure link:/incubation/Roles_and_Responsibilities.html#Mentor[Mentors] and link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[IPMC] have no link:#notes-issues[remaining issues]
-* Decide upon link:#subproject-or-top-level[destination]
-* Prepare a link:#tlp-resolution[resolution] *(top level candidates only)*.
-* link:#subproject-acceptance[Subproject acceptance *VOTE*] by destination Project *(subproject candidates only)*
-* link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[Incubator PMC (IPMC)]:
-** For top level candidates, this is a link:#ipmc-top-level-recommendation[recommendation *VOTE*]
-** For subproject candidates, this is a link:#subproject-graduation[graduation approval *VOTE*]
-* Final link:#notes-on-hand-over[hand-over]
-* Consider post graduation link:#project-first-steps[tasks]
-
-=== Checking the Status File
-
-The status file records and summarizes incubation-related
-information on the podling. The
-link:ppmc.html#Incubator_ASF_Board_Reports[PPMC] is
-responsible for keeping this file current. Before you are
-able to graduate, all tasks need to be completed.
-
-The status file is a great way of keeping tabs on how your
-project is doing and what needs to be done to meet the
-graduation criteria. The link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[Incubator PMC]
-will check this
-file when they vote on the graduation of your project.
-Once all tasks are done and the listed criteria met, your
-project may be ready for graduation.
-
-The status file of the JUDDI project is link:http://incubator.apache.org/projects/juddi.html[one example].
-
-== Ensure suitable project name and product names
-
-Please read link:http://www.apache.org/foundation/marks/naming.html[detailed documentation here].
-The "Process for ensuring suitable project and product names" is mandatory for every podling which wants to
-graduate.
-
-== Creating an Apache Release
-[quote,Eric Steven Raymond, http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html]
-====
-Release Early, Release Often
-====
-
-Projects need to cut releases. Apache projects need to
-understand how to cut Apache releases. Therefore it is an
-important step during your stay in the incubator to
-demonstrate the ability to create an Apache Release.
-
-Podlings do not need to actually *publish* a
-release to demonstrate that they understand how to
-accomplish such a feat. However, creating a release that
-is approved by the link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[incubator project management committee] is usually the
-simplest way to do this.
-
-If you are going to cut a release (which is highly
-recommended), then please read the link:releasemanagement.html[Incubator Release Management Guide] for hints, tips and guidelines for cutting a
-release that will get approved by the
-link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[IPMC]
-without problems.
-
-== Creating an Open and Diverse community
-
-A major criterion for graduation is to have developed an
-open and diverse link:http://www.apache.org/foundation/glossary.html#Meritocracy[meritocratic]
-community. Time has demonstrated that these kinds of
-communities are more robust and productive than more
-closed ones.
-
-Apache projects are self-sustaining and self-governing
-communities. Long term success and health requires that
-these communities understand how to:
-
-- recruit users, developers, committers and PMCers
-- take responsible collective action
-- disagree in public on technical matters without destroying personal relationships
-- create an open, positive and inclusive atmosphere on the mailing lists
-
-Graduation tests whether (in the opinion of the link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[IPMC])
-a podling has learned enough and is responsible enough to
-sustain itself as such a community.
-
-Read more on how to successfully build an open and diverse
-community for your podling in the link:community.html[community guide].
-
-As a project grows, it needs to renew itself by accepting
-new committers. A project needs to learn how it can
-recruit new developers and committers into the community.
-Accepting new committers usually increases the diversity
-of the project. So, this process is very beneficial. link:community.html[Community building] requires
-energy which could have been spent on code development but
-this cost is an important investment for the future of the
-project.
-
-The openness of the community is not only measured by the
-number of contributors. Open and respectful discussions on
-the mailing lists are vital. Ways to resolve technical
-conflict without destroying personal relationships must be
-learned. Learning to use mailing lists effectively is very
-important. If this can be achieved, then you have shown to
-be a lively, active and successful community. The future
-looks bright.
-
-The project is considered to have a diverse community when
-it is not highly dependent on any single contributor
-(there are at least 3 legally independent committers and
-there is no single company or entity that is vital to the
-success of the project). Basically this means that when a
-project mostly consists of contributors from one company,
-this is a sign of not being diverse enough. You can
-mitigate this requirement by admitting more external
-contributors to your project that have no tie to the
-single entity.
-
-Growing an open and diverse meritocratic community is not
-something that just happens: it takes work. Read the link:community.html[building a community guide] for
-guidelines, hints and tips on how you can accomplish this
-for your project.
-
-=== Other Issues
-
-The Incubator relies more on people than rules: rather
-than try to create rules to cover every circumstance,
-rules are developed and codified as required. People
-are trusted to evolve process and policy. This guide
-can only document the most common issues and it is
-possible that there are other concerns that may require
-resolution that are not covered.
-
-Podlings who are unsure if they are ready to graduate may want to consider completing the link:http://community.apache.org/apache-way/apache-project-maturity-model.html[Apache Project Maturity Model]. You may find this to be a useful guide when looking at various factors in your podling's community.
-
-== The Graduation Process
-
-=== Graduating to a Top Level Project
-
-Top level projects are created by the
-link:/incubation/Roles_and_Responsibilities.html#board[Board]. The
-link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[Incubator Project Management Committee (IPMC)] can therefore only
-recommend to the Board that the project is ready to
-graduate to a top level project.
-
-Graduation to a top level project requires:
-
-- a charter for your project
-- a positive community graduation *link:http://www.apache.org/foundation/voting.html[VOTE]*
-- a positive IPMC recommendation *link:http://www.apache.org/foundation/voting.html[VOTE]*
-- the acceptance of the link:#tlp-resolution[resolution] by the Board
-
-This process can take a while, since it typically sparks
-some discussion inside the community and possibly in the
-IPMC.
-
-Here's an estimated timeline for the graduation process.
-It should help you understand when you should start
-ramping up your community to get timely graduation and
-make the process smooth.
-
-image:/images/graduation-timeline.png[Graduation timeline]
-
-For each event we scheduled one or two weeks. Even though
-a *link:http://www.apache.org/foundation/voting.html[VOTE]*
-is usually limited to 72 hours, you should prepare
-for discussion and possibly having to cast a revote with a
-revised proposal.
-
-=== Community Graduation Vote
-
-A community needs to be willing to govern itself
-before it can become a top level project. A good way
-to demonstrate this is through a free *link:http://www.apache.org/foundation/voting.html[VOTE]* (by the
-community) on the graduation proposal.
-
-This *VOTE* is not a requirement but is recommended. It
-is unlikely that link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[IPMC]members
-will vote to approve graduation unless the link:/incubation/Roles_and_Responsibilities.html#Mentor[Mentors]
-and community positively express their readiness for
-graduation. It is wise to notify the
-link:lists.html#general_at_incubator.apache.org[incubator general list] that the community vote is starting. Please do not Cc the
-vote to the general list as that creates confusion, instead you can either:
-- FWD the [VOTE] e-mail to the general list, or
-- Send a different copy to the general list indicating that a graduation community [VOTE] is in progress
-
-=== Preparing a Charter
-
-So, in this case a suitable
-link:/incubation/Roles_and_Responsibilities.html#board[Board] resolution should be
-drawn up by the community advised by the
-link:/incubation/Roles_and_Responsibilities.html#Mentor[Mentors].
-Committers can access the podling template for
-resolutions in the
-link:https://svn.apache.org/repos/private/committers/board/templates/podling-tlp-resolution.txt[committers svn repository]. Your link:https://whimsy.apache.org/roster/ppmc/[whimsy roster] also includes a feature to draft a resolution. Also, resolutions are included in the Board minutes, which are posted publicly
-link:http://www.apache.org/foundation/board/calendar.html[here ] . These contain numerous examples. Good examples include:
-
-- Harmony (see section *E. Establish the Apache Harmony project* in the link:http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_10_25.txt[October 2006 Board minutes])
-- OFBiz (see section *B. Establish Apache Open for Business Project* in the link:http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_12_20.txt[December 2006 Board minutes])
-- Cayenne (see section *C. Establish Apache Cayenne Project* in the link:http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_12_20.txt[December 2006 Board minutes])
-
-The original proposal and the status document should
-be consulted when creating this document. Projects
-evolve over time and some deviation from the original
-proposal may well prove acceptable. The
-link:/incubation/Roles_and_Responsibilities.html#board[Board]
-resolution is the ultimate definition of the scope of
-an Apache project. So, it is important that it
-reflects the vision for the project as it appears on
-the eve of graduation.
-
-A good resolution is neither too narrow nor too broad.
-If the project's scope is too narrow, then its
-activities will be unnecessarily constrained. If a
-project's scope is too broad then it may lack focus
-and suffer from governance issues.
-
-If you read these resolutions you also see that you
-need to appoint a link:http://www.apache.org/foundation/glossary.html#Chair[Chair]
-for your project. It is up to the
-link:ppmc.html[PPMC] to choose one
-person to act as the chair after graduation.
-
-=== The Recommendation Vote
-
-The link:#tlp-resolution[resolution] should be proposed on the general
-link:mailto:general@incubator.apache.org[incubator list] before a *link:http://www.apache.org/foundation/voting.html[VOTE]*
-is started to allow feedback. Once a consensus has been reached, a *VOTE*
-should be started on the same general incubator list by a member of the link:ppmc.html[PPMC] proposing
-that the
-link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[IPMC]
-recommends the resolution to the link:/incubation/Roles_and_Responsibilities.html#board[Board].
-
-=== Submission of the Resolution to the Board
-
-Top level projects are created by a link:#tlp-resolution[resolution] by the
-link:/policy/roles_and_responsibilities.html#the_board[Board].
-Once the link:#tlp-resolution[resolution] has been
-finalized and consensus reached, it should be
-submitted to the Board. For inclusion in the agenda
-for the next meeting, the resolution should be
-submitted at least 72 hours before that meeting. A
-calendar for meetings is link:http://www.apache.org/foundation/board/calendar.html[available].
-
-Business for the link:/policy/roles_and_responsibilities.html#the_board[Board] should be submitted by a post
-to the *board* mailing list. Posting from
-an Apache address is recommended. Mixing public and
-private lists on a post is not recommended.
-
-The *board* list is private.
-The usual link:http://www.apache.org/foundation/how-it-works.html#management[netiquette]
-for Apache private lists should be observed. So, it is
-recommended that only the podling and
-link:/policy/roles_and_responsibilities.html#incubator_project_management_committee_ipmc[IPMC]
-private lists are CC'd (rather than the general incubator
-list). Please treat responses with appropriate
-confidentiality.
-
-The submission should include:
-- A clear subject (for example *Establish Foo TLP*)
-- A brief introduction
-- The name of proposed VP
-- Links to the *VOTE* threads
-- Summary of the *VOTE* results
-- The link:#tlp-resolution[resolution] text
-
-For example:
-[source]
-====
-From: <you _at_ apache dot org>
-To: <board _at_ apache dot org>
-CC: <<project>-private _at_ incubator dot apache dot org>
-Subject: Proposed Resolution: Establish <project> TLP
-
-Dear Apache Board,
-
-<Project> is ready for graduation out of the incubator. So, please
-consider the draft resolution below at your next meeting.
-
-<thank you, best regards, personal note if you wish, etc etc>
-
-<your name>
-
---
-References:
-
-Home: <project home page>
-Vote by project: <link to vote thread on project list>
-Vote by incubator: <link to vote thread on general list>
-
-Resolution draft:
-
-<<resolution goes here, 72 characters wide,
-indent with 4 spaces>>
-
---
-<your e-mail sig, if you have one>
-====
-
-Please try to keep the *board* list traffic low. Do not
-submit reminders or ask whether messages have been
-received on the list. link:http://www.apache.org/foundation/members.html[Apache Members] have access to the link:/incubation/Roles_and_Responsibilities.html#board[Board]
-archives and may
-observe Board meetings. To follow the progress of a
-resolution, please ask a friendly Mentor, Member or
-link:http://www.apache.org/foundation/board/[Director].
-
-=== Press Releases for new TLPs
-
-Once there is clear consensus that the recommendation will happen,
-a member of the PPMC should contact ASF Marketing & Publicity at
-*press(at)apache(dot)org* if your project is interested in a
-formal press release announcing your graduation. This should be done
-roughly at the same time that the board resolution is sent.
-
-== Graduating to a Subproject
-
-Subprojects are accepted by a Project Management
-Committee. The link:/incubation/Roles_and_Responsibilities.html#Incubator_Project_Management_Committee_IPMC[Incubator Project Management Committee]
-needs to approve the graduation of the podling to a
-subproject.
-
-=== Community Graduation Vote
-
-Becoming a subproject is a voluntary process, and should be accepted by the community becoming a sub-project. It should be clear to the PPMC and committers for the podling what the make up of the new sub-project should be, e.g. who belongs on the receiving PMC, who will be a committer. Due to this nature, it is important that the podling votes to become a sub-project. This vote should happen on a public dev list.
-
-=== Subproject Acceptance Vote
-
-A formal *link:http://www.apache.org/foundation/voting.html[VOTE]*
-by the Project link:http://www.apache.org/foundation/how-it-works.html#structure[PMC]
-to accept the podling as a subproject is a
-prerequisite. Sometimes, projects may feel that the
-podling has grown too big and would be better as a
-top level project. The Chair of the project is the
-right contact.
-
-=== Graduation Approval Vote
-
-Once the accepting TLP have voted to accept the podling and the podling has voted to become a subproject, noticed should be sent to the IPMC via `general AT incubator.a.o` email list indicating that the podling will become a subproject. If after 72 hours no issues are raised, the podling may be considered a subproject of the accepting TLP. Likewise, if any IPMC member raises an issue, that should be discussed. If the issue is addressed, the member raising the issue should indicate the [...]
-
-=== Final steps
-
-Please read the link:/guides/transferring.html[Guide to Transferring Resources out of the Incubator]
diff --git a/pages/guides/ip_clearance.ad b/pages/guides/ip_clearance.ad
deleted file mode 100644
index 14f4f51..0000000
--- a/pages/guides/ip_clearance.ad
+++ /dev/null
@@ -1,94 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= IP Clearance
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Podling IP Clearance
-
-=== Background
-
-Existing codebases need to be imported through the standard IP clearance
-process. This means that a Software Grant Agreement
-(link:http://www.apache.org/licenses/#grants[SGA])
-or Contributor License Agreement
-(link:http://www.apache.org/licenses/#clas[CLA])
-needs to be submitted
-for all copyright owners. This process may take a while so it is best to
-start as soon as the podling is accepted.
-
-The acceptance of the initial codebases is approved by the
-IPMC as part of the acceptance motion. So, no vote is required by the
-PPMC. Otherwise, follow the standard IP clearance process for podlings.
-
-=== Establishing Provenance
-
-Paperwork needs to be submitted to Apache that grants a legal license on the code
-to the Apache Software Foundation.
-As a rule of thumb, if all the material contributors to the code
-are joining the podling as initial contributors, then CLAs (individual or corporate)
-are all you need. The individuals must submit the 'individual' CLA (ICLA).
-If there are employers involved who might claim
-rights in the code, then corporate CLAs (CCLAs) are needed for those employers.
-
-If, on the other hand, there are material contributors who are *not*
-joining the podling as initial contributors, or if there
-are additional corporate entities who can claim rights in the code,
-then SGAs are required from those individuals or corporations.
-
-The foregoing is only a rule of thumb. Generally, the mentors of a new project
-will need to consult with general@incubator.apache.org or the Apache legal team
-about the particular circumstances.
-
-It may take some time to track down all contributors. It is not necessary to
-have paperwork on file for all contributions before the code is imported.
-It may be necessary to reverse some patches and rewrite areas of code if
-contributors cannot be found or at not happy about given Apache written
-permission to use their code.
-
-No releases are possible until the provenance of all the code to be release
-has been clearly established and the relevant paperwork filed with Apache. It is
-therefore important to keep the status updated.
-
-Receipts of ICLAs, CCLAs, and SGAs are recorded by the secretary in
-the private foundation repository. Reading is restricted to members and officers
-of the foundation. If there is no officer or member available then ask on the
-general list.
-
-=== IPMC Responsibility around IP Clearance
-
-The board has charged the Incubator project with management of IP clearance for Apache.
-Instructions are link:http://incubator.apache.org/ip-clearance/index.html[here].
-
-These equally apply to podlings. The Incubator project is responsible for all podlings
-and so is the receiving PMC. So, when a podling requests IP clearance, the
-IPMC wears link:http://www.apache.org/foundation/how-it-works.html#hats[two hats].
-This may be a little confusing at first.
-
-The Incubator PMC must approve the clearance. This indicates that the project is
-happy to receive the code donated. When a new podling is created, this is done
-by the identification of existing codebases in the proposal. Otherwise, the
-IPMC delegates this decision to the PPMC.
-
-As usual, three binding votes are required. So, Mentors need to be involved in
-IP clearance for podlings. If too few binding VOTEs are posted on list,
-the VOTE will need to be posted to the general list for ratification.
-
-The second hat is technical IP clearance. Here, the IPMC needs to check that the
-paperwork is in order. Once the acceptance vote has been approved, an officer
-or member need to complete the process. For a podling, this will typically
-involve a Mentor.
diff --git a/pages/guides/lists.ad b/pages/guides/lists.ad
deleted file mode 100644
index a365cfc..0000000
--- a/pages/guides/lists.ad
+++ /dev/null
@@ -1,69 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Incubator Mailing Lists Guide
-Apache Incubator PMC
-2002-10-16
-:jbake-type: pmcGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Incubator Mailing Lists Guide
-
-=== Archive Policy
-Please read the link:http://www.apache.org/foundation/public-archives.html[Apache Public Forum Archive Policy] before sending email to any list.
-
-=== Incubator-wide Mailing Lists
-
-==== general at incubator.apache.org
-
-This is where general and public discussion of the Incubator takes place.
-- link:mailto:general-subscribe@incubator.apache.org[Subscribe]
-- link:mailto:general-unsubscribe@incubator.apache.org[Unsubscribe]
-- link:http://mail-archives.apache.org/mod_mbox/incubator-general/[Archives]
-
-You can also use link:https://whimsy.apache.org/committers/subscribe[Whimsy] to manage your subscriptions, if you are a committer at Apache.
-
-==== cvs at incubator.apache.org
-
-This is the Incubator's "commits" list, named "cvs" for historical reasons. Changes made to the link:https://svn.apache.org/viewvc/incubator/public/trunk[Incubator codebase and website] and
-the link:http://wiki.apache.org/incubator[Incubator wiki] trigger automatic notifications to
-this list. Replies go to the link:general+at+incubator.apache.org[general list].
-
-- link:mailto:cvs-subscribe@incubator.apache.org[Subscribe]
-- link:mailto:cvs-unsubscribe@incubator.apache.org[Unsubscribe]
-- link:http://mail-archives.apache.org/mod_mbox/incubator-cvs/[Archives]
-
-=== podlings at incubator.apache.org
-
-This mail alias is for all of the dev lists for all active podlings. It is used
-for incubator wide announcements so that podlings don't need to be subscribed to general for all information.
-Emails to podlings at incubator should be done as a BCC, with general in the to, in order to avoid spamming
-all of the podlings.
-
-=== Podling Mailing Lists
-
-Each podling under incubation has its own mailing lists, which should be easily discovered via the
-podling website or via the link:/projects/index.html[podling status pages].
-These are the right place to get involved with a particular project or to ask project specific
-questions. They form the public record of the development of the project. All lists are link:http://mail-archives.apache.org[archived].
-
-=== Foundation-wide Mailing Lists
-
-Many link:http://www.apache.org/foundation/mailinglists.html[ASF-wide lists] will
-also be of interest to Incubator participants. The
-link:http://www.apache.org/foundation/mailinglists.html#foundation-legal[legal discussion],
-link:http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure[infrastructure],
-and link:http://www.apache.org/foundation/mailinglists.html#foundation-community[community]
-lists are especially germane for PPMC members and release managers trying to develop their knowledge
-and stay current.
diff --git a/pages/guides/mentor.ad b/pages/guides/mentor.ad
deleted file mode 100644
index 66d46df..0000000
--- a/pages/guides/mentor.ad
+++ /dev/null
@@ -1,269 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Mentors' Guide
-Apache Incubator PMC
-2002-10-16
-:jbake-type: pmcGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-The Mentors' guide is a go-to place for information about getting a podling up and running from an infrastructure point of view.
-
-This document targets any Incubating Project member, but
-especially Mentors, who have to ensure that some things get done.
-For a general description of the role of a mentor on an incubating
-project see the
-link:/policy/roles_and_responsibilities.html#Mentor[Roles and Responsibilities]document.
-
-This guide is a descriptive and at times
-discursive document. It describes established practices.
-It is informational not normative. Policy is laid down in the
-link:/incubation/Incubation_Policy.html[Incubation Policy].
-
-== Overview
-
-After the Podling has been accepted by the Incubator PMC, one of the mentors
-link:/incubation/Incubation_Policy.html#Setting+Up+a+New+Podling[sets up]
-the Podling; _i.e._ adds the podling metadata, creates the initial Podling status page, and
-either creates or requests that
-other resources (mail lists, subversion, bug tracker, _etc._)
-be created.
-
-== Add to Incubation Summary file
-
-Add the podling to the podling summary file in
-the "incubator" SVN at *content/podlings.xml*
-(e.g. copy the entry from another podling that also has status="current")
-and see link:website.html[instructions].
-
-Please do this step ASAP after Acceptance. Other setup procedures utilize
-this metadata.
-
-Add a *'reporting'* tag (after *'description'*) with the attribute *'monthly="true"'*
-and the appropriate "group" attribute, based on the month in which the podling
-entered incubation (1 for January, April, July, October, 2 for February, May,
-August, November or 3 for March, June, September, December). The text content
-of the 'reporting' tag must contain the initial list of reporting months,
-starting with the month after the podling entered incubation. Below is an example of the final XML snippet
-
-[literal]
-----
- <podling name="PodlingName" status="current" resource="podlingname" sponsor="Sponsor" startdate="YYYY-MM-DD">
- <description>A description of the podling, for the status page and reports</description>
- <reporting group="1|2|3" monthly="true">First,Second,Third</reporting>
- <champion availid="userid">Champion Name</champion>
- <mentors>
- <mentor username="userid">Mentor One</mentor>
- <mentor username="userid">Mentor Two</mentor>
- <mentor username="userid">Mentor Three</mentor>
- </mentors>
- </podling>
-----
-
-An example reporting block:
-[literal]
-----
-<reporting group="3" monthly="true">June, July, August</reporting>
-----
-Once the first three reports are complete, the monthly attribute should be removed
-and the list of months removed as well.
-
-The first report might be
-very short. However it is better that the Incubator PMC can help to
-guide through the early setup stages.
-For more details see the
-link:ppmc.html#Incubator+ASF+Board+Reports[PPMC Guide].
-
-== Initialize Podling Status Page
-
-A mentor needs to
-link:website.html#Edit+your+project+status+page[create the web page] that will track the project's status.
-A mentor will also need to update it until
-link:ppmc.html#Project+Status+Updates[others in the project's PPMC can update it].
-
-The status
-page is the incubator's record of the progress made.
-It MUST be kept update to date during incubation.
-Some of the information is available from the proposal.
-As the startup process continues and resources are
-created the status SHOULD be updated.
-
-The template contains lists of actions which may be needed
-to start up a podling. All those which do not apply should
-be deleted.
-
-The status page is a useful aid to workflow. Volunteers
-can use it to sign up to the various tasks and monitor their
-progress. Once the mailing lists are set up and prospective
-committers subscribe then these may be used for discussion.
-
-== Resources
-
-Resources should be requested in a particular order, and based on paperwork processed. Do not request source repositories before SGAs are filed, for instance, if the source code is not already Apache licensed or Category A licensed.
-
-The proposal should include a list of required resources. All of these will
-require active set up. Some are created by infrastructure after an appropriate
-request, others can be set up by any IPMC members (typically mentors).
-
-The first resources to be created are LDAP and DNS. These should be requested via link:https://issues.apache.org/jira/browse/INFRA[Apache Infra JIRA -> New Podling Parent Request]
-
-Once these items are requested, mailing lists should be created next. Other resources typically post information to these lists.
-
-=== Request Mailing Lists
-
-Apache mailing lists require volunteer moderators. New moderators can be
-link:http://www.apache.org/dev/committers.html#mailing-list-moderators[changed later]
-but at least one volunteer is required before the mailing lists can be set up.
-Moderation is a reasonably
-link:http://www.apache.org/dev/committers.html#mail-moderate[easy task]
-though moderators may want to set up
-link:http://spamassassin.apache.org/[spam filtering].
-Having at least three moderators is recommended to spread the load.
-
-The proposal should contain the rest of the information that needs to be collected
-before the mailing lists can be requested. Incubator is the responsible top level project.
-So the domain *MUST* be *incubator.apache.org*.
-For example:
-
-- dev@${podling}.incubator.apache.org
-- commits@${podling}.incubator.apache.org
-- private@${podling}.incubator.apache.org
-
-For initial community building it is usually appropriate to only have a "dev" list, to keep the discussions focussed. Later add a "user" list if needed. A podling that is already established and using an existing user interaction channel may want to keep those resources around until they feel they have transitioned to the ASF successfully. You will want to discuss this on your existing development lists.
-
-Note:
-[NOTE]
-----
-If you are using SVN
-Commits under *http://svn.apache.org/repos/asf/incubator/_${podling}_* will be emailed to *commits@${podling}.incubator.apache.org*.
-Any deviation will require special configuration in the *asf-mailer.conf* file by the IPMC.
-----
-
-Mailing lists creation is a task for the link:#who-infra[infrastructure team]. The
-infrastructure team offers a tool that simplifies the creation of mailing lists. You can access the
-link:https://selfserve.apache.org/mail.html[Incubator Mailing List Request Form^]
-to request a list. A notification will be sent to private@incubator when the lists have been created.
-
-Remember to update the project status file with mailing list details. Prospective committers
-and mentors will need to subscribe. Email them once the status file has been updated. Inform
-any existing mailing lists or forums previously used by the project.
-
-Once the *commits* list is created, the project MUST review
-the */incubator/${podling}* tree, since any commits made prior
-to the list's creation will have generated no email trail.
-
-==== Mail Archives
-
-Archives at link:http://mail-archives.apache.org[http://mail-archives.apache.org] for the public
-mailing lists will be setup as part of the mailing list creation process. No action is
-required by Mentors. The archives will be link:http://mail-archives.apache.org/mod_mbox/[visible]
-as soon as posts have been made (and moderated) to these lists.
-
-You can also leverage link:https://lists.apache.org[lists.apache.org^] for
-mailing list archives. There is a login link in the top right corner, which allows you to respond to
-threads from within the web application.
-
-Many projects are independently archived externally (for example, at
-link:http://www.mail-archive.com/[The Mail Archive] and
-link:http://marc.info/?q=about[MARC])
-Independent archives help to
-increase project visibility as well as preserving a independent historic record.
-These subscriptions are not automatically created. If desired, subscribe manually.
-
-Subscriptions to news-to-mailing-list bridges (for example, link:http://www.nabble.com[Nabble])
-must also be created manually. Subscribing helps accessibility and visibility but Nabble news
-users may not be aware that they are posting to a mailing list.
-
-==== Mailing List Administration
-
-Apache uses link:http://www.ezmlm.org/[ezmlm]. See the
-link:http://www.ezmlm.org/man/ezmlmman.html[manual] and
-committer link:http://www.apache.org/dev/committers.html#mail[mail FAQ]
-for more details.
-
-==== Mailing List Transition
-
-Independent mailing lists and groups are perfectly acceptable but development should
-happen on the official mailing lists at Apache. If a project has existing mailing lists,
-forums or groups the community needs to consider their future and plan for the transition
-to the official Apache mailing lists.
-
-It may be useful to move development first to the official lists followed gradually
-by the user resources.
-
-Note that subscribers of external mailing lists will not be automatically subscribed
-to the new Incubator project mailing lists. Instead, a note should be posted to the
-old external mailing list asking them to subscribe to the new list. If possible, add
-a footer to the old mailing list with some instructions.
-
-=== Self Service Requests
-
-Most of the resources you will request can be done via Self Service. To do that, visit https://selfserve.apache.org/ and request the necessary resources. This includes git, mailing lists, JIRA and Confluence. If you do not have access to Self Serve, please use link:https://issues.apache.org/jira/browse/INFRA[JIRA] instead.
-
-==== JIRA Issue Tracking
-
-To request JIRA, visit https://selfserve.apache.org/jira.html
-
-==== Other Issue Trackers
-
-Request an issue tracker on the link:https://issues.apache.org/jira/browse/INFRA[infra jira]
-
-Remember to post an email announcing that the issue tracker is available.
-
-=== Git Migrations
-
-To request a git migration, please file a link:https://issues.apache.org/jira/browse/INFRA[New Git Repository] infra ticket, requesting to migrate from an existing organization to the Apache Organization
-
-=== Gitbox Requests
-
-To request gitbox repositories for a new podling, please first file a link:https://issues.apache.org/jira/browse/INFRA[GitBox Integration] infra ticket. Once your podling has been added, you can use link:https://gitbox.apache.org/ to manage your gitbox repositories and user information.
-
-== [DRAFT] Podling Bootstrap
-
-*NOTE* This section is a DRAFT under development.
-
-Following podling creation, it needs to be bootstrapped. Here are some of the tasks:
-
-- Ensure link:#mentors-ipmc[Mentors are on the IPMC][*Mentors*]
-- Add podling to link:#Sending+in+an+Incubation+Report[reporting schedule] [*IPMC member*]
-- link:#Initialize+Podling+Status+Page[Initialize project status page] [*IPMC member*]
-- Start link:#orientation[orientation] [*link:#who-committers[Prospective committers]*]
-- Start *CLA* and *CCLA* submission [*link:#who-committers[Prospective committers]*]
-- Start link:#initial-ip-clearance[IP Clearance] [*IPMC member*]
-- Request Required Resources
--- link:#request-mailing-lists[Mailing Lists] [Infrastructure Team]
---- Consider and plan link:#transition-mailing-lists[transition to official mailing lists]
--- link:#Set+Up+Repository[Subversion] [IPMC]
--- link:#request-issue-tracking[Issue Tracking] [link:#who-infra[Infrastructure Team]]
---- Consider and plan link:#issue-tracking-transition[issue tracking transition]
-- link:#create-website[Create website] [*link:#who-committers[Prospective committers]*]
--- Consider and plan link:#web-site-transition[web site transition]
-
-== Mentors MUST be on the IPMC
-
-Mentors link:/policy/incubation.html#Mentor[MUST] be on the IPMC. This should be checked prior to beginning incubation.
-Any prospective Mentors who are not yet on the IPMC should ask to be added (by election).
-Email the application to *private@incubator.apache.org*.
-
-[NOTE]
-----
-This process may take a few days.
-----
-
-== CLA and CCLA Submission
-
-Prospective committers need to submit a Contributor License Agreement
-(link:http://www.apache.org/licenses/#clas[CLA]).
-This process can take a while so it is recommended that committers start to submit
-these as soon as the podling is accepted.
diff --git a/pages/guides/names.ad b/pages/guides/names.ad
deleted file mode 100644
index a061925..0000000
--- a/pages/guides/names.ad
+++ /dev/null
@@ -1,266 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Podling Name Search Guide
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-== Introduction
-
-This guide is *not* _legal advice_ or _legal opinion_:
-*do not* use it as a substitute.
-Its aims are education and information *only*.
-
-This process filters out unsuitable names early,
-reducing the legal resources required and
-limiting the potential disruption to a community of a forced name change
-later. A smooth path, but not the only one. If there are reasons
-why this road isn't right for your podling,
-consult link:http://mail-archives.apache.org/mod_mbox/incubator-general/[incubator general].
-
-=== Meet The Apache Branding Team
-
-Names link:http://www.apache.org/foundation/marks/#whoweare[fall] within the responsibilities of the
-link:http://www.apache.org/foundation/[V.P., Brand Management] (and
-link:http://www.apache.org/foundation/marks/#whoweare[team]). Please start by reading:
-
--the link:http://www.apache.org/foundation/marks/[Apache Trademark Policy] (which introduces trademarks and outlines our policy);
--the link:http://www.apache.org/foundation/marks/faq/[Apache Trademark FAQs] (which answers questions asked by downstream consumers); and
--the link:http://www.apache.org/foundation/marks/pmcs.html[Apache Project Branding Requirements] (which guides PMCs).
-
-For podlings in the Incubator, naming issues are managed co-operatively by the Brand and Incubator communities.
-Rules for podlings include all branding requirements for PMCs, plus a few extras.
-
-=== Trademarks
-
-Trademark law is a complex subject.
-Distinctive differences from other intellectual property laws (such as patent or copyright) mean that
-intuition or knowledge gained from other areas may not be applicable.
-The link:http://www.apache.org/foundation[Apache Software Foundation] is
-a link:http://www.apache.org/foundation/faq.html#is-ASF-a-corporation[US corporation].
-Developing some understanding of the basic principles of US trademark law is therefore important.
-
-Please read:
-
-- link:http://www.apache.org/foundation/marks/#principles[Description of key trademark principles] for Apache projects;
-- USPTO trademark
- - link:http://www.uspto.gov/trademarks/index.jsp[home] page
- - link:http://www.uspto.gov/trademarks/basics/index.jsp[basics], and follow the links for materials;
-- link:http://en.wikibooks.org/wiki/US_Trademark_Law[US Trademark Law] WikiBook; and
-- link:http://www.ifosslr.org/ifosslr/article/view/11/37[Passport Without A Visa: Open Source Software Licensing and Trademarks] by Tiki Dare and Harvey Anderson in the link:http://www.ifosslr.org/[International Free and Open Source Software Law Review].
-
-==== Trademarks And The Apache License
-
-Like link:http://www.ifosslr.org/ifosslr/article/view/11/37[many]
-link:http://www.opensource.org[open source] licenses, the
-link:http://www.apache.org/licenses/LICENSE-2.0.html[Apache License, Version 2.0]
-focuses on granting copyright and patent rights to the public.
-The _trademark_ section permits only very limited trademark rights.
-
-[quote]
-""
-*6. Trademarks.*
-This License does not grant permission to use the trade names, trademarks,
-service marks, or product names of the Licensor, except as required for
-reasonable and customary use in describing the origin of the Work and
-reproducing the content of the NOTICE file."
-""
--- link:http://www.apache.org/licenses/LICENSE-2.0.html#trademarks[Apache License, Version 2.0]
-
-All Apache projects share the Apache License. This issues standard *copy*
-and *patent* rights to
-downstream consumers. *Trademark* rights for Apache products are issued and managed independently,
-beyond the Apache License. This allows Apache communities to use trademark law to protect their reputation and that of the
-link:http://www.apache.org/foundation/[Foundation], within the broader
-framework provided by the Brand team.
-
-=== What Makes A Name Good
-Good names for commercial products or _UNIX_ utilities have tended to work less well here at Apache.
-Many successful Apache project names are memorable, unusual and a little
-link:http://www.sdtimes.com/TOP_FIVE_HEAD_SCRATCHINGEST_NAMES_FOR_APACHE_PROJECTS/By_Victoria_Reitano/About_APACHE_and_HADOOP_and_HARMONY_and_MYSQL_and_OODT_and_YAY/35959[whimsical].
-These qualities also happen to be useful when it comes to securing trademark protection.
-Have fun. Be creative.
-
-=== Podling Suitable Name Search
-
-The initial link:http://incubator.apache.org/guides/proposal.html[proposal]
-establishes a working name for the new podling.
-Often some discussion and filtering of suitable names happens during the election
-process but this proposed name is *not* final, only _provisional_.
-The community may choose to change it. Or the community may discover that the name is unsuitable:
-in which case a suitable new name must be found.
-
-A podling needs to discover whether a name is suitable.
-The Incubator community calls this process the _suitable name search_.
-This avoids any potential confusion with phrases like
-_trademark search_ with technical meanings in the trademark community.
-Please be careful with language. In particular:
-
-- avoid using loaded technical legal terms;
-- use plain, simple English to describe what you did and what you found;
-- avoid speculation; and
-- don't offer _advice_ or _opinions_.
-
-A suitable name search must be successfully completed before a podling can graduate.
-This isn't the only way one might be done, just a smooth path.
-
-Names are an essential part of building a brand and community.
-Switching names wastes the efforts put into establishing the original name.
-Therefore complete this task as soon as possible.
-
-== Conducting A Suitable Name Search
-
-The aim - to find a name that is acceptable to the community and is not unsuitable.
-
-A suitable name search has public and private elements.
-The link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[tracker] provides the public record.
-Incubator best practice evolves over time, documentation lags.
-The public records of past searches are a primary source of guidance.
-Review now the records of previous searches, beginning with the most recent then working back.
-
-The public record consists of _actions_ (how you searched) and _facts_ (what your search found). In particular,
-in *all* public forums (mailing lists, issue trackers and so on):
-
-
--*Do not* speculate.
--*Do not* use loaded technical legal language.
--*Do not* offer
- -opinions,
- -advice,
- -interpretation, or
- -analysis.
-
-Use the public lists in the Incubator to ask questions about _how_ the search should be conducted.
-Once the information is collected and collated, then ask the trademark team to help interpret and analyse these results
-on the private lists, copying in the PPMC. Finally discuss the results of your investigation on the private PPMC list.
-Whether a name is suitable or unsuitable (or somewhere in between) should be recorded when the issue is closed.
-
-=== Eliminate Unsuitable Names
-To be suitable, a name needs to be
-
-- judged _appropriate_ by the wider community; and
-- _unique enough_ to avoid confusion
-
-Facts and activities performed are link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[recorded] for the public.
-Interpretation and analysis of these facts happens on private mailing lists, the PPMC private in the first instance.
-Whether the name proved suitable or unsuitable should be entered into the public record
-but take care to use our language (_ethically unsuitable_ or
-_not unique enough_) and to avoid loaded legal terms.
-
-
-==== The Main Sequence
-
-Every podling is unique, but using a link:http://outreach.atnf.csiro.au/education/senior/astrophysics/stellarevolution_mainsequence.html[cosmic]
-metaphor, most fit into a main sequence. For podlings on the main sequence,
-most of the bugs should have been squashed and rough edges documented away, so expect a smooth journey.
-Away from the main sequence, process may need to be grown, documentation is likely be sparse
-and progress less smooth.
-
-The main sequence is described here. This well known path is
-appropriate for almost all podlings.
-If there are good reasons to think that your podling is a special case, discuss this with the
-link:http://mail-archives.apache.org/mod_mbox/incubator-general/[Incubator community]
-and reach consensus on the way forward.
-
-==== Appropriateness
-
-Some names are not appropriate for open source projects.
-Acceptability under
-link:http://www.law.cornell.edu/uscode/15/1052.shtml[US Trademark Law] is a good base line.
-This excludes marks that
-
-[quote]
-----
-Consists of or comprises immoral, deceptive, or scandalous matter;
-or matter which may disparage or falsely suggest a connection with persons,
-living or dead, institutions, beliefs, or national symbols, or bring them into contempt, or disrepute;
-----
--- link:http://www.law.cornell.edu/uscode/15/1052.shtml[US Code 15:1052]
-
-Proposals with inappropriate names are unlikely to pass the initial hustings but spend a few moments considering
-whether anything has been missed. Check for alternative meanings, perhaps in foreign languages.
-
-==== Unique Enough Names
-
-The name needs be unique enough to avoid confusion with software that already exists.
-For the community to be able to protect its reputation for quality and openness,
-its name needs to unique enough to have potential as a trademark.
-
-But this isn't only about being able to register trademark protection.
-Ethics also plays a role. Even where a name may offer enough protection, existing adoption
-of the name by an active community may mean that the choice needs to be eliminated on ethical grounds.
-There is some judgment involved in this decision. So, involve the wider Incubator community if a name is already
-used.
-
-==== How To Collect Evidence Of Uniqueness
-
-To decide whether a potential name is _unique enough_ to be suitable
-
-- Collect evidence about current name usage.
-- link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[Record] the facts.
-- Analyse and interpret these facts; in private with help from the brand team.
-- Reach consensus about whether the name is unique enough.
-- link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[Record] whether the name is suitable.
-- If unsuitable then the community should pick a more unique name and repeat this process.
-
-==== Evidence Of Open Source Adoption
-
-Existing adoption amongst another active open source community may give ethical
-reasons for eliminating a name. This is an example of a condition with a fractal
-boundary. Not every name which has been used before need be eliminated as unsuitable
-but this is an issue which needs to be discussed more widely and
-a consensus reached with the broad
-link:http://mail-archives.apache.org/mod_mbox/incubator-general/[Incubator community].
-
-Look for evidence of existing adoption amongst open source communities by searching well known
-foundries (for example link:http://www.github.com[GitHub] and
-link:http://www.sourceforge.net[Sourceforge])
-and the web (use several search engines for example link:http://www.bing.com[Bing],
-link:http://www.google.com[Google] and link:http://www.yahoo.com[Yahoo]).
-Review recent link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[records]
-for contemporary details about where to search.
-link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[Record] each search and describe the results.
-
-If the name been used by the same community before it arrived at Apache, that's fine but should be noted in the
-link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[record].
-
-=== Evidence Of Registration
-
-A number of online resources exist which may help to discover evidence of
-competing registered trademarks.
-Not every trademark is registered. Not every registered trademark is listed in these resources.
-Even if evidence is found of existing registrations,
-this does not necessary eliminate the proposed name. Just
-link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[record] the facts.
-Leave analysis and interpretation to private lists.
-When a search returns a large number of hits, focus on live registrations related to software.
-
-The foremost online resource is TESS run by USPTO. Before using
-TESS, please browse the documentation links from
-link:http://www.uspto.gov/trademarks/index.jsp[USPTO trademark home].
-
-Other resources which allow cheap searches of their databases exist but are often
-ephemeral. Review the link:https://issues.apache.org/jira/browse/PODLINGNAMESEARCH[records]
-for the state of this art.
-
-==== Evidence Of Use On The World Wide Web
-
-Registration of trademark is not required. Rights may also be obtained by use of a mark in commerce.
-
-Use a variety of web search engines (for example, link:http://www.bing.com[bing], link:http://www.google.com[google]
-and link:http://search.yahoo.com[yahoo]) to survey usage on the world wide web.
--The results returned by a search for the name itself may provide evidence of well known usages of the term.
--The results returned by searching for the name and _software_ may provide evidence of existing use in trade. You may also want to search for the name and key functionality the software provides
-and name and _open source_
diff --git a/pages/guides/participation.ad b/pages/guides/participation.ad
deleted file mode 100644
index e555906..0000000
--- a/pages/guides/participation.ad
+++ /dev/null
@@ -1,119 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Guide to Participation
-Apache Incubator PMC
-2002-10-16
-:jbake-type: pmcGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-This document is descriptive, not normative. It aims to help those who are new
-to the Incubator learn its ways and netiquette.
-
-== General Netiquette
-
-The usual advice applies. If you are not familiar with the way mailing lists
-work at Apache, read link:http://jakarta.apache.org/site/mail.html[this].
-
-Please ensure that your mail client is correctly configured. In particular, post only plain
-text emails to these lists. Apache spam filters may reject HTML emails.
-
-The incubator is a public meeting place with a diverse and ever-changing community.
-Creating social bonds and establishing a reputation is important. Please be polite,
-courteous and diplomatic.
-
-When in doubt - ask on link:lists.html#general+at+incubator.apache.org[general.AT.incubator.apache.org].
-
-== Ways To Participate
-=== On The General Mailing List
-
-The *general.AT.incubator.apache.org* is an public list with open subscription.
-All are encouraged to subscribe, read and post their opinions in the usual way.
-
-Anyone can by their words influence the decision-making process and may vote on
-link:http://www.apache.org/foundation/voting.html[VOTE threads].
-However (as is usual) only the votes of those on the
-link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[Incubator PMC] are binding.
-
-=== As A User
-
-A link:http://www.apache.org/foundation/how-it-works.html#users[user]
-is anyone who uses our software. Most Apache projects have active user
-communities who are willing to provide help. This is not always the case with incubator podlings.
-
-To gain the maximum benefit from any immature project (as many podlings are),
-adopt an active attitude.
-Read link:http://jakarta.apache.org/site/contributing.html[On Contributing]
-and
-link:http://jakarta.apache.org/site/understandingopensource.html[Understanding Open Source].
-Become a link:#developer[developer] (in the Apache meaning of the term).
-
-=== As A Developer
-
-At Apache, a link:http://www.apache.org/foundation/how-it-works.html#developers[developer]
-(aka contributor) is anyone who actively helps to develop our software. This includes more than just coders
-and documenters. For example, anyone who joins in discussions on the mailing lists or answers questions
-from users is also a developer.
-
-Apache is a link:http://www.apache.org/foundation/how-it-works.html#decision-making[_DO_-ocracy]. The first step along the road leading to
-link:#committer[committership] is to become a developer. For more information start with
-link:http://www.apache.org/foundation/how-it-works.html[How Apache Works]
-and the link:http://www.apache.org/dev/[developer documentation].
-
-=== As A Committer
-
-A link:/incubation/Roles_and_Responsibilities.html#Committers[committer]
-is anyone with write access to the source repository. Election to committership in the Incubator
-works a little differently from the process that is usual elsewhere at Apache.
-
-Once a podling has been bootstrapped, link:#developer[developers] are nominated
-and election to committer happens in the link:ppmc.html#Voting+in+a+new+committer[usual way].
-
-When a proposal is just a link:/incubation/Roles_and_Responsibilities.html#Candidate[candidate],
-there are two possible approaches (for those interested in committership).
-
-The proposal typically
-link:proposal.html#template-initial-committers[contains] a list of initial committers.
-When a podling is bootstrapped, this list is used by the mentors to set up initial accounts.
-So, one way to become a committer for a podling is to be listed on the proposal as an initial
-committer.
-
-The right way to express interest is by a post to the list with a brief introduction.
-Piling onto a proposal (by adding your own name as an initial committer) is impolite.
-Read
-link:http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/%3cC73C6D24-3216-4EB4-8846-1218B38CC594@gbiv.com%3e[this thread].
-
-A podling needs to learn how to recruit new committers from its developers. So,
-another way is to show up on the list and start helping with the development.
-This path will help the podling more than adding your name to the list of initial committers.
-
-=== As A Mentor
-
-Anyone with knowledge of open source or Apache can participate as a informal mentor
-for a podling. Development is open and anyone with an interest is encouraged to
-subscribe.
-
-Eligibility to act as a formal
-link:/incubation/Roles_and_Responsibilities.html#Mentor[Mentor] is
-link:/incubation/Incubation_Policy#Mentor[limited]. The best way for an eligible
-individual to become a Mentor is to post a note introducing him- or herself
-and volunteering their services to *general.AT.incubator.apache.org*
-during the development of the link:proposal.html[proposal].
-
-=== On The Incubator PMC
-
-Apache Members are encouraged to join the
-link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[Incubator PMC]. Post a note to the Incubator PMC private list.
-
-Those who aren't members may be elected in the usual Apache way. These elections are held on private lists.
diff --git a/pages/guides/pmc.ad b/pages/guides/pmc.ad
deleted file mode 100644
index bf06132..0000000
--- a/pages/guides/pmc.ad
+++ /dev/null
@@ -1,34 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= The Incubator PMC
-Apache Incubator PMC
-2002-10-16
-:jbake-type: pmcGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Joining the IPMC
-
-Joining the IPMC is just like any other PMC, once enough merit and community involvement is performed, PMC members will take notice and may vote on you to join.
-
-Foundation members may willingly join the IPMC at any time, to express desire send an email to *private.AT.incubator.apache.org*
-
-== Members
-
-A full list of IPMC members can be found at link:http://home.apache.org/phonebook.html?ctte=incubator[home.apache.org/phonebook.html?ctte=incubator]
-
-== Roles and Responsibilities of the IPMC
-
-The full list of expectations of an IPMC member can be found on the
-link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[Roles & Responsibilities Page]
diff --git a/pages/guides/podling_sourcecontrol.ad b/pages/guides/podling_sourcecontrol.ad
deleted file mode 100644
index ee13fdf..0000000
--- a/pages/guides/podling_sourcecontrol.ad
+++ /dev/null
@@ -1,118 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Podling Source Control
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Set Up Podling Source Repository
-
-The most important responsibility for mentors is to set up the
-podling source repository. Podlings can choose between svn and
-git for source control. For git, podlings may use repositories hosted at Apache, or within GitHub in the Apache organization.
-
-=== Set up GIT Repository
-
-Requests for new git repos are done via link:https://reporeq.apache.org/[reporeq.apache.org].
-This service will initialize a new repository, setup github mirrors and enable integrations for that repository.
-
-Historically, the Foundation's policy
-is to grant access to git repositories broadly to the incubator group,
-not narrowly podling-by-podling. So, once the repository
-exists, incubator group members gain access without further work. Once
-the podling graduates, a dedicated ldap group will be created to manage
-access and only those members will be given access.
-
-=== Set Up SVN Repository
-
-If the podling chooses svn, you must create the
-repository and give read/write access to the repository
-to all the committers for the podling. This involves requesting
-new committer accounts and granting access to mentors and existing
-Apache committers.
-
-Setting up a podling subversion repository has two steps: Creating the SVN space
-and configuring the authorization (in both svn and git).
-
-Create the workspace in svn. This requires commit access to the
-incubator svn repository. Podlings are given their own subdirectory
-of the incubator svn repository. To create the podling subdirectory,
-the mentor executes the svn command to create a remote directory: `svn mkdir https://svn.apache.org/repos/asf/incubator/{podling}`
-
-Create the workspace authorization in asf-authorization-template.
-This requires commit access to `infrastructure-puppet` to modify the file
-`https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob;f=modules/subversion_server/files/authorization/asf-authorization-template`.
-Please follow the procedures in the link:https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo[infrastructure puppet workflow] document.
-
-Edit the file to add the podling repository in alphabetical order, e.g.
-
-[source]
-====
-{podling}={mentor1},{mentor2}
-====
-
-In the section listing all the projects (again in alphabetical order)
-add the podling directory and permissions, to enable the podling for its
-eventual website:
-
-[source]
-====
-[/incubator/{podling}]
-@{podling} = rw
-...
-====
-
-This is a convenient time to add link:#Authorize+Committers[authorization] for committers
-who have accounts.
-
-link:#who-auth-karma[Authorization] karma is restricted. If no Mentor
-has this karma then post an email to IPMC private list requesting that this
-is actioned.
-
-== Authorize Committers
-
-The process to add committers to the podling depends on whether
-the new committer is already an Apache committer and whether
-the new committer is in the list of original committers:
-
-- The committer is in the list of original committers in the
-podling proposal to the incubator and is not already an Apache
-committer:
-** Ask developers to send their ICLA to secretary@apache.org according to
-link:http://apache.org/licenses/#submitting[standard procedure.]
-Note that ICLA forms must be signed, either by hand or by digital signature.
-** Developers should choose an Apache id that is not already listed
-link:http://people.apache.org/committer-index.html[here.]
-** Developers should enter their preferred Apache id on the ICLA
-and enter the podling name in the "notify" field of the ICLA.
-- The committer is in the list of original committers in the
-podling proposal to the incubator and is already an Apache committer, only
-link:#who-auth-karma[incubator authorization] is required.
-- The committer was voted by the PPMC and approved by the incubator PMC:
-
-Perform one of the above procedures depending on whether the
-committer is already an Apache committer on another project.
-
-== Incubator Access Authorization
-
-Special karma is required to authorize incubator access for committers.
-This karma is limited to:
-
-- IPMC Members
-- Secretary
-- Infrastructure
-
-IPMC Members should use link:https://whimsy.apache.org/roster/committee/incubator[Whimsy's Roster Tool] to add existing commiters.
\ No newline at end of file
diff --git a/pages/guides/ppmc.ad b/pages/guides/ppmc.ad
deleted file mode 100644
index 1a43e9c..0000000
--- a/pages/guides/ppmc.ad
+++ /dev/null
@@ -1,256 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Podling Project Management Committee
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Podling Project Management Committee (PPMC)
-The Podling Project Management Committee (PPMC) helps a
-Podling learn how to govern itself. It works like a PMC but
-reports to the Incubator PMC instead of to the ASF Board.
-Initially, it is composed of the Podling's mentors and initial
-committers. The PPMC is directly responsible for the oversight
-of the podling and it also decides who to add as a PPMC member.
-
-For general information about PMCs, see the link:http://www.apache.org/dev/pmc.html[PMC FAQ].
-
-== Private Mail List
-
-A private mail list, named private@*project*, lets the PPMC discuss confidential topics.
-*Most communication should be on the Podling's dev list!*
-The private list is used only for confidential discussions that
-should not be made public, such as the suitability of a
-particular individual to become a committer or a member of the
-PPMC. See the ASF *How it Works* section titled
-link:http://www.apache.org/foundation/how-it-works.html#confidential[Balancing confidentiality and public discussion].
-
-The mentors should verify that all PPMC members are actually
-subscribed to the private list. Mailing list moderators can
-request the list of subscribers using ezmlm commands, and any
-subscriber can send a "ping - please reply" message to check
-who is actually "listening" to the PPMC list.
-
-*Don't mix private and public lists in posts!*
-
-- Don't post to both the dev and private lists. Each member of the PPMC should be on the dev list, so posting to dev is sufficient.
-- Likewise, don't post to both the Incubator general and Incubator private lists. Each member of the Incubator PMC is on the Incubator general list, so posting to general is sufficient.
-
-[NOTE]
-====
-The lists used to be named *project*-ppmc or
-pmc@*tlp*, so you may see those names referenced in other ASF
-documentation or in the mail list archives. It was
-link:/official/mailing-lists.html#july-2005[resolved]
-that these lists should be named *private*
-to make it clear that they should be used for confidential discussion,
-not as a general purpose way to contact (P)PMC members.
-====
-
-== Podling Status Reports
-On a regular basis, reports from each incubating project are
-aggregated and sent to the ASF Board. Watch the Incubator general
-mail list for when these become due.
-
-The Incubator reports to the ASF Board monthly and includes
-status for a subset of the incubating projects. Currently new
-Podlings report to the Incubator monthly for the first three
-months, then quarterly thereafter. The link:../report-groups.txt[reporting schedule] is generated from podlings.xml.
-
-The PPMC does not have to fill out the report itself; the PPMC
-is just responsible for making sure that it gets filled out. In
-fact, it is better to discuss the report on the dev list and ask
-Podling developers to contribute to it. If Mentors disagree with
-the posted report, they should say so; otherwise, the Incubator
-PMC will assume that it speaks for the community.
-
-Please add the following items:
-- Project name and one-line summary.
-- Date of entry to the Incubator.
-- Top three items to resolve before graduation.
-
-Here are the points to be addressed:
-- Is there anything that the Incubator PMC or ASF Board specifically needs to address?
-- Are there any legal, infrastructure, cross-project or personal issues that need to be addressed? (Are there any stumbling blocks that impede the podling?)
-- Check that the project's Incubation link:../projects/index.html[Status] file up to date. (Also provide the URL.)
-- What has been done (releases, milestones, etc.) since the last report?
-- What are the plans and expectations for the next period?
-- Are there any recommendations for how incubation could run more smoothly for you?
-- etc. (your own thoughts on what is important would be helpful!)
-
-It is required for mentors to sign off on podling reports.
-- Mentors must sign off on the podling report. If there is no mentor sign off, the report from that podling will not be accepted and they will be moved to monthly, expected to report next month.
-
-Podling reports get added to the Incubator wiki
-- All podling reports must be added to the link:http://wiki.apache.org/incubator/[Incubator wiki]
-- Follow the instructions in your monthly reminder, and post on the <Month><Year> page, with the provided template
-
-== Project Status Page
-In addition to the quarterly status reports, each Podling has a
-page on the Incubator web site that tracks the status
-(see the link:http://incubator.apache.org/projects/index.html[complete list] for examples). Instructions for updating the status page
-are in the link:website.html[Incubator web site guide]
-under link:website.html#Edit+your+project+status+page[Edit your project status report].
-
-This is one of the primary link:mentor.html#Overview[sources] of information about your podling's
-status to the Incubator PMC and to the general public. Be sure to
-keep it updated as your podling progresses!
-
-== Maintaining Podling Roster
-Podling rosters are maintained in Whimsy. Going forward, the content in *projects/$podling.xml*
-is considered deprecated.
-
-link:https://whimsy.apache.org/roster/ppmc/[Click Here to access the Whimsy Roster Tool for PPMCs]
-
-== Adding new committers
-
-Adding new committers is one of the most important functions
-of any PMC, and Incubator podlings are no different.
-
-There are no ASF wide rules on how to decide when to make someone
-a committer, podlings need to agree an approach that works for them.
-Some ASF projects have a high bar requiring significant contributions before
-someone is considered, other projects grant it more freely to anyone
-who shows interest in contributing. Some projects use formal [DISCUSS] and
-[VOTE] threads on the private mailing list, others use a more lazy consensus
-approach. For more information see,
-link:http://www.apache.org/foundation/glossary.html#CommitAccess[commit access] and the ASF *How it Works* document, which explains
-link:http://www.apache.org/foundation/how-it-works.html#meritocracy[ meritocracy] and
- link:http://www.apache.org/foundation/how-it-works.html#roles[ roles].
-
-The podling Incubator reports should document any new committers
-added since the last report.
-
-Once the decision has been made the proposer offers committership
-to the nominee. If the nominee accepts the responsibility of being
-a committer for the project, the nominee formally becomes an
-Apache committer.
-
-The proposer then asks an Incubator PMC member (typically one of
-the mentors) to follow the
-link:http://www.apache.org/dev/pmc.html#newcommitter[documented]
-link:http://www.apache.org/dev/pmc.html#SVNaccess[procedures]
-to complete the process. If the nominee is already an Apache
-committer on another project, the Incubator PMC member simply
-link:http://www.apache.org/dev/pmc.html#SVNaccess[updates]
-the SVN authorization settings to include the nominee as a committer
-on the podling.
-
-The proposer then directs the new committer to the
-link:http://www.apache.org/dev/[Apache developer's pages],
-to the
-link:http://incubator.apache.org/[Apache Incubator site]
-and to the Incubator
-link:committer.html[Committers Guide] for important additional
-information.
-
-For projects which wish to have all
-committers also be PPMC members, the "Voting in a new PPMC member"
-guide below should then be followed, noting that if desired it
-is possible to run a joint committership and PPMC vote, providing
-that the guidance for both is followed.
-
-== Voting in a new PPMC member
-It should be a goal of a podling to have all committers participate
-in the PPMC. The PPMC should take an active role in watching
-committers develop into community participants, identify those who
-are participating at a community level, not just a technical one,
-and approach them with an offer of PPMC membership.
-
-Any member of the PPMC can propose a new member of the PPMC. The
-proposal should be discussed in private on the PPMC private alias,
-with a subject line of [DISCUSS] Joe Bob PPMC membership. If there
-is consensus that the proposed member is suitable, then there should
-be a formal vote in the PPMC private alias, with the subject line of
-[VOTE] Joe Bob PPMC membership.
-
-If the vote is successful, the proposer
-should send a message to the PPMC private alias, with
-the subject line of [VOTE][RESULT] Joe Bob PPMC membership. The
-message id of the [VOTE][RESULT] message should be preserved for
-notifying the Incubator PMC.
-The nominating PPMC member should send a message to
-the IPMC (link:mailto:private@incubator.apache.org[private@incubator.apache.org]) with a reference to
-the vote result's message id of the following form:
-
-[source]
---
-To: private at incubator.apache.org
-CC: private at PODLING.incubator.apache.org
-Subject: [NOTICE] Joe Bob for PODLING PPMC
-Body:
-
-Joe Bob has been voted as a new member of the *PODLING* PPMC. the vote thread is at: *link to the vote thread*
---
-
-*It should noted that there is a grace period of 72 hours from when the
-above NOTICE is sent to the Incubator PMC to when the proposed member
-is formally invited. This is an important part of the overall
-process. Failure to do this can result in an embarassing situation
-for people involved.*
-
-In the email you send, replace *PODLING* with your podling's actual name, and replace Joe Bob with the prospect's actual name.
-
-After 72 hours, Joe Bob
-should be invited to join the PPMC, using a sample message like
-link:ppmc-offer.txt[this].
-
-Once the proposed member has accepted, the moderator for the
-PPMC mail alias will accept the new member's subscription request.
-
-The new member should be directed to
-link:ppmc.html[this page] for PPMC membership information.
-
-The nominating member should also update the PPMC membership
-section of the Podling's status file. For projects which choose to
-always make new committers also PPMC members, simply updating
-the committer list and ensuring that a statement such as
-"The PPMC consists of all the committers and mentors listed here"
-is generally sufficient.
-
-== Adding new mentors
-
-At times, it may be desirable to add a new mentor to a podling.
-Under all circumstances, a mentor must be an IPMC member.
-
-IPMC members are free to volunteer to be a mentor to a podling
-as they see fit. To do so, they should mail the podling stating
-their intentions. The podling should then decide if it wants to
-add the new mentor or not. If a decision has been reached to
-add the mentor, then all podling documentation should be updated
-to reflect the change (podlings.xml, projects/{podling}.xml) and
-the incubator be notified of the change as well.
-
-If a podling is in a position where they feel they need to add a new mentor,
-they may want to drop a mail on the general incubator mailing list to try
-to recruit a new mentor.
-
-== Removing a mentor
-
-Occasionally it may be necessary to remove a mentor who has been
-too busy to participate or who has gone silent. After discussing
-it with the PPMC you can have someone with access (another mentor)
-remove them via link:https://whimsy.apache.org/roster/ppmc/[Whimsy].
-An email will be generated by Whimsy so no email to the list is needed.
-
-== PPMC and Binding Votes
-
-The only time when a PPMC member's vote is binding is for the addition of
-new PPMC members and committers. Release votes are only binding to IPMC
-members.
-
-The binding status of a person's vote is not related to the mailing list
-that the vote is occurring on.
diff --git a/pages/guides/press-kit.ad b/pages/guides/press-kit.ad
deleted file mode 100644
index fc95d2a..0000000
--- a/pages/guides/press-kit.ad
+++ /dev/null
@@ -1,108 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Podling Press Kit
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Apache Incubator Graphics
-
-This page contains various graphical assets that are intended to be used by Apache Incubator podlings and their communities.
-The Apache Software Foundation owns all Apache-related trademarks, service marks, and graphic logos. You can read our link:http://www.apache.org/foundation/marks/[formal Trademark Policy] that addresses allowable uses and how to contact us for permissions.
-The Apache Incubator provides two main types of graphic:
-
-- Incubator Graphics - the official Apache Incubator logo
-- “Powered By” Apache Incubator Logos - to be used by Apache Incubator podlings
-
-Please note that each Apache podling provides and maintains their own official project logo on their homepage. The best place to ask for a copy of a project logo is on their dev@ mailing list.
-
-= Downloadable Graphics
-
-This section contains downloadable graphics of the Apache Incubator logo.
-
-REMINDER: all graphics/images/logos are trademarks of the ASF, and must not be used without appropriate attribution and permission from the ASF. Please see our formal Trademark Policy for more details. In particular, as a vendor-neutral public charity that provides independent governance to all Apache projects, you must use care when displaying the feather, and ensure it's clear that it's referring to the ASF as an independent organization.
-
-=== Official Incubator Logo
-
-This is the latest version of the Apache Incubator logo, as launched in March 2017. This logo is to be used on ALL podling pages during the incubation process.
-
-image:/images/incubator_feather_egg_logo.png[]
-
-link:/images/SVG/apache_incubator.svg[SVG] | link:/images/PDF/apache_incubator.pdf[PDF] | link:/images/EPS/apache_incubator_RGB.eps[EPS - RGB] | link:/images/EPS/apache_incubator_CMYK.eps[EPS - CMYK]
-
-=== Red-On-White Version of Logo
-
-The red-on-white version of the Apache Incubator Logo is
-
-image:/images/incubator_feather_egg_logo_red_crop.png[]
-
-link:/images/SVG/apache_incubator_red.svg[SVG] | link:/images/PDF/apache_incubator_red.pdf[PDF] | link:/images/EPS/apache_incubator_red_RGB.eps[EPS - RGB] | link:/images/EPS/apache_incubator_red_CMYK.eps[EPS - CMYK]
-
-=== Black-On-White Version of Logo
-
-The black-on-white version of the Apache Incubator Logo is
-
-image:/images/incubator_feather_egg_logo_wb_crop.png[]
-
-link:/images/SVG/apache_incubator_black.svg[SVG] | link:/images/PDF/apache_incubator_black.pdf[PDF] | link:/images/EPS/apache_incubator_black_RGB.eps[EPS - RGB] | link:/images/EPS/apache_incubator_black_CMYK.eps[EPS - CMYK]
-
-=== White-On-Black Version of Logo
-
-The white-on-black version of the Apache Incubator Logo is
-
-image:/images/incubator_feather_egg_logo_bw_crop.png[]
-
-link:/images/SVG/apache_incubator_white.svg[SVG] | link:/images/PDF/apache_incubator_white.pdf[PDF] | link:/images/EPS/apache_incubator_white_RGB.eps[EPS - RGB] | link:/images/EPS/apache_incubator_white_CMYK.eps[EPS - CMYK]
-
-== "Powered By" Apache Incubator Podling Logos
-
-Inspired by the ASF’s “Powered by Apache” logo [LINK], the “Apache Incubator Podling” logo was created to maintain the unique identity of each Apache podling whilst undergoing development in the Apache Incubator. All Apache podlings and their communities are encouraged to proudly display “Apache Incubator Podling” assets on their Websites, documentation, marketing materials, etc.
-Guidelines for the appropriate use of the “Powered By Apache” logos include:
-
-- The standalone “Powered By” Apache Incubator and “Apache Incubator Podling” circular banded logos may be used standalone with just the Apache Incubator logomark (denoting general use of an Apache Incubator podling) or in combination with an official Apache podling logo;
-- The official podling logo may not be altered in any way other than removing/separating the name(s) where applicable as approved by the associated Podling Project Management Committee (PPMC);
-- The appropriate trademark symbol(s), such as ® or ™, associated with the podling's logo --if applicable-- must be included in the logo;
-- The “Powered By” logo's circular band format, font, and color must not be altered in any way;
-- The logo and/or its contents must not be rotated, animated, distorted, or otherwise altered, nor should it be used as a graphic element, background, or pattern;
-- The logo and/or its contents must not be translated or localized, nor should it have versioning numbers or other unauthorized words added to it;
-- The preferred background color for the logo is white, however, the logo may appear on colored, black, or image/photographic backgrounds providing the logo's legibility is not compromised;
-- The logo may be sized and produced in multiple file formats as required by the Podling Project Management Committee, with a preferred minimum size of 80 pixels high in Web/online applications (where possible) to ensure legibility;
-- The logo may not, under any circumstances, be incorporated with a third party's company name, product name, or logo(s), or adopt marks and/or logos that are confusingly similar to or imply improper association with The Apache Software Foundation;
-- Third parties and programs are not allowed to use official Apache project or podling logos and/or create alternate logos or identifying marks relating to any Apache project without written permission from the associated Podling Project Management Committee and/or ASF Brand Management.
-- We have a link:https://www.apache.org/foundation/marks/faq/#poweredby[trademark use policy for the "Powered By" phrase]
-
-In addition, official Apache Project pages and documentation on apache.org must utilize the appropriate trademark symbols on the respective Project logo, along with the following footnote: "Apache, Apache [PODLING NAME], and the Apache [PODLING NAME] logo are registered trademarks or trademarks of The Apache Software Foundation in the U.S. and/or other countries."
-
-=== Template and Usage
-
-==== Standalone "Powered By" Apache Incubator Logo
-image:/images/incubator_ring_logo.png[height=200]
-
-==== Per-Project Powered By Logos
-
-Logos for individual podlings, such as the ones below, are available in jpg, psd, and eps format. They can be retrieved by requesting:
-
-image:/images/incubator_power_ring.jpg[height=200]
-image:/images/incubator_ring_airflow.jpg[height=200]
-
-For example, creating the “Apache Incubator Podling” logo for Apache Airflow can be accomplished by retrieving the Airflow logo from link:http://airflow.incubator.apache.org/_images/pin_large.png[http://airflow.incubator.apache.org/_images/pin_large.png]
-If you are unable to find the logo you are looking for, please contact the podling’s mailing list.
-
-==== Template For the Creation of Powered By Logos
-image:/images/template_airflow.jpg[height=200]
-image:/images/template_hawq.jpg[height=200]
-image:/images/template_spot.jpg[height=200]
-
diff --git a/pages/guides/proposal.ad b/pages/guides/proposal.ad
deleted file mode 100644
index 96bcd97..0000000
--- a/pages/guides/proposal.ad
+++ /dev/null
@@ -1,899 +0,0 @@
-= A Guide To Proposal Creation
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-:jbake-type: proposalGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-This document provides guidance only. Policy is found link:/incubation/Incubation_Policy.html[here].
-
-== Abstract
-
-This document is descriptive, not normative. It describes approaches to
-drawing up a proposal for submission. It is not an inflexible standard but
-represents a consensus condensed from discussions on the
-link:lists.html#general+at+incubator.apache.org[general mailing list].
-
-=== Background
-link:entry.html[Entry] to the incubator is a democratic
-link:/incubation/Process_Description[process] decided by a vote.
-The proposal is the document upon which the
-link:/incubation/Roles_and_Responsibilities.html#Sponsor[Sponsor] votes.
-So, though it's neither necessary nor sufficient to have a good proposal,
-a good proposal increases the chances of a positive result.
-
-Proposals to the incubator generate attention. The
-link:lists.html#general+at+incubator.apache.org[general mailing list] is open,
-widely discussed and well indexed. It is a very public space.
-The proposal is a manifesto.
-A good proposal should target also the wider audience and not just the
-link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[jury].
-Use this time to engage and inform potential
-link:participation.html#developer[developers]
-and link:participation.html#user[users].
-
-Much of the information will be reused in the
-link:sites.html[Podling website].
-A good proposal should shape the future evolution of the project
-but each proposal captures only the particular instant at birth.
-It is understood that projects change and evolve.
-
-=== Continuous Improvement
-The link:/incubation/Process_Description.html[Incubation process] is continuously evolving.
-Hopefully this will help newer projects to be even stronger and more successful then existing ones.
-One consequence of this approach is that precedence is not always a reliable guide.
-Another is that documentation may be a little outdated.
-
-=== Help Wanted!
-Help to improve the system by posting a patch for this document to the
-link:https://issues.apache.org/jira/browse/INCUBATOR[incubator section]
-of link:http://issues.apache.org/jira[JIRA]
-or a comment to the link:lists.html#general+at+incubator.apache.org[general list].
-
-== Formulating A Proposal
-=== Preparation
-
-Start with research. The link:entry.html[incubator entry guide] is a good place to start.
-Read the link:http://www.apache.org[Apache]
-link:http://www.apache.org/foundation[documentation].
-
-link:lists.html[Subscribe] to the
-link:lists.html#general+at+incubator.apache.org[general mailing list].
-Spend some time reviewing the
-link:http://mail-archives.apache.org/mod_mbox/incubator-general/[mailing lists archives].
-The mailing lists are the canonical form of
-link:http://www.apache.org/foundation/how-it-works.html#communication[communication]
-and link:http://www.apache.org/foundation/how-it-works.html#decision-making[decision making]
-at Apache. Documentation is an attempt to codify the consensus formed and record the decisions taken on list.
-
-Before starting on the formal proposal, recruit a
-link:/incubation/Roles_and_Responsibilities.html#Champion[Champion]. The Champion understands
-Apache and should be able to help navigate the process.
-
-Review link:http://wiki.apache.org/incubator/[recent proposals] and how they have been
-link:http://mail-archives.apache.org/mod_mbox/incubator-general/[received].
-
-The incoming community needs to work together before presenting this
-proposal to the incubator. Think about and discuss future goals and the reasons for coming to Apache.
-Feel free to ask questions link:lists.html#general+at+incubator.apache.org[on list].
-
-Every proposal is different. There will always be some aspects which do not seem
-to fit well into the link:#proposal-template[template].
-Use the template as a guide but do not feel constrained
-by it. Adopt what works and change what doesn't. That's fine - in fact, it's expected.
-
-Be sure to add your proposal to link:http://wiki.apache.org/incubator/ProjectProposals[this list].
-
-=== Project Name
-While it is important to ensure a
-link:graduation.html#notes-names[suitable project name]
-and product names sometime during incubation, it is not necessary
-to do this prior to entering incubation. In fact, be careful not to
-disrupt your proposal and entry process.
-
-=== Presentation
-
-Once the preparatory work is done, the proposal should be presented to the
-incubator. Post the proposal in plain text in an email to the
-link:lists.html#general+at+incubator.apache.org[mailing list]
-whose subject is prefixed with _[PROPOSAL]_. You should be clear
-that you want to discuss your proposal when submitting this mail.
-
-If there is interest in the proposal, expect a lively debate to begin.
-Approval is an open and
-link:http://www.apache.org/foundation/voting.html[democratic]
-link:entry.html#understanding[process].
-Discussion is an important part of opinion formation. A proposal
-will require development if it is to gain the maximum level of support from the
-link:/whoweare.html[electorate].
-
-=== Developing The Proposal
-
-Expect to work on improving the proposal on the list after presenting it.
-No preparation can cover every question. It is usual for unexpected
-and novel questions to be asked. This is often a sign of interest. So
-(though it may sometimes feel like an ordeal)
-approach these questions as a positive opportunity.
-
-The link:http://wiki.apache.org/incubator/[wiki] is a good
-development tool. Consider creating a wiki page containing the evolving proposal
-content. Those who are interested should add themselves
-to the watch list for the page so they can receive change notifications.
-
-Developing the proposal on the wiki allows easy collaboration. This has disadvantages
-as well as advantages. The wiki is just a tool to assist the easy development of the
-final proposal (the one that will be voted upon). Not every change improves a proposal
-and there is no requirement that every change is accepted by the proposers. Note that the incubator
-asks all participants to abide by appropriate link:participation.html[netiquette].
-
-Effective management of this development is an exercise in community building.
-The wiki is not an appropriate forum for debating changes. Discussion should be
-gently moved onto the appropriate
-link:lists.html#general+at+incubator.apache.org[mailing list].
-
-=== The Vote
-
-When the proposal seems finished and some sort of consensus has emerged, the
-proposal should be put to a vote.
-
-If the wiki is used to develop the proposal, please ensure that the wiki
-matches the final proposal then add a notice to the wiki that development of
-the document is now complete:
-
-[literal]
-----
-/!\ '''FINAL''' /!\
-
-This proposal is now complete and has been submitted for a VOTE.
-----
-
-Embed the final proposal text or a link to a specific revision number of the
-wiki proposal page in the email which kicks off the VOTE thread. If a change
-is required after the vote has been called then the vote must be cancelled,
-the change made, and the vote restarted. Alternatively, Mentors will advise
-on how to make the change once the proposal has been accepted if this is
-appropriate. Do not edit the wiki proposal unless you cancel the vote
-thread.
-
-== Proposal Template
-
-The aim of presenting a template with examples and comments is educational.
-Proposals are not required to adopt this format.
-Every proposal is different. There may be sections which don't seem to be
-useful. It's fine to miss them out and to add new ones that the proposal seems
-to need. Best practice evolves. Innovation is acceptable.
-
-The format is less important than the content.
-
-Each section is broken down into a commentary/explanation and examples, in the following format
-
-[literal]
---
-== SECTION ==
-Commentary:
-
- Commentary is thus.
-
-Examples:
-
- Examples are thus.
---
-
-The proposal template can be copy and pasted into the Incubator Wiki to speed up creation. Please remove excess commentary and examples sections
-
-[literal]
---
-== Abstract ==
-Commentary:
-
- A short descriptive summary of the
- project. A short paragraph, ideally one sentence in length.
-
- The abstract should be suitable for reuse in
-
-the board resolution used to create the official project upon graduation,
- as the first paragraph on the podling web site and in the DOAP document.
-
-Examples:
-
- Geronimo will be a J2EE
-compliant container.
-
- Heraldry will develop technologies around the emerging user-centric
- identity space.
-
- Yoko will be a CORBA server.
-
-
-= Proposal =
-
-Commentary:
-
- A lengthier
-description of the proposal. Should be reasonably declarative. More discursive material should be included in the rationale (or other later sections).
-
-Example:
-
- XAP is to provide an XML-based
-declarative framework for building,
- deploying and maintaining rich, interactive, Ajax-powered web
- applications. A basic principal of XAP is to leverage existing Ajax
-
-
-=== Background
-===
-Commentary:
-
- Provides context for those unfamiliar with the problem space and history.
-
- Explain terms whose meanings may be misunderstood (for example, where there is not a single widely
-adopted definition).
-
- This content should be capable of being safely ignored by domain experts. It should probably find an eventual home on the Podling website.
-
-Example (Heraldry):
-
- To
-provide some background, the Higgins Project is being actively
- developed within Eclipse and is a framework that will enable users
- and enterprises to integrate identity, profile, and
-relationship
- information across multiple systems. Using context providers,
- existing and new systems such as directories, collaboration spaces
- ...
-
-=== Rationale ===
-Commentary:
-
-
-Explains why this project needs to exist and why should it be adopted by Apache. This is the right place for discursive material.
-
-Example (Beehive):
-
- There is a strong need for a cohesive,
-easy-to-use programming model
- for building J2EE applications. Developers new to Java are forced to
- learn a myriad of APIs just to build simple applications; advanced
- J2EE developers are
-forced to write tedious plumbing code; and tools
- authors are limited in what they can do to simplify the experience
- due to the underlying complexity.
-
-=== Initial Goals ===
-Commentary:
- A
-complex proposal (involving multiple existing code bases, for example) may cause concerns about its practicality. A good way to address these concerns is to create a plan that demonstrates the
-proposal is feasible and has been carefully thought through.
-
- Many projects will not need this section.
-
-
-Example (Heraldry):
-
- * Expansion of Yadis and OpenID libraries into additional
-languages
- beyond the existing Python, Ruby, Perl, and PHP libraries
- * OpenID authentication specification revision to fix known security
- considerations, investigate compatibility with the
-DIX IETF
- proposal, describe Yadis integration, and allow either an URL or
- XRI be used as the End User's Identifier
-
-=== Current Status ===
-Commentary:
- This section (and the contained
-topics) describes the candidate's current status and development practices. This should be an honest assessment balancing these against Apache's principles and development ideals.
-
- For some
-proposals, this is a chance to demonstrate understanding of the issues that will need to addressed before graduation. For others, this is a chance to highlight the close match with Apache that already
-exists. Proposals without an initial code base should just simply state that.
-
- Some proposals name this section criteria (though the term is a little misleading).
-
- *
-'''Meritocracy:'''
-
-Commentary:
-
- Apache is a meritocracy.
-
- Once a developer has submitted enough good patches then it should be natural that they are elected to committer. It should be
-natural that active committers are elected to the project management committee (PMC).
-
- This process of renewal is vital to the long term health of Apache projects. This is the right place to
-demonstrate that this process is understood by the proposers.
-
-
-Example (OFBiz):
-
- OFBiz was originally created by David E. Jones and Andy Zeneski in
- May 2001. The project now has committers
-and users from around the
- world. The newer committers of the project joined in subsequent
- years by initially submitting patches, then having commit privileges
- for some of the applications,
-and then privileges over a larger
- range of applications...
-
-Example (Beehive):
-
- We plan to do everything possible to encourage an environment that
- supports a meritocracy. One of the
-lessons that the XMLBeans
- committers have learned is that meritocracies don't just evolve
- from good intentions; they require actively asking the community
- for help, listing/specifying the
-work that needs to be done, and
- keeping track of and encouraging members of the community who make
- any contributions...
-
- * '''Community:'''
-Commentary:
-
- Apache is interested only
-in communities.
-
- Candidates should start with a community and have the potential to grow and renew this community by attracting new users and developers. Explain how the proposal fits this
-vision.
-
-Example (Beehive):
-
- BEA has been building a community around predecessors to this
- framework for the last two years. There is currently an active
- newsgroup that should help us
-build a new community at Apache.
-
-Example (WebWork2):
-
- The WebWork 2 community has a strong following with active mailing
- lists and forums.
-
-Example (WADI):
-
- The need for a full service
-clustering and caching component in the
- open source is tremendous as its use can be applied in many areas,
- thus providing the potential for an incredibly large community.
-
- * '''Core
-Developers:'''
-
-Apache is composed of individuals.
-
-It is useful to provide a brief introduction to the developers on the initial committers list. This is best done here (and not in that
-section). This section may be used to discuss the diversity of the core development team.
-
-
-Example (ServiceMix)
- The core developers are a diverse group of developers many of which
- are
-already very experienced open source developers. There is at
- least one Apache Member together with a number of other existing
- Apache Committers along with folks from various companies.
-
-http://servicemix.org/Team
-
-Example (WADI)
- WADI was founded by Jules Gosnell in 2004, it now has a strong base
- of developers from Geronimo, Castor, OpenEJB, Mojo, Jetty,
- ActiveCluster,
-ActiveMQ, and ServiceMix.
-
- * '''Alignment:'''
-
-Describe why Apache is a good match for the proposal. An opportunity to highlight links with Apache projects and development
-philosophy.
-
-
-Example (Beehive):
- The initial code base is targeted to run within Tomcat, but the goal
- is to allow the framework to run on any compliant Servlet or J2EE
- container. The Web
-services component, based on JSR-181, will
- leverage Axis. The NetUI component builds on top of Struts. The
- underlying Controls component framework uses Velocity. There are
- other projects that
-we will need to work with, such as the Portals
- and Maven projects.
-
-'''Known Risks'''
-
-An exercise in self-knowledge. Risks don't mean that a project is unacceptable. If they are
-recognized and noted then they can be addressed during incubation.
-
- * '''Orphaned products''':
-
-A public commitment to future development.
-
-Recruiting a diverse development community and
-strong user base takes time. Apache needs to be confident that the proposers are committed.
-
-
-Example (Yoko):
- The contributors are leading vendors in this space. There is no risk
- of any of
-the usual warning signs of orphaned or abandoned code.
-
-
-
-Example (Ivy):
-Due to its small number of committers, there is a risk of being orphaned.
-The main knowledge of the codebase is still
-mainly owned by Xavier Hanin.
-Even if Xavier has no plan to leave Ivy development, this is a problem we
-are aware of and know that need to be worked on so that the project become
-less dependent on
-an individual.
-
-
-
-Example (Tika):
-There are a number of projects at various stages of maturity that implement
-a subset of the proposed features in Tika. For many potential users the
-existing
-tools are already enough, which reduces the demand for a more
-generic toolkit. This can also be seen in the slow progress of this proposal
-over the past year.
-
-However, once the project gets
-started we can quickly reach the feature level
-of existing tools based on seed code from sources mentioned below. After that
-we believe to be able to quickly grow the developer and user communities
-based
-on the benefits of a generic toolkit over custom alternatives.
-
- * '''Inexperience with Open Source:'''
-
-
-If the proposal is based on an existing open source project with a history
-of open development, then highlight this here.
-
-If the list of initial committers contains developers with strong open source backgrounds then highlight this here.
-
-Inexperience with open source
-is one reason why closed projects choose to apply for incubation. Apache has developed over the years a store of experience in this area. Successfully opening up a closed project means an investment
-of energy by all involved. It requires a willingness to learn and to give back to the community. If the proposal is based around a closed project and comes with very little understand of the open
-source space, then acknowledge this and demonstrate a willingness to learn.
-
-
-Example (Cayenne):
- Cayenne was started as an open source project in 2001 and has
- remained so for 5
-years.
-
-
-
-Example (Beehive):
- Many of the committers have experience working on open source
- projects. Five of them have experience as committers on other
- Apache projects.
-
-
-
-Example
-(Ivy):
- While distributed under an open source license, access to Ivy was initially
- limited with no public access to the issue tracking system or svn
- repository. While things have changed
-since then - the svn repository is
- publicly accessible, a JIRA instance has been setup since june 2005, many
- new features are first discussed on the forum or JIRA - experience with a
- true
-open source development model is currently limited.
- However, Maarten has already a good experience with true open development
- process, and bring his experience to the project.
-
-
-
-Example
-(River):
- The initial committers have varying degrees of experience with open source
- projects. All have been involved with source code that has been released under
- an open source license, but
-there is limited experience developing code with an
- open source development process. We do not, however, expect any difficulty in
- executing under normal meritocracy rules.
-
- * '''Length of Incubation:'''
-Commentary:
- This section describes how long the project is expected to be in incubation before it's graducation as a top level project and the reaosns for that.
-
- This shows the project has thought about the steps required to graduate and that there are not any unrealistic expectations.
-
- * '''Homogenous
-Developers:'''
-
-Healthy projects need a mix of developers. Open development requires a commitment to encouraging a diverse mixture. This includes the art of working as part of a geographically
-scattered group in a distributed environment.
-
-Starting with a homogenous community does not prevent a project from entering incubation. But for those projects, a commitment to creating a diverse
-mix of developers is useful. Those projects who already have a mix should take this chance to highlight that they do.
-
-
-Example (Beehive):
- The current list of committers includes developers from
-several
- different companies plus many independent volunteers. The committers
- are geographically distributed across the U.S., Europe, and Asia.
- They are experienced with working in a
-distributed environment.
-
-
-
-Example (River)
- Since the Jini Technology Starter Kit has been mainly developed to date by Sun
- Microsystems, the vast majority of initial committers to the
-project are from
- Sun. Over the years, Sun has received bug fixes and enhancements from other
- developers which have been incorporated into the code. Our plan is to work with
- these other
-developers and add them as committers as we progress. There are
- three other initial committers (non Sun): Bill Venners, Dan Creswell, and Mark
- Brouwer. Bill is the lead of the Service UI API
-work, Dan has been involved with
- much Jini-based development, including an implementation of the JavaSpaces
- service called Blitz <http://www.dancres.org/blitz/>, and Mark is veteran of
- much
-Jini-based development, including commercial work at Virgil
- <http://www.virgil.nl> as well as leading the open source Cheiron
- <http://www.cheiron.org> project.
-
-
-
-Example (Ivy):
- With only
-two core developers, at least they are not homogenous! Xavier and
- Maarten knew each other only due to their common interest in Ivy.
-
- * '''Reliance on Salaried Developers''':
-
-A project
-dominated by salaried developers who are interested in the code only whilst they are employed to do so risks its long term health.
-
-Apache is about people, not corporations. We hope that developers
-continue to be involved with Apache no matter who their current employer happens to be.
-
-This is a right place to indicate the initial balance between salaried developers and volunteers. It's also
-good to talk about the level of commitment of the developers.
-
-
-Example (OpenJPA):
- Most of the developers are paid by their employer to contribute to
- this project, but given the anticipation
-from the Java community for
- the a JPA implementation and the committers' sense of ownership for
- the code, the project would continue without issue if no salaried
- developers contributed to
-the project.
-
-
-
-Example (River):
- It is expected that Jini development will occur on both salaried time and on
- volunteer time, after hours. While there is reliance on salaried developers
-
-(currently from Sun, but it's expected that other company's salaried developers
- will also be involved), the Jini Community is very active and things should
- balance out fairly quickly. In the
-meantime, Sun will support the project in the
- future by dedicating 'work time' to Jini, so that there is a smooth transition.
-
-
-
-Example (Wicket):
- None of the developers rely on Wicket for
-consulting work, though two -
- Martijn and Eelco - are writing Wicket In Action (publisher Manning) in
- their spare time. Most of the developers use Wicket for their day jobs,
- some for
-multiple projects, and will do so for a considerable while as
- their companies (specifically Topicus, Cemron and Teachscape) choose
- Wicket as their development framework of choice.
-
- *
-'''Relationships with Other Apache Products:'''
-
-Apache projects should be open to collaboration with other open source projects both within Apache and without. Candidates should be willing to
-reach outside their own little bubbles.
-
-This is a an opportunity to talk about existing links. It is also the right place to talk about potential future links and plans.
-
-Apache allows different
-projects to have competing or overlapping goals. However, this should mean friendly competition between codebases and cordial cooperation between communities.
-
-It is not always obvious whether a
-candidate is a direct competitor to an existing project, an indirect competitor (same problem space, different ecological niche) or are just peers with some overlap. In the case of indirect
-competition, it is important that the abstract describes accurately the niche. Direct competitors should expect to be asked to summarize architectural differences and similarities to existing
-projects.
-
-
-Example (OpenJPA):
- Open JPA will likely be used by Geronimo, requires some Apache
- products (regexp, commons collections, commons lang, commons pool),
- and supports Apache
-commons logging.
-
-Example (River)
- Currently the only tie to Apache projects is the starter kit's use
- of the Ant build tool. There are potential future ties (http server,
- database backend,
-etc)that will be explored.
-
- * '''A Excessive Fascination with the Apache Brand:'''
-
-Concerns have been raised in the past that some projects appear to have been proposed just to generate
-positive publicity for the proposers. This is the right place to convince everyone that is not the case.
-
-This is also the right place to build bridges with the community after past misdemeanors
-(for example, if any of those associated with the proposal have - in the past - sort to associate themselves with the Apache brand in factually incorrect ways) and promise good conduct for the
-future.
-
-
-Example (CeltiXfire):
- While we expect the Apache brand may help attract more contributors,
- our interests in starting this project is based on the factors
- mentioned in the
-Rationale section. However, we will be sensitive to
- inadvertent abuse of the Apache brand and will work with the
- Incubator PMC and the PRC to ensure the brand policies are
-respected.
-
-
-
-Example (Wicket):
- The ASF has a strong brand, and that brand is in itself attractive.
- However, the developers of Wicket have been quite successful on
- their own and could
-continue on that path with no problems at all.
- We are interested in joining the ASF in order to increase our
- contacts and visibility in the open source world. Furthermore, we
- have been
-enthusiastic users of Apache from the earliest hour
- (remember JServ anyone?), and feel honored at getting the
- opportunity to join the club.
-
-
-
-Example (OpenJPA):
- We think that Open JPA is
-something that will benefit from wide
- collaboration, being able to build a community of developers and
- committers that outlive the founders, and that will be embraced
- by other Apache efforts,
-such as the Geronimo project.
-
-'''Documentation'''
-
-References to further reading material.
-
-
-Examples (Heraldry):
- [1] Information on Yadis can be found at:
- http://yadis.org
-
-http://www.openidenabled.com
-
- [2] Information on OpenID can be found at:
- http://www.openid.net
- http://www.openidenabled.com
-
- The mailing list for both OpenID and Yadis is located
-at:
- http://lists.danga.com/mailman/listinfo/yadis
- ...
-
-'''Initial Source'''
-
-Describes the origin of the proposed code base. If the initial code arrives from more than one source,
-this is the right place to outline the different histories.
-
-If there is no initial source, note that here.
-
-
-Example (Heraldry):
- OpenID has been in development since the summer of 2005. It
-currently
- has an active community (over 15 million enabled accounts) and
- libraries in a variety of languages. Additionally it is supported by
- LiveJournal.com and is continuing to gain
-traction in the Open
- Source Community.
-
- Yadis has been in development since late 2005 and the specification
- has not changed since early 2006. Like OpenID, it has libraries in
- various
-languages and there is a large overlap between the two
- communities. The specification is...
-
-
-'''Source and Intellectual Property Submission Plan'''
-
-Complex proposals (typically
-involving multiple code bases) may find it useful to draw up an initial plan for the submission of the code here. Demonstrate that the proposal is practical.
-
-
-Example (Heraldry):
- * The OpenID
-specification and content on openid.net from Brad
- Fitzpatrick of Six Apart, Ltd. and David Recordon of VeriSign,
- Inc.
- * The domains openid.net and yadis.org from Brad Fitzpatrick of
-
-Six Apart, Ltd. and Johannes Ernst of NetMesh, Inc.
- * OpenID libraries in Python, Ruby, Perl, PHP, and C# from JanRain,
- Inc.
- ...
- * Yadis conformance test suite from NetMesh and
-VeriSign, Inc.
-
- We will also be soliciting contributions of further plugins and
- patches to various pieces of Open Source software.
-
-'''External Dependencies''':
-
- External
-dependencies for the initial source is important. Only some external dependencies are allowed by Apache policy. These restrictions are (to some extent) initially relaxed for projects under
-incubation.
-
- If the initial source has dependencies which would prevent graduation then this is the right place to indicate how these issues will be resolved.
-
-
- Example (CeltiXfire):
- The
-dependencies all have Apache compatible licenses. These include
- BSD, CDDL, CPL, MPL and MIT licensed dependencies.
-
-'''Cryptography'''
-
-If the proposal involves cryptographic code either
-directly or indirectly, Apache needs to know so that the relevant paperwork can be obtained.
-
-'''Required Resources''':
-
- * '''Mailing lists:'''
-
- The minimum required lists are
-private@{podling}.incubator.apache.org (for confidential PPMC discussions) and dev@{podling}.incubator.apache.org lists. Note that projects historically misnamed the private list pmc. To avoid
-confusion over appropriate usage it was resolved that all such lists be renamed.
-
- If this project is new to open source, then starting with these minimum lists is the best approach. The initial
-focus needs to be on recruiting new developers. Early adopters are potential developers. As momentum is gained, the community may decide to create commit and user lists as they become necessary.
-
-
-Existing open source projects moving to Apache will probably want to adopt the same mailing list set up here as they have already. However, there is no necessity that all mailing lists be created
-during bootstrapping. New mailing lists can be added by a VOTE on the Podling list.
-
- By default, commits for {podling} will be emailed to commits@{podling}.incubator.apache.org. It is therefore
-recommended that this naming convention is adopted.
-
- Mailing list options are described at greater length elsewhere.
-
-
- Example (Beehive):
- * private@beehive.incubator.apache.org (with
-moderated subscriptions)
- * dev@beehive.incubator.apache.org
- * commits@beehive.incubator.apache.org
-
-
- * '''Subversion Directory:'''
-
- It is conventional to use all lower case,
-dash-separated (-) directory names. The directory should be within the incubator directory space (http://svn.apache.org/repos/asf/incubator).
-
-
- Example (OpenJPA):
-
-https://svn.apache.org/repos/asf/incubator/openjpa
-
-
-
- * '''Git Repositories:'''
- It is conventional to use all lower case, dash-separated (-) repository names. The repository should be
-prefixed with incubator and later renamed assuming the project is promoted to a TLP.
-
-
- Example (Blur):
-
-https://git-wip-us.apache.org/repos/asf/incubator-blur.git
-
-
- * '''Issue Tracking:'''
-
- Apache runs JIRA and Bugzilla. Choose one. Indicate the name by which project should be known in the
-issue tracking system.
-
-
- Example (OpenJPA):
- JIRA Open-JPA (OPEN-JPA)
-
-
- * '''Other Resources:'''
-
- Describe here any other special infrastructure requirements necessary for the
-proposal. Note that the infrastructure team usually requires a compelling argument before new services are allowed on core hardware. Most proposals should not require this section.
-
- Most standard
-resources not covered above (such as continuous integration) should be added after bootstrapping. The infrastructure documentation explains the process.
-
-
-'''Initial Committers'''
-
-List of
-committers (stating name and an email address) used to bootstrap the community. Mark each which has submitted a contributor license agreement (CLA). Existing committers should use their apache.org
-email address (since they require only appropriate karma). Others should use the email address that is (or will be) on the CLA. That makes it easy to match CLAs with proposed committers to the
-project.
-
-It is a good idea to submit CLAs at the same time as the proposal. Nothing is lost by having a CLA on file at Apache but processing may take some time.
-
-Note this and this. Consider
-creating a separate section where interested developers can express an interest (and possibly leave a brief introduction) or ask them to post to the general list.
-
-
-Example (OpenJPA):
- Abe White
-(awhite at bea dot com)
- Marc Prud'hommeaux (mprudhom at bea dot com)
- Patrick Linskey (plinskey at bea dot com)
- ...
- Geir Magnusson Jr (geirm at apache dot org) *
- Craig Russell (clr at
-apache dot org) *
-
-'''Sponsors'''
-
-Little bit of a controversial subject. Committers at Apache are individuals and work here on their own behalf. They are judged on their merits not their
-affiliations. However, in the spirit of full disclosure, it is useful for any current affiliations which may effect the perceived independence of the initial committers to be listed openly at the
-start.
-
-For example, those in salaried positions whose job is to work on the project should list their affiliation. Having this list helps to judge how much diversity exists in the initial list and
-so how much work there is to do.
-
-This is best done in a separate section away from the committers list.
-
-Only the affiliations of committers on the initial bootstrap list are relevant. These
-committers have not been added by the usual meritocratic process. It is strongly recommended that the once a project is bootstrapped, developers are judged by their contributions and not by their
-background. This list should not be maintained after the bootstrap has been completed.
-
- * '''Champion:'''
- The Champion is a person already associated with Apache who leads the proposal
-process. It is common - but not necessary - for the Champion to also be proposed as a Mentor.
-
- A Champion should be found while the proposal is still being formulated. Their role is to help
-formulate the proposal and work with you to resolve comments and questions put forth by the IPMC while reviewing the proposal.
-
- * '''Nominated Mentors:'''
-
-Lists eligible (and willing)
-individuals nominated as Mentors [definition] for the candidate.
-
-Three Mentors gives a quorum and allows a Podling more autonomy from the Incubator PMC, so the current consensus is that three
-Mentors is a good number. Any experienced Apache community member can provide informal mentorship anyway, what's important is to make sure the podling has enough regularly available mentors to
-progress smoothly. There is no restriction on the number of mentors, formal or informal, a Podling may have.
-
-
- * '''Sponsoring Entity''':
- The Sponsor is the organizational unit within
-Apache taking responsibility for this proposal. The sponsoring entity can be:
-
- - the Apache Board
- - the Incubator
- - another Apache project
- The PMC for the appropriate project will decide
-whether to sponsor (by a vote). Unless there are strong links to an existing Apache project, it is recommended that the proposal asks that the Incubator for sponsorship.
-
- Note that the final
-destination within the Apache organizational structure will be decided upon graduation.
-
---
diff --git a/pages/guides/releasemanagement.ad b/pages/guides/releasemanagement.ad
deleted file mode 100644
index d5fd530..0000000
--- a/pages/guides/releasemanagement.ad
+++ /dev/null
@@ -1,49 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Release Management
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== What goes into a release
-
-A podling should begin to familiarize itself with ASF policies for releases. Those policies can be found at link:http://www.apache.org/dev/#releases[http://www.apache.org/dev/#releases].
-
-It is well understood that one of the goals of incubation is to help a podling understand how to
-build link:http://www.apache.org/dev/#releases[ASF compliant releases]. This is why its
-mandatory to have at least 3 +1 votes from
-link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[IPMC members]
-review the releases (this should include your link:/incubation/Roles_and_Responsibilities.html#Mentor[mentors] but is not mandatory)
-for accuracy in compliance with the ASF and link:/incubation/Incubation_Policy.html#Releases[Incubator policies].
-The podling community, of course, needs to be fully engaged in review process as well. Anybody reviewing
-the releases will provide the release manager and IPMC members with information about what is wrong
-with the release. The severity of the issues and whether they are blocking or not may be discussed
-but the ultimate guidance on where podling releases may get additional flexibility belongs to the mentors and IPMC members.
-
-== Podling Constraints
-
-The link:/incubation/Incubation_Policy.html#Releases[Incubator policies] apply two additional constraints to podlings for their releases. They are repeated here for clarity only.
-- Release artifacts must include #incubating# in the final file name
-- Release artifacts must include a link:/guides/branding.html#disclaimers[disclaimer] as noted
-
-In order for a podling to receive full permission from the IPMC to execute the release, the release
-vote must be held on the link:/guides/lists.html#general+at+incubator.apache.org[incubator general list]
-and pass based on the link:http://apache.org/foundation/voting.html#ReleaseVotes[standard Package Release voting rules].
-Only Incubator PMC votes are binding, but all are encouraged to vote.
-
-The Incubator PMC expects the source releases to be staged on
-#https://dist.apache.org/repos/dist/dev/incubator/$podlingName# so that they can easily be moved
-to the release location via #svn mv#.
diff --git a/pages/guides/retirement.ad b/pages/guides/retirement.ad
deleted file mode 100644
index 98d8acb..0000000
--- a/pages/guides/retirement.ad
+++ /dev/null
@@ -1,105 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Guide to Retirement
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-The intent of this document is to help Mentors and other
-community members understand retirement, both as a
-concept and a process.
-
-== What is Retirement?
-
-A retired podling is one which has been closed down on the
-initiative of the PPMC or the IPMC for various reasons. It is
-no longer developed at the Apache Incubator and does not have
-any other duties.
-
-It's important to view this process as being the retirement of
-the podling community, not the code. It should not be implied
-that the code is not for use - just that it has no community.
-So long as the Incubator's copyright requirements are
-fulfilled by the podling prior to retirement, its source code
-will continue to be made available through version control.
-
-Retiring a podling is analogous to moving a top-level Apache
-project to the link:http://attic.apache.org[Attic],
-but podlings receive a lower level of ongoing support -- for
-example, podling websites are deleted outright rather than
-munged to indicate retired status.
-
-== Deciding to retire
-
-In the vast majority of cases, a podling decides to retire on
-its own and that decision is later formally ratified by the
-Incubator PMC; very rarely, the IPMC may act unilaterally.
-(This is deliberate mimicry of Board oversight of TLPs --
-the language and role titles change but in general the Board
-and the IMPC merely implement the wishes of the community.)
-
-Before the IPMC gets involved, a public discussion and
-community vote SHOULD be held on the podling's dev list. This
-ensures that all podling stakeholders are properly informed and
-have the opportunity to participate in the decision.
-
-The final decision to retire the podling takes the form of a
-vote by the IPMC on general@incubator.
-
-== Steps to retirement
-
-Once the IPMC vote to retire the podling has closed, a Mentor or other volunteer needs to perform the following steps.
-
-- Update #content/podlings.xml#:
-** Update podling status to "retired".
-** Add an "enddate" attribute set to the date that the IPMC vote concluded.
-** Remove the "reporting" element.
-** Add the "resolution" element. (Follow the example of other recently retired podlings.)
-- Update the podling's status page with a prominent message indicating when the podling retired: <p><span class="retired">The ${podling} podling retired on XXXX-XX-XX</span></p>.
-- Has the copyright checkbox of the podling's incubation
-status page been checked off? If not, try to resolve it.
-If it cannot be resolved, the podling's source code must
-be removed from version control.
-- Delete the podling's dist dir, so that its releases will no
-longer be mirrored:
-#svn remove https://dist.apache.org/repos/dist/release/incubator/${podling}#
-Any incubating releases will still be available via
-link:http://archive.apache.org/dist/incubator[archive.apache.org/dist/incubator].
-- Create a file RETIRED.txt at the top-level of each podling
-source repository. This should contain something like the following:
-** This podling has been retired, please see: http://incubator.apache.org/projects/index.html##{podling-name}
-- If the podling has a DOAP referenced in the link:https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/projects.xml[projects.xml] file used for generating link:http://projects.apache.org[projects.apache.org], remove the entry.
-- Open a "task" INFRA JIRA ticket entitled "Retire the ${podling} Incubator podling". Open sub-tickets using "Create Sub-Task" as applicable:
-** Close ${podling} mailing lists
-** Make ${podling} version control read-only
-** Move ${podling} JIRA to "retired" and set read-only
-** Make ${podling} wiki read-only
-** Turn off ${podling} automatic builds
-** Update ${podling} Incubator SVN
-*** Add entries to asf-mailer.conf and send mail to cvs at incubator.apache.org
-*** Remove entries from asf-authorization - this makes the directory rw to the Incubator PMC.
-- After Infra modifies the website SVN permissions, disable
-the podling website by installing an `.htaccess` like this
-----
-RedirectMatch Permanent ^(/.*)?$ http://incubator.apache.org/projects/{podling}.html
-----
-file at the root of the podling website dir which consists
-of only a redirect to the podling status page.
-- When all steps towards retirement are done, announce completeness on general@incubator.
-- Indicate that the podling is closed down in the next board report.
-
-The user accounts of the projects committers do not need
-to be removed.
diff --git a/pages/guides/sites.ad b/pages/guides/sites.ad
deleted file mode 100644
index 05d2feb..0000000
--- a/pages/guides/sites.ad
+++ /dev/null
@@ -1,112 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Podling Websites
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-Podlings need to build a community in Apache in order to be accepted
-as part of the Apache Software Foundation. One of the tools used to build
-a community is the web site.
-
-== Podling Website Requirements
-
-Podlings are, by definition, not yet fully accepted as part of the
-Apache Software Foundation. Therefore, they are subject to additional
-constraints on their websites. These policies MUST be adhered to
-before Graduation is considered unless prior approval is obtained from
-the Incubator PMC.
-
-- The published site for each podling must conform to the guidelines in link:/guides/branding.html[Podling Branding/Publicity].
-- Podlings should review link:https://www.apache.org/foundation/marks/linking[Corporate Recognition Best Practices], link:https://www.apache.org/foundation/marks/resources[Apache trademark information], and must aim to be in compliance with link:https://www.apache.org/foundation/marks/pmcs[Apache Project Website Branding Policy]
-- The sources for every podling site sources should be maintained in the podling's site SVN or git directory
-- The published site for each podling should conform to this URL space: #http://podlingname.incubator.apache.org/#
-- The staging site (if using CMS) for each podling should conform to this URL space: #http://podlingname.staging.apache.org/#
-- Every podling should maintain an incubation status file under: #http://incubator.apache.org/projects/podlingname.html#
-- Eventual extra incubation documents should be filed under: #http://incubator.apache.org/projects/podlingname/**#
-
-== Creating the Podling Website
-=== Creating A Good Podling Site
-
-Apache Project Web Sites typically include several standard pages.
-Each page is formatted with a navigation bar on the left and a project
-standard header that includes the Incubator graphic.
-
-The Web Site can be established during incubation, and migrated
-after incubation to a permanent place in the TLP home.
-
-- Project Home Page: the primary entry point to the site; contains project description, news, invitation to join the project.
-- License Page: link to the Apache License 2.0
-- Downloads: many projects in incubation will release code, and this page describes them and has links to the download pages that redirect to Apache Mirror sites.
-- Documentation: this page describes the project documentation, including javadoc for Java projects; guides, tutorials, and links to external documentation.
-- Committers: a list of current committers on the project.
-- Mailing Lists: there are several mailing lists that the community might be interested in, and this page contains mailto: links that allow easy subscription (and unsubscription) to any of them.
-- FAQ: frequently asked questions are answered here.
-- Road Map: if the project has a vision of future community or development activities, the road map is published here.
-- Source Code: links to the browsable source repository and git or svn commands to check out the sources.
-- Coding Standards: the coding standards for submitted code by the community, along with a description of how strict the project intends to be.
-- Issue Tracking: links to the JIRA or other issue tracking tool, possibly including frequently used filters for issue lists.
-- Dependencies: other projects that this project depends on.
-- favicon: the project's icon in a format suitable for a browser's address bar. If absent, an Apache Feather will be displayed.
-
-=== Web Site Generation Tool
-
-The choice of tool used to generate the web site is left to
-the podling. If you already have a tool that you are comfortable
-with, you can continue to use it. If you do not, consider using
-the Jekyll based link:http://www.apache.org/dev/cmsref.html[Apache website template].
-
-Regardless of which tool you use, the web site should be maintained
-in the svn/git repository, and include the site generation tool as a binary
-file. This simplifies the process of site generation and enables changes
-to the site to be made by any committer. The generated site should also
-be checked into svn/git. This allows the generated site to be relocated
-to any part of the Apache site after incubation is complete.
-
-Since the site is independent of the code, it should exist high in
-the svn/git repository, e.g. parallel to the trunk of the source tree.
-
-=== Publishing Your Website
-
-Managing a podling's website is now the same as a top-level project. Review the link:http://www.apache.org/dev/project-site.html[Infra Documentation on Project Websites]
-
-=== Using A Wiki To Create Documentation
-
-Podlings may use a wiki to create documentation (including the website) providing that follow the
-link:http://cwiki.apache.org/[guidelines]. In particular, care must be taken to
-ensure that access to the wiki used to create documentation that may be included in the project
-release is restricted to only those with filed link:http://www.apache.org/licenses/[individual CLAs]. The PPMC MUST review all changes and ensure that trust is not abused.
-
-=== Web Site Transition
-
-Projects may arrive with existing web sites outside Apache. Contributing as much
-documentation as possible to the project from these sites is strongly encouraged.
-Offshore sites related to projects are fine but official web sites for Apache
-projects should be hosted by Apache.
-
-Some projects elect to maintain previous releases outside Apache. In this case, the existing site
-is typically retained as a hub for this maintenance work. Otherwise, sites should link
-or redirect to the official Apache site.
-
-Apache may accept donations of domains related to projects moving here.
-Infrastructure will then arrange for renewal of the domains and redirection
-of traffic the official site. Ask infrastructure for more details.
-
-Apache needs to deal with all commercial entities equitably. Linking to
-useful information on commercial sites is fine but unfair discrimination between
-commercial sites is not. Most Apache projects find it better to simply link only
-to relevant articles on commercial sites rather than having to vet every request
-for links to commercial activity.
diff --git a/pages/guides/sql_reference.md b/pages/guides/sql_reference.md
index a0bb172..fae7822 100644
--- a/pages/guides/sql_reference.md
+++ b/pages/guides/sql_reference.md
@@ -1,6 +1,6 @@
title=Apache Doris SQL Reference
date=2018-09-28
-type=proposalGuide
+type=Guide
status=published
imagesdir=/images/
~~~~~~
diff --git a/pages/guides/transferring.ad b/pages/guides/transferring.ad
deleted file mode 100644
index 6ac02b6..0000000
--- a/pages/guides/transferring.ad
+++ /dev/null
@@ -1,234 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Transferring Resources out of the Incubator
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-== Life After Graduation
-
-Once a project has been established by the board, or a sub-project consumed by a TLP, this guide should be followed to migrate the podling from the Incubator to their own TLP.
-
-=== Handover
-
-This is the transfer of virtual resources from the care of
-the link:/policy/roles_and_responsibilities.html#incubator_project_management_committee_ipmc[IPMC]
-to the care of either the new or existing top
-level project taking charge of the graduating community.
-
-==== Graduating as Subproject
-
-This is the simple case. The
-link:/policy/roles_and_responsibilities.html#chair_of_the_incubator_pmc[IPMC Chair] and the Chair of the project accepting the
-graduating community organize the handover between
-themselves.
-
-==== Graduating as New Top Level Project
-
-When graduating to a new project, the process is more
-complex. Creating a new project requires a
-link:http://www.apache.org/foundation/board/calendar.html[resolution]
-to be passed by the link:http://www.apache.org/foundation/board/[Board].
-Usually once this happens, the secretary will
-inform the new chair.
-Occasionally, this will be missed: if more than 72
-hours has passed since the Board meeting, it may be
-worth pinging the board to request confirmation.
-
-The link:#tlp-resolution[resolution] will appoint a Chair for the new
-project. The Chair will also be appointed an
-link:http://www.apache.org/foundation/[Officer]
-of the Apache Software Foundation. This allows them
-access to official resources of the foundation as well
-as granting power to act on behalf of Apache.
-
-Once appointed, the new Chair needs to:
-
-- Subscribe to the *board* mailing list
-- Ensure that they have been added to
-link:https://people.apache.org/phonebook.html?service=pmc-chairs[the PMC chairs group (pmc-chairs) in LDAP].
-The ASF Secretary should do this without any action on the part
-of the new chair. As with above, if it has not happened within
-72 hours of the resolution passing, contact the secretary to remind them.
-- Check out the link:https://svn.apache.org/repos/private/foundation/officers[*foundation/officers*] folder from the private repository.
-Users with member or pmc-chairs karma can do this.
-- Add yourself to the #foundation/officers/affiliations.txt# and the #foundation/officers/irs-disclosures.txt* files with the appropriate information.
-- Add your details to the foundation web site Officer list at link:http://www.apache.org/foundation/index.html[http://www.apache.org/foundation/index.html] (in SVN at link:https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/[https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/])
-- Review appropriate documentation:
-** link:http://www.apache.org/dev/pmc.html#chair[PMC Chair Duties]
-** PMC link:http://www.apache.org/dev/#pmc[documentation]
-** Jakarta link:http://wiki.apache.org/jakarta/RoleOfChair[Chair guide]
-** Incubator link:http://incubator.apache.org/guides/chair.html[Chair guide]
-** Reporting link:http://www.apache.org/foundation/board/calendar.html[calendar]
-- Work out a reporting schedule with the link:/incubation/Roles_and_Responsibilities.html#board[Board]. For
-the first three months after graduation this will
-be monthly. After that, the project should slot
-into a quarterly reporting schedule. Now is a good time to remove
-the project from the Incubator reporting schedule.
-- Work with the link:http://www.apache.org/dev/index.html#infra[Apache Infrastructure team]
-to set up the top level project infrastructure. Setting up the TLP request can be done by anyone on the new PMC, and should be done via link:https://issues.apache.org/jira/servicedesk/customer/portal/1/create/10[Infra Service Desk]
-- Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
-There are 3 sections which need to be updated; see instructions in the file, otherwise update it in link:https://whimsy.apache.org/roster/[Whimsy's Roster Tool]
-You may need to get a member to help with this, such as your mentors.
-
-They should then be able to start assembling the new
-link:http://www.apache.org/foundation/how-it-works.html#structure[PMC].
-The starting membership is listed in the
-link:#tlp-resolution[resolution]. However, the Chair of the new project
-needs to ensure that private list is created and the
-membership subscribed.
-
-Members of the new PMC need to:
-- Subscribe to the private mailing list for the project, if they weren't already subscribed from their PPMC days
-- Review appropriate documentation:
-** Apache link:http://www.apache.org/dev/pmc.html[PMC Guide]
-** Related link:http://www.apache.org/dev/#pmc[documentation]
-
-Once all this is in place, resources can start to be
-handed over to the new project.
-
-Please continue to hang around the Incubator and help
-new podlings have an easier time than you did!
-
-=== First Steps Outside the Incubator
-
-Graduation is the first step in what is hopefully a long road.
-There are some issues which incubation may not cover.
-
-==== Transferring Resources
-
-When a project graduates, then the infrastructure
-resources (mailing lists, websites, source, etc.) need to
-be transferred from the Incubator to a project's new home.
-
-Although the below checklist is still generally useful, *the infrastructure process has been streamlined*, see
-link:http://www.apache.org/dev/infra-contact#requesting-graduation[requesting graduation]. You might also want to check JIRA checklist tickets for projects that graduated in the last month or two. This process is known as "TLP Parent Request"
-
-Checklist:
-
-- Update the Incubator status records
-** Like the rest of incubation, graduation is a process. Updating your status records as you progress will enable others to assist.
-** Update the podling link:#notes-status[status page]. All sections should now be filled in
-including *EXIT*. Take some
-time to read carefully since this page
-forms the final public record for
-graduation.
-** Update the Incubator link:http://incubator.apache.org/projects/index.html[status page] to denote the project as "graduating" when you commence,
-then as "graduated" when you are finished. The notes link:#unincubate[below] will assist.
-
-- Source
-** Git repositories will be renamed to drop the `incubator-` prefix, please ensure that developers change their remotes. After you've created the TLP request, request the rename.
-** SVN repositories will be moved from the incubator to other locations, if you need the move done please raise an infra ticket after the TLP Parent Request.
-** Post an announcement to the development list telling everyone that the repository is about to be moved
-** Post an announcement containing instructions for developers describing how to #svn switch# their workspaces
-** Update site, jenkins, wikis, *pom.xml* and other resources to point to the new repository location.
-
-- Websites
-** Since podlings receive standard domains, no changes are required
-** Once graduated, your website will automatically redirect to remove the *incubator* subdomain
-
-- Mailing lists
-** Mailing lists no longer need to get moved, since podlings are given standard domains.
-** If you are using *podling.incubator.apache.org* format email addresses, please
-** When using Maven: update *pom.xml* for
-the new mailing list address(es). Also update any
-documents on your website that show how to
-subscribe to the lists and/or find archives.
-** Check project-private mailing list membership. Mentors should be allowed to remain if they wish to do so. The subscriber list should otherwise match that on the resolution. See link:http://www.apache.org/dev/committers.html#mail-moderate[this] and the link:http://www.ezmlm.org/[EZMLM] "Moderator's and Administrator's Manual".
-** Update mail addresses including:
-*** confluence commit messages (see adminstration documentation)
-*** issue tracking messages (see administration documentation)
-*** The chair should have karma to perform these tasks.
-** Double-check that all of your lists have sufficient active link:http://www.apache.org/dev/committers.html#mailing-list-moderators[moderators].
-
-- Issue Tracking
-** Ask infra to move the podling to its own top level category in JIRA, if using JIRA
-
-- Distribution mirrors
-** Raise an infra ticket to create your dist area and move your Incubator dist area to the new location.
-
-==== Final Revision of Podling Incubation Records
-
-When a project has finished its graduation steps, then the incubator resources
-need to be updated to indicate that the project is no
-longer incubating. Here are a few of the items that need
-to be done:
-
-- Update the svn *incubator/trunk/content/projects/${project}.xml* file to show the project's status.
-
-- Update the podling summary metadata file, *incubator/trunk/content/podlings.xml* svn file. See the content/podlings.dtd and follow examples of other recent graduates. At the beginning of the process, add the "graduating" element.
-
-- When finished the graduation process, then:
-** Change the podling status to "graduated";
-** add the "enddate" attribute to document when the project graduated;
-** add the "resolution" element (see other project examples);
-** remove the "graduating" element.
-
-- After your project has finished reporting to the Incubator, then remove the "reporting" element from that *podlings.xml* file.
-- Ensure that other svn resources for your project have moved to your new home.
-- Review this whole graduation guide.
-
-*NOTE: Please edit this guide to add missing steps and clarifications.*
-
-==== New Responsibilities
-===== Oversight
-
-During the stay in the Incubator, the
-link:/policy/roles_and_responsibilities.html#incubator_project_management_committee_ipmc[Incubator PMC (IPMC)]
-was responsible to the
-link:/policy/roles_and_responsibilities.html#the_board[Board]
-for oversight. A graduated project must now take
-responsibility for its own oversight.
-
-A project needs to ensure that its code base is
-clean from an IP perspective. New committers need to
-recruited, educated and mentored. Quality releases
-need to be cut. Community spirit needs to be maintained
-and conflicts resolved positively. Board reports need
-to be accurate and prompt.
-
-Help is still available but the
-appropriate bodies (infrastructure, community, legal
-and so on) should now be approached directly.
-
-===== Security
-
-Each project needs to be able to manage security issues
-discovered in their code. By their nature, these issues
-need to be dealt with in private. These issues may either
-be dealt with on a separate security list or on the
-private list. Which list is suitable for security issues
-should be noted.
-
-Volunteers need to be found from the
-link:http://www.apache.org/foundation/how-it-works.html#structure[PMC]
-to work with the link:https://www.apache.org/security/committers.html[Apache security team] and act as
-first contacts on security matters. The new project
-should make contact with the team soon after graduation
-and not wait for the first issue to be raised.
-
-Projects should adopt a positive attitude towards
-security issues. It is easy to gain a poor reputation
-by mishandling of these issues. There are many people
-at Apache with considerable experience in this area
-so ask first.
-
-===== Stay In Touch
-
-Passing through the incubation process gives a very
-valuable perspective. Please help to improve the process
-by guiding new podlings and by developing improved policy
-and documentation on the link:lists.html#general+at+incubator.apache.org[general] list.
diff --git a/pages/guides/transitioning_asf.ad b/pages/guides/transitioning_asf.ad
deleted file mode 100644
index 11752c0..0000000
--- a/pages/guides/transitioning_asf.ad
+++ /dev/null
@@ -1,161 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Initial Code Import
-Apache Incubator PMC
-2002-10-16
-:jbake-type: guide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-For corporate contributions, the SGA or CCLA MUST be completed, submitted
-and received before the code is imported.
-
-For contributions composed of patches from individual contributors,
-it is safe to import the code once the major contributors (by volume)
-have completed ICLAs or SGAs.
-
-In either case, the code to be imported should be attached to a JIRA
-and then imported. It is recommended that the previous version
-control system is tagged so that the imported version is precisely known.
-
-A public record MUST be made of the code imported. If the import is not
-attached to JIRA then it MUST be committed to version control.
-
-=== Importing History
-
-The incoming code can either be committed as a snapshot or as a complete version
-control export including history (provided that the import is available in a format
-readable by subversion).
-Importing with history allows existing open source projects who want to maintain
-older versions at Apache to easily perform source diffs and so on. Import just the
-latest code allows a clean break to be made with the past. The choice is left to
-the community of the incoming project.
-
-The infrastructure team will perform the import including
-mapping IDs but it is an operation that requires skill, time and care. In this case,
-please ask the infrastructure team politely.
-
-If you are importing from a github repository, you'll need to add one of our infra staff members as an admin to perform a move.
-
-== Audit Cryptography
-
-Before the code base is committed into an Apache repository, the contribution
-link:http://www.apache.org/dev/crypto.html[MUST] be checked
-and any restricted cryptography reported appropriately. Read and follow
-link:http://www.apache.org/dev/crypto.html[this guide].
-
-== Initial Clean Up
-
-Once a JIRA has been created, the source should be cleaned up.
-
-- Ensure source files use the standard Apache boilerplates. This may mean replacing existing license headers. The tools in link:https://svn.apache.org/repos/private/committers/tools[private/committers/tools] and link:https://svn.apache.org/repos/private/committers/relicense[private/committers/relicense] may be useful.
-- Ensure that NOTICE and LICENSE documents are present and correct. Mentors should assist with this.
-- Add any required notices. Consider moving copyright attributions from source documents to the NOTICE. Read link:http://www.apache.org/legal/src-headers.html[Apache policy on headers].
-- Audit the source for any potential licensing issues. Any which are found should either resolved immediately (when required) or noted in the status document for later.
-
-
-It is recommended that the initial clean up be is started
-before the code is committed. It MUST be completed before any
-releases are cut.
-
-== Clean Up Best Practice
-
-It is recommended that version control is used to create a
-public record of the process. This will assist anyone
-auditing the code provenance (now or in the future) to
-easily perform due diligence without contacting the people
-who performed the clean up. The clean up process should
-therefore clearly document (using version control) the
-evolution of the IP licensing.
-
-Particular care needs to be taken with commit messages
-during clean up. The intended audience needs to include
-lawyers and code auditors. Members of the public need to be
-able to follow and understand the process from these
-messages alone.
-
-It is therefore recommended that the initial source is
-(after being expanded from the archive) checked in as is
-into a special directory (*${project}/trunk/import* is suggested). The original packaging, copyright statements
-and license notices should be preserved. A standard Apache
-LICENSE and appropriate NOTICE should be added at the top
-for the copyright for the collective work (see link:http://www.apache.org/legal/src-headers.html[policy]). Take particular care with this commit message. As with
-any patch that contains code which is not the original work
-of the committer, the JIRA url (for the artifact imported)
-needs to be included together with notes about the original
-copyright owner and any associated paperwork. The fact that
-this is a exact import including original headers should be
-noted to stop any queries about these foreign headers.
-
-The cleanup should then proceed in a number of commits. If
-the source provenance is complex, break the process up into
-a number of logical steps committing each in turn with a
-good message.
-
-In particular, take care when relocating copyright
-statements and license notices into the NOTICE in the root
-directory: consider moving each copyright owner individually
-so that it is easier to audit. (See link:http://www.apache.org/legal/src-headers.html#notice[policy].)
-
-Once a section of code has been cleaned up
-(and link:#repackaging[repackaged], if necessary) normal development can begin.
-
-== On Repackaging
-
-It is recommended - but not mandated - that source is repackaged
-under the Apache namespace. There is no need to use the incubator
-namespace. For example, Java source might be repackaged to
-*org.apache.foo.Bar* or a DTD to *http://podling.apache.org/foo/bar*.
-
-Existing open source projects moving to Apache may well need to consider
-carefully how they will approach this transition.
-
-== Update Documents
-
-Check the documentation for references to the old home of the project and update them
-with references to Apache.
-
-Read
-link:http://incubator.apache.org/guides/branding.html[Branding Guide].
-Ensure that appropriate disclaimers are added to the appropriate documentation.
-Consider adding a *DISCLAIMER* text document.
-
-=== Update Build
-
-If the project uses link:http://maven.apache.org[Apache Maven], the pom will
-need to be updated to reflect that the project is now at Apache. In particular:
-- Update *mailingLists*
-- Update *organization*
-- Update *url*
-- Update *issueManagement*
-- Check *licenses*
-- Update *scm*
-- Update *groupId*
-- Update *manifestEntries*. It is recommended that the
-standard Apache settings are used
-- Update *developers* to use apache IDs (when known)
-- Update *distributionManagement*
-- Consider specifying a link:http://maven.apache.org/pom.html#relocation[relocation]
-
-If the project uses link:http://ant.apache.org[Apache Ant], the build script
-will probably need to be updated. In particular:
-- Ensure any MANIFESTs generated refer to Apache. It is recommended that the standard Apache settings are used.
-- Check that *LICENSE*, *NOTICE* and - if appropriate - *DISCLAIMER* documents are copied into binary artifacts
-
-== Issue Tracking Transition
-
-Issues for Apache projects should be tracked on Apache hardware. Some projects arrive
-with existing issues tracking. So, in the end these need to be replaced (for new development
-at least) by the Apache issues tracker. Options need to be discussed publicly on list
-and a consensus reached about the best transition strategy.
diff --git a/pages/guides/tutorial.md b/pages/guides/tutorial.md
new file mode 100644
index 0000000..bd1bbeb
--- /dev/null
+++ b/pages/guides/tutorial.md
@@ -0,0 +1,706 @@
+Palo采用mysql协议进行通信，用户可通过mysql client或者JDBC连接到Palo集群。选择mysql client版本时建议采用5.1之后的版本，因为5.1之前不能支持长度超过16个字符的用户名。本文以mysql client为例，通过一个完整的流程向用户展示Palo的基本使用方法。
+
+
+# 基础使用指南
+
+## 1. 创建用户
+
+#### 1.1 Root用户登录与密码修改
+
+Palo内置root用户，密码默认为空，启动完Palo程序之后，可以通过root用户连接到Palo集群。
+假如mysql客户端和Palo FE程序部署在同一台机器，使用默认端口，下面命令即可登录Palo。
+```
+mysql -h 127.0.0.1 -P9030 -uroot
+```
+
+修改root密码
+```
+set password for 'root' = PASSWORD('root');
+```
+
+#### 1.2 创建cluster (可选，如果需要使用palo的多租户功能)
+如果需要使用多租户功能，则在部署的时候需要按照[安装文档](https://github.com/baidu/palo/blob/master/docs/admin_guide/install.md)3.2节中提示的方法添加be。在多租户模式下，用户以及相关的数据库都在cluster之下。修改完root用户密码之后，紧接着需要创建cluster，创建cluster时会为cluster创建一个superuser用户，创建cluster的命令如下:
+
+```
+CREATE CLUSTER example_cluster PROPERTIES("instance_num"="1") IDENTIFIED BY 'superuser';
+```
+上述命令创建了一个example_cluster的cluster，密码为superuser的superuser用户，properties中的instance_num表示这个cluster运行在一个BE节点之上。
+
+此时可使用root用户登录Palo，并进入example_cluster。
+```
+mysql -h 127.0.0.1 -P9030 -uroot -proot
+enter example_cluster;
+```
+
+#### 1.3 创建新用户
+
+如果使用多租户则按照1.3.1，没使用则按照1.3.2。
+
+##### 1.3.1 使用多租户
+
+进入到指定cluster之后，可以在里面创建新的用户。
+```
+create user 'test' identified by 'test';
+```
+
+后续登录时就可以通过下列连接命令登录到指定cluster
+```
+mysql -h FE_HOST -P QUERY_PORT -uUSERNAME@CLUSTER_NAME -pPASSWORD
+```
+- FE_HOST: 部署FE的机器。
+- QUERY_PORT: 在fe.conf中进行配置,默认配置为9030。
+- USERNAME: 用户名。
+- CLUSTER_NAME: 创建的cluster名称。
+- PASSWORD: 创建用户时指定的密码。
+
+使用root登录Palo集群，并进入example_cluster。
+```
+mysql -h 127.0.0.1 -P9030 -uroot@example_cluster -proot
+
+```
+当然，root账户依然可以采用先登录Palo集群，后enter到指定cluster的方式；而其他用户登录必须显示指名cluster的名称。
+
+使用superuser登录Palo集群，并进入example_cluster。
+
+```
+mysql -h 127.0.0.1 -P9030 -usuperuser@example_cluster -psuperuser
+```
+
+使用test登录Palo集群，并进入example_cluster。
+```
+mysql -h 127.0.0.1 -P9030 -utest@example_cluster -ptest
+
+##### 1.3.2 不使用多租户
+
+通过下面的命令创建一个普通用户。
+
+
+```
+create user 'test' identified by 'test';
+```
+
+
+也可以创建一个管理员superuser用户，指定密码的方式如1.1节描述。
+
+```
+create user 'test' superuser;
+```
+
+后续登录时就可以通过下列连接命令登录。
+```
+mysql -h FE_HOST -P QUERY_PORT -uUSERNAME -pPASSWORD
+```
+- FE_HOST: 部署FE的机器。
+- QUERY_PORT: 在fe.conf中进行配置,默认配置为9030。
+- USERNAME: 用户名。
+- PASSWORD: 创建用户时指定的密码。
+
+使用root登录Palo集群。
+```
+mysql -h 127.0.0.1 -P9030 -uroot -proot
+```
+
+使用test登录Palo集群。
+
+```
+mysql -h 127.0.0.1 -P9030 -utest -ptest
+```
+
+## 2 数据表的创建与数据导入
+
+#### 2.1 创建数据库
+
+Palo中只有root账户和superuser账户有权限建立数据库，使用root或superuser用户登录，建立example_db数据库:
+
+ CREATE DATABASE example_db;
+
+- 所有命令都可以使用'HELP your_command'查看到详细的中文帮助
+- 如果不清楚命令的全名，可以使用'help 命令某一字段' 进行模糊查询。
+ 如键入'HELP CREATE'，可以匹配到CREATE DATABASE, CREATE TABLE, CREATE USER三个命令
+
+数据库创建完成之后，可以通过show databases查看数据库信息。
+
+ mysql> show databases;
+ +--------------------+
+ | Database |
+ +--------------------+
+ | test |
+ | information_schema |
+ +--------------------+
+ 2 rows in set (0.00 sec)
+
+information_schema是为了兼容mysql协议而存在，实际中信息可能不是很准确，所以关于具体数据库的信息建议通过直接查询相应数据库而获得。
+
+#### 2.2 账户授权
+example_db创建完成之后，可以通过root账户或者superuser账户将example_db读写权限授权给test账户, 授权之后采用test账户登录就可以操作example_db数据库了。
+```
+grant all on example_db to test;
+```
+
+#### 2.3 建表
+
+使用CREATE TABLE命令建立一个表(Table)。更多详细参数可以查看:
+
+ HELP CREATE TABLE;
+
+首先切换数据库:
+
+ USE example_db;
+
+Palo支持支持单分区和复合分区两种建表方式。
+
+在复合分区中：
+
+- 第一级称为Partition，即分区。用户可以指定某一维度列作为分区列（当前只支持整型和时间类型的列），并指定每个分区的取值范围。
+
+- 第二级称为Distribution，即分桶。用户可以指定某几个维度列（或不指定，即所有KEY列）以及桶数对数据进行HASH分布。
+
+以下场景推荐使用复合分区
+
+- 有时间维度或类似带有有序值的维度：可以以这类维度列作为分区列。分区粒度可以根据导入频次、分区数据量等进行评估。
+- 历史数据删除需求：如有删除历史数据的需求（比如仅保留最近N 天的数据）。使用复合分区，可以通过删除历史分区来达到目的。也可以通过在指定分区内发送DELETE语句进行数据删除。
+- 解决数据倾斜问题：每个分区可以单独指定分桶数量。如按天分区，当每天的数据量差异很大时，可以通过指定分区的分桶数，合理划分不同分区的数据,分桶列建议选择区分度大的列。
+
+用户也可以不使用复合分区，即使用单分区。则数据只做HASH分布。
+
+下面以聚合模型为例，分别演示两种分区的建表语句。
+
+#### 单分区
+
+建立一个名字为table1的逻辑表。使用全hash分桶，分桶列为siteid，桶数为10。
+
+这个表的schema如下：
+
+- siteid：类型是INT（4字节）, 默认值为10
+- cidy_code：类型是SMALLINT（2字节）
+- username：类型是VARCHAR, 最大长度为32, 默认值为空字符串
+- pv：类型是BIGINT（8字节）, 默认值是0; 这是一个指标列, Palo内部会对指标列做聚合操作, 这个列的聚合方法是求和（SUM）
+
+建表语句如下:
+```
+CREATE TABLE table1
+(
+ siteid INT DEFAULT '10',
+ citycode SMALLINT,
+ username VARCHAR(32) DEFAULT '',
+ pv BIGINT SUM DEFAULT '0'
+)
+AGGREGATE KEY(siteid, citycode, username)
+DISTRIBUTED BY HASH(siteid) BUCKETS 10
+PROPERTIES("replication_num" = "1");
+```
+
+#### 复合分区
+
+建立一个名字为table2的逻辑表。
+
+这个表的 schema 如下：
+
+- event_day：类型是DATE，无默认值
+- siteid：类型是INT（4字节）, 默认值为10
+- cidy_code：类型是SMALLINT（2字节）
+- username：类型是VARCHAR, 最大长度为32, 默认值为空字符串
+- pv：类型是BIGINT（8字节）, 默认值是0; 这是一个指标列, Palo 内部会对指标列做聚合操作, 这个列的聚合方法是求和（SUM）
+
+我们使用event_day列作为分区列，建立3个分区: p1, p2, p3
+
+- p1：范围为 [最小值, 2017-06-30)
+- p2：范围为 [2017-06-30, 2017-07-31)
+- p3：范围为 [2017-07-31, 2017-08-31)
+
+每个分区使用siteid进行哈希分桶，桶数为10
+
+建表语句如下:
+```
+CREATE TABLE table2
+(
+ event_day DATE,
+ siteid INT DEFAULT '10',
+ citycode SMALLINT,
+ username VARCHAR(32) DEFAULT '',
+ pv BIGINT SUM DEFAULT '0'
+)
+AGGREGATE KEY(event_day, siteid, citycode, username)
+PARTITION BY RANGE(event_day)
+(
+ PARTITION p1 VALUES LESS THAN ('2017-06-30'),
+ PARTITION p2 VALUES LESS THAN ('2017-07-31'),
+ PARTITION p3 VALUES LESS THAN ('2017-08-31')
+)
+DISTRIBUTED BY HASH(siteid) BUCKETS 10
+PROPERTIES("replication_num" = "1");
+```
+表建完之后，可以查看example_db中表的信息:
+
+ mysql> show tables;
+ +----------------------+
+ | Tables_in_example_db |
+ +----------------------+
+ | table1 |
+ | table2 |
+ +----------------------+
+ 2 rows in set (0.01 sec)
+
+ mysql> desc table1;
+ +----------+-------------+------+-------+---------+-------+
+ | Field | Type | Null | Key | Default | Extra |
+ +----------+-------------+------+-------+---------+-------+
+ | siteid | int(11) | Yes | true | 10 | |
+ | citycode | smallint(6) | Yes | true | N/A | |
+ | username | varchar(32) | Yes | true | | |
+ | pv | bigint(20) | Yes | false | 0 | SUM |
+ +----------+-------------+------+-------+---------+-------+
+ 4 rows in set (0.00 sec)
+
+ mysql> desc table2;
+ +-----------+-------------+------+-------+---------+-------+
+ | Field | Type | Null | Key | Default | Extra |
+ +-----------+-------------+------+-------+---------+-------+
+ | event_day | date | Yes | true | N/A | |
+ | siteid | int(11) | Yes | true | 10 | |
+ | citycode | smallint(6) | Yes | true | N/A | |
+ | username | varchar(32) | Yes | true | | |
+ | pv | bigint(20) | Yes | false | 0 | SUM |
+ +-----------+-------------+------+-------+---------+-------+
+ 5 rows in set (0.00 sec)
+
+
+**注意事项**：
+
+- 上述表通过设置replication_num建的都是单副本的表，Palo建议用户采用默认的3副本设置,以保证高可用。
+- 可以对复合分区表动态的增删分区。详见'HELP ALTER TABLE'中 PARTITION相关部分。
+- 数据导入可以导入指定的partition。详见'HELP LOAD'。
+- 可以动态修改表的Schema。
+- 可以对Table增加上卷表（Rollup）以提高查询性能，这部分可以参见高级使用指南关于Rollup的描述。
+
+
+#### 2.4 导入数据
+
+Palo 支持两种数据导入方式：
+
+- 小批量导入：针对小批量数据的导入。详见'HELP MINI LOAD'
+- 批量导入：支持读取HDFS文件，部署不同broker可以读取不同版本HDFS数据。详见 'HELP LOAD'
+
+我们这里分别提供两种导入方式的操作示例，为快速完成导入建议使用方采用小批量导入进行数据导入的测试。
+
+#### 小批量导入
+
+小批量导入: 主要用于让用户可以不依赖HDFS，导入本地目录文件。
+
+小批量导入是Palo中唯一不使用mysql-client执行的命令，采用http协议完成通信。**小批量导入的端口是fe.conf中配置的http port。**
+
+示例1：以 "table1_20170707"为Label，使用本地文件table1_data导入table1表。
+
+curl --location-trusted -u test:test -T table1_data http://127.0.0.1:8030/api/example_db/table1/_load?label=table1_20170707
+
+本地table1_data以\t作为数据之间的分隔，具体内容如下：
+
+ 1 1 'jim' 2
+ 2 1 'grace' 2
+ 3 2 'tom' 2
+ 4 3 'bush' 3
+ 5 3 'helen' 3
+
+示例2: 以"table2_20170707"为Label，使用本地文件table2_data导入table2表。
+
+curl --location-trusted -u test:test -T table2_data http://127.0.0.1:8030/api/example_db/table2/_load?label=table2_20170707
+
+本地table2_data以\t作为数据之间的分隔，具体内容如下：
+
+ 2017-07-03 1 1 'jim' 2
+ 2017-07-05 2 1 'grace' 2
+ 2017-07-12 3 2 'tom' 2
+ 2017-07-15 4 3 'bush' 3
+ 2017-07-12 5 3 'helen' 3
+
+**注意事项**:
+- 小批量导入单批次导入的数据量限制为1GB，用户如果要导入大量数据，需要自己手动拆分成多个小于1GB的文件，分多个批次导入，或者采用批量导入。
+- 每一批导入数据都需要取一个Label，Label 最好是一个和一批数据有关的字符串，方便阅读和管理。Palo基于Label 保证在一个Database内，同一批数据只可导入成功一次。失败任务的Label可以重用。
+- 该方式可以支持用户同时向多个表进行导入，并且多表间原子生效。用法请参阅：'HELP MULTI LOAD'。
+- 导入label建议采用表名+时间的方式。
+- 如果使用了多租户上面的用户名的格式需要是test@example_cluster
+
+#### 批量导入
+
+示例：以 "table1_20170707"为Label，使用HDFS上的文件导入table1表
+```
+LOAD LABEL table1_20170707
+(
+ DATA INFILE("hdfs://your.namenode.host:port/dir/table1_data")
+ INTO TABLE table1
+)
+WITH BROKER hdfs ("username"="hdfs_user", "password"="hdfs_password")
+PROPERTIES
+(
+ "timeout"="3600",
+ "max_filter_ratio"="0.1"
+);
+```
+
+示例：以 "table2_20170707"为Label，使用HDFS上的文件导入table2表
+```
+LOAD LABEL table1_20170707
+(
+ DATA INFILE("hdfs://your.namenode.host:port/dir/table2_data")
+ INTO TABLE table2
+)
+WITH BROKER hdfs ("username"="hdfs_user", "password"="hdfs_password")
+PROPERTIES
+(
+ "timeout"="3600",
+ "max_filter_ratio"="0.1"
+);
+```
+
+**注意事项**:
+
+- 该方式导入Palo的源数据文件必须在HDFS上，并且部署过broker。
+- Label 的使用同小批量导入。
+- timeout表示本次导入的超时时间。
+- max_filter_ratio表示本次导入可以过滤的不符合规范的数据比例。
+- 更多参数的设置可以参考'HELP LOAD'。
+
+
+#### 2.5 查询导入任务的状态
+
+导入任务是异步执行的。执行导入命令后，需要通过SHOW LOAD 命令查询导入任务的状态。
+更多详细参数可以查看:
+
+ HELP SHOW LOAD;
+
+导入任务的主要信息为:
+
+- State：导入状态
+ 1. **pending** 导入任务尚未被调度执行
+ 2. **etl** 正在执行 ETL 计算, Palo 内部状态
+ 3. **loading** 正在进行加载, Palo 内部状态
+ 4. **finished** 导入任务成功完成
+ 5. **cancelled** 导入任务被取消或者失败
+- Progress：导入进度
+- ETL：阶段的作业信息
+ 1. **dpp.abnorm.ALL** 输入数据中被过滤掉的非法数据条数
+ 2. **dpp.norm.ALL** 输入数据中合法的数据条数
+- TaskInfo：本次导入作业的参数信息
+- ErrorMsg：导入任务失败原因
+- CreateTime：任务创建时间
+- EtlStartTime：ETL 开始时间
+- EtlFinishTime：ETL 结束时间
+- LoadStartTime：加载开始时间
+- LoadFinishTime：加载结束时间
+- URL: 导入失败后的错误日志地址
+
+示例1：显示当前数据库内以"table1_20170707"为Label 的所有任务的状态的详细信息
+
+ SHOW LOAD WHERE LABEL = "table1_20170707";
+
+示例2：显示当前正在做ETL的所有任务的状态信息
+
+ SHOW LOAD WHERE STATE = "ETL";
+
+示例3：显示当前数据库内最后20个导入任务的状态
+
+ SHOW LOAD ORDER BY CreateTime DESC LIMIT 20;
+
+**注意事项**:
+- 如果任务失败，[常见问题](./FAQ.md)中的导入任务失败原因。
+
+#### 2.6 取消导入任务
+
+使用CANCEL LOAD命令取消一个正在执行的导入任务。
+被取消的任务数据不会导入Palo。
+已经处于cancelled或finished状态的任务无法被取消。
+
+示例：取消当前数据库中Label为"table1_20170707"的任务
+
+ CANCEL LOAD WHERE LABEL = "table1_20170707";
+
+## 3 数据的查询
+
+#### 3.1 简单查询
+
+示例:
+
+ mysql> select * from table1 limit 3;
+ +--------+----------+----------+------+
+ | siteid | citycode | username | pv |
+ +--------+----------+----------+------+
+ | 2 | 1 | 'grace' | 2 |
+ | 5 | 3 | 'helen' | 3 |
+ | 3 | 2 | 'tom' | 2 |
+ +--------+----------+----------+------+
+
+#### 3.2 order by查询
+
+示例:
+
+ mysql> select * from table1 order by citycode;
+ +--------+----------+----------+------+
+ | siteid | citycode | username | pv |
+ +--------+----------+----------+------+
+ | 2 | 1 | 'grace' | 2 |
+ | 1 | 1 | 'jim' | 2 |
+ | 3 | 2 | 'tom' | 2 |
+ | 4 | 3 | 'bush' | 3 |
+ | 5 | 3 | 'helen' | 3 |
+ +--------+----------+----------+------+
+ 5 rows in set (0.07 sec)
+
+**注意事项**:
+鉴于order by的特殊性，order by后面建议一定要加入limit，如果未加 limit，系统当前默认会自动为你添加limit 65535。
+
+#### 3.3 带有join的查询
+
+示例:
+
+ mysql> select sum(table1.pv) from table1 join table2 where table1.siteid = table2.siteid;
+ +--------------------+
+ | sum(`table1`.`pv`) |
+ +--------------------+
+ | 12 |
+ +--------------------+
+ 1 row in set (0.20 sec)
+
+#### 3.4 带有子查询的查询
+
+示例:
+
+ mysql> select sum(pv) from table2 where siteid in (select siteid from table1 where siteid > 2);
+ +-----------+
+ | sum(`pv`) |
+ +-----------+
+ | 8 |
+ +-----------+
+ 1 row in set (0.13 sec)
+
+
+# 高级使用指南
+
+## 1 数据表的创建和导入相关
+
+#### 1.1 修改Schema
+
+使用ALTER TABLE命令可以修改表的Schema，包括如下修改：
+
+ * 增加列
+ * 删除列
+ * 修改列类型
+ * 改变列顺序
+
+以下举例说明。
+
+原表table1的Schema如下:
+
+ +----------+-------------+------+-------+---------+-------+
+ | Field | Type | Null | Key | Default | Extra |
+ +----------+-------------+------+-------+---------+-------+
+ | siteid | int(11) | Yes | true | 10 | |
+ | citycode | smallint(6) | Yes | true | N/A | |
+ | username | varchar(32) | Yes | true | | |
+ | pv | bigint(20) | Yes | false | 0 | SUM |
+ +----------+-------------+------+-------+---------+-------+
+
+
+我们新增一列uv，类型为BIGINT，聚合类型为SUM，默认值为0:
+
+ ALTER TABLE table1 ADD COLUMN uv BIGINT SUM DEFAULT '0' after pv;
+
+提交成功后，可以通过以下命令查看:
+
+ SHOW ALTER TABLE COLUMN;
+
+当作业状态为FINISHED，则表示作业完成。新的Schema 已生效。
+
+ALTER TABLE完成之后, 可以通过desc table查看最新的schema。
+
+ mysql> desc table1;
+ +----------+-------------+------+-------+---------+-------+
+ | Field | Type | Null | Key | Default | Extra |
+ +----------+-------------+------+-------+---------+-------+
+ | siteid | int(11) | Yes | true | 10 | |
+ | citycode | smallint(6) | Yes | true | N/A | |
+ | username | varchar(32) | Yes | true | | |
+ | pv | bigint(20) | Yes | false | 0 | SUM |
+ | uv | bigint(20) | Yes | false | 0 | SUM |
+ +----------+-------------+------+-------+---------+-------+
+ 5 rows in set (0.00 sec)
+
+可以使用以下命令取消当前正在执行的作业:
+
+ CANCEL ALTER TABLE COLUMN FROM table1;
+
+**注意事项**:
+
+ 请使用 HELP ALTER TABLE 查看更多详细信息。
+
+#### 1.2 创建Rollup
+
+Rollup可以理解为Table的一个物化索引结构。**物化**是因为其数据在物理上独立存储，而**索引**的意思是，Rollup可以调整列顺序以增加前缀索引的命中率，也可以减少key列以增加数据的聚合度。
+
+以下举例说明。
+
+原表table1的Schema如下:
+
+ +----------+-------------+------+-------+---------+-------+
+ | Field | Type | Null | Key | Default | Extra |
+ +----------+-------------+------+-------+---------+-------+
+ | siteid | int(11) | Yes | true | 10 | |
+ | citycode | smallint(6) | Yes | true | N/A | |
+ | username | varchar(32) | Yes | true | | |
+ | pv | bigint(20) | Yes | false | 0 | SUM |
+ | uv | bigint(20) | Yes | false | 0 | SUM |
+ +----------+-------------+------+-------+---------+-------+
+
+对于table1明细数据是siteid, citycode, username三者构成一个key，从而对pv字段进行聚合；如果业务方经常有看城市pv总量的需求，可以建立一个只有citycode, pv的rollup。
+
+ ALTER TABLE table1 ADD ROLLUP rollup_city(citycode, pv);
+
+提交成功后，可以通过以下命令查看:
+
+ SHOW ALTER TABLE ROLLUP;
+
+当作业状态为 FINISHED，则表示作业完成。
+Rollup建立完成之后可以使用desc table1 all查看表的rollup信息。
+
+ mysql> desc table1 all;
+ +-------------+----------+-------------+------+-------+--------+-------+
+ | IndexName | Field | Type | Null | Key | Default | Extra |
+ +-------------+----------+-------------+------+-------+---------+-------+
+ | table1 | siteid | int(11) | Yes | true | 10 | |
+ | | citycode | smallint(6) | Yes | true | N/A | |
+ | | username | varchar(32) | Yes | true | | |
+ | | pv | bigint(20) | Yes | false | 0 | SUM |
+ | | uv | bigint(20) | Yes | false | 0 | SUM |
+ | | | | | | | |
+ | rollup_city | citycode | smallint(6) | Yes | true | N/A | |
+ | | pv | bigint(20) | Yes | false | 0 | SUM |
+ +-------------+----------+-------------+------+-------+---------+-------+
+ 8 rows in set (0.01 sec)
+
+可以使用以下命令取消当前正在执行的作业:
+
+ CANCEL ALTER TABLE ROLLUP FROM table1;
+
+
+**注意事项**:
+
+- 请使用 HELP ALTER TABLE 查看更多详细信息。
+- Rollup建立之后查询不需要指定rollup进行查询，还是指定原有表进行查询就行，程序会自动判断是否应该使用ROLLUP。是否命中ROLLUP可以通过EXPLAIN SQL进行查看。
+
+
+## 2 数据表的查询
+
+#### 2.1 内存限制
+
+* 为了防止用户的一个查询可能因为消耗内存过大，将集群搞挂，所以查询进行了内存控制，默认控制为落在没有节点上的执行计划分片使用不超过 2GB 内存。
+* 用户在使用时，如果发现报 memory limit exceeded 错误，一般是超过内存限制了。
+* 遇到内存超限时，用户应该尽量通过优化自己的sql语句来解决。
+* 如果确切发现2GB内存不能满足，可以手动设置内存参数。
+
+显示查询内存限制:
+
+ mysql> show variables like "%MEM_LIMIT%";
+ +---------------+------------+
+ | Variable_name | Value |
+ +---------------+------------+
+ | exec_mem_limit| 2147483648 |
+ +---------------+------------+
+ 1 row in set (0.00 sec)
+
+exec_mem_limit的单位是byte，可以通过set命令改变exec_mem_limit的值。
+
+ set exec_mem_limit = 10;
+
+ mysql> show variables like "%MEM_LIMIT%";
+ +---------------+--------+
+ | Variable_name | Value |
+ +---------------+--------+
+ | exec_mem_limit| 10 |
+ +---------------+--------+
+ 1 row in set (0.00 sec)
+
+ mysql> select * from table1;
+ ERROR:
+ Memory limit exceeded
+
+#### 2.2 查询超时
+
+当前默认查询时间设置为最长为300秒，如果一个查询在300 秒内没有完成，则查询会被 Palo系统cancel掉。用户可以通过这个参数来定制自己应用的超时时间，实现类似 wait(timeout) 的阻塞方式。
+
+查看当前超时设置:
+
+ mysql> show variables like "%QUERY_TIMEOUT%";
+ +---------------+-------+
+ | Variable_name | Value |
+ +---------------+-------+
+ | QUERY_TIMEOUT | 300 |
+ +---------------+-------+
+ 1 row in set (0.00 sec)
+
+修改超时时间到1分钟:
+
+ set QUERY_TIMEOUT = 60;
+
+**注意事项**:
+
+当前超时的检查间隔为5秒，所以小于5秒的超时不会太准确。这个未来会将精度提高到秒级别。
+
+#### 2.3 broadcast join 和 shuffle join
+
+系统默认实现join的方式，是将小表进行条件过滤后，将其广播到大表所在的各个节点上，形成一个内存hash表，然后流式读出大表的数据进行hash join。但是如果当小表过滤后的数据量无法放入内存的话，此时join 将无法完成，通常的报错应该是首先造成内存超限。
+
+如果遇到上述情况，建议使用shuffle join的方式，也被称作partitioned join。即将小表和大表都按照join的key进行hash，然后进行分布式的 join。这个对内存的消耗就会分摊到集群的所有计算节点上。
+
+使用broadcast join（默认）:
+
+ mysql> select sum(table1.pv) from table1 join table2 where table1.siteid = 2;
+ +--------------------+
+ | sum(`table1`.`pv`) |
+ +--------------------+
+ | 10 |
+ +--------------------+
+ 1 row in set (0.20 sec)
+
+使用 broadcast join（显式指定）:
+
+ mysql> select sum(table1.pv) from table1 join [broadcast] table2 where table1.siteid = 2;
+ +--------------------+
+ | sum(`table1`.`pv`) |
+ +--------------------+
+ | 10 |
+ +--------------------+
+ 1 row in set (0.20 sec)
+
+使用shuffle join:
+
+ mysql> select sum(table1.pv) from table1 join [shuffle] table2 where table1.siteid = 2;
+ +--------------------+
+ | sum(`table1`.`pv`) |
+ +--------------------+
+ | 10 |
+ +--------------------+
+ 1 row in set (0.15 sec)
+
+#### 2.4 failover 和 load balance
+
+**第一种**
+
+自己在应用层代码进行重试和负载均衡。比如发现一个连接挂掉，就自动在其他连接上进行重试。应用层代码重试需要应用自己配置多个palo前端节点地址。
+
+
+**第二种**
+
+如果使用 mysql jdbc connector 来连接Palo，可以使用 jdbc 的自动重试机制:
+
+ jdbc:mysql://[host:port],[host:port].../[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
+
+**第三种**
+
+应用可以连接到和应用部署到同一机器上的mysql proxy，通过配置mysql proxy的failover和loadbalance功能来达到目的。
+
+ http://dev.mysql.com/doc/refman/5.6/en/mysql-proxy-using.html
+
+**注意事项**:
+
+- 无论你是否使用Palo，还是普通的mysql，应用都需要对连接进行错误检测，并且出错后要进行重试。
+- 第一种：在有failover时，需要重试其他节点。
+- 第二种和第三种：failover 时，也只需要简单重试，不需要在应用层明确地选择重试节点。
diff --git a/pages/guides/website.ad b/pages/guides/website.ad
deleted file mode 100644
index 2aee709..0000000
--- a/pages/guides/website.ad
+++ /dev/null
@@ -1,50 +0,0 @@
-//Licensed under the Apache License, Version 2.0 (the "License");
-//you may not use this file except in compliance with the License.
-//You may obtain a copy of the License at
-//
-//http://www.apache.org/licenses/LICENSE-2.0
-//
-//Unless required by applicable law or agreed to in writing, software
-//distributed under the License is distributed on an "AS IS" BASIS,
-//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-//See the License for the specific language governing permissions and
-//limitations under the License.
-= Updating the top-level Incubator website
-Apache Incubator PMC
-2002-10-16
-:jbake-type: pmcGuide
-:jbake-status: published
-:idprefix:
-:toc:
-:imagesdir: ../images/
-
-The Incubator website is generated by the `incubator` git repository. The primary document format is asciidoc, templates are based on gsp, and we use jbake to build it.
-
-You can edit files directly on github and raise a link:https://github.com/apache/incubator[pull request] or just checkout the repository at https://git-wip-us.apache.org/repos/asf/incubator.git
-
-To work with the website, follow information on our link:https://git-wip-us.apache.org/repos/asf?p=incubator.git;a=blob;f=README.md;hb=refs/heads/jbake-site[README]
-
-After you make changes, the site is built automatically. Build failures are sent to *cvs AT incubator.apache.org*
-
-== Maintaining Status files
-
-Podling status files are maintained in SVN, and you should continue to maintain them at https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/
-
-== IP Clearance
-
-IP Clearance is still maintained in SVN, and you should continue to maintain them at https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/
-
-== Building
-
-The website is built on link:https://builds.apache.org/view/H-L/view/Incubator/job/Incubator%20Site/[Jenkins], if you have karma you can trigger a build yourself. Commits to the git repo trigger builds automatically, and the website builds daily for other changes.
-
-== Help Wanted!
-People with commit access to the "incubator" git repository can edit the source
-documents in the "content" directory. That is any ASF Member and
-any committer on a current podling in incubation. So you can all help to
-keep your project's Status page up-to-date, and if you find problems with
-the "guidelines" docs then can immediately fix them.
-If unsure, then discuss changes on the general mailing list.
-Note that the "policy" documents need special treatment.
-
-Anyone else can send patches to those documents to the INCUBATOR issue tracker.
diff --git a/pages/index.ad b/pages/index.ad
new file mode 100644
index 0000000..197fa60
--- /dev/null
+++ b/pages/index.ad
@@ -0,0 +1,53 @@
+//Licensed under the Apache License, Version 2.0 (the "License");
+//you may not use this file except in compliance with the License.
+//You may obtain a copy of the License at
+//
+//http://www.apache.org/licenses/LICENSE-2.0
+//
+//Unless required by applicable law or agreed to in writing, software
+//distributed under the License is distributed on an "AS IS" BASIS,
+//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+//See the License for the specific language governing permissions and
+//limitations under the License.
+
+= Apache Doris (incubating)
+Apache Doris
+2018-09-29
+:jbake-type: homepage
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+Doris is a MPP-based interactive SQL data warehousing for reporting and analysis.
+
+= 1. Overview
+
+Doris’s implementation consists of two daemons: Frontend (FE) and Backend (BE).
+
+image::architecture.png[]
+
+**Frontend daemon** consists of query coordinator and catalog manager. Query coordinator is responsible for receiving users’ sql queries, compiling queries and managing queries execution. Catalog manager is responsible for managing metadata such as databases, tables, partitions, replicas and etc. Several frontend daemons could be deployed to guarantee fault-tolerance, and load balancing.
+
+**Backend daemon** stores the data and executes the query fragments. Many backend daemons could also be deployed to provide scalability and fault-tolerance.
+
+A typical Doris cluster generally composes of several frontend daemons and dozens to hundreds of backend daemons.
+
+Users can use MySQL client tools to connect any frontend daemon to submit SQL query. Frontend receives the query and compiles it into query plans executable by the Backend. Then Frontend sends the query plan fragments to Backend. Backend will build a query execution DAG. Data is fetched and pipelined into the DAG. The final result response is sent to client via Frontend. The distribution of query fragment execution takes minimizing data movement and maximizing scan locality as the main goal.
+
+= 2. Background
+
+At Baidu, Prior to Doris, different tools were deployed to solve diverse requirements in many ways. And when a use case requires the simultaneous availability of capabilities that cannot all be provided by a single tool, users were forced to build hybrid architectures that stitch multiple tools together, but we believe that they shouldn’t need to accept such inherent complexity. A storage system built to provide great performance across a broad range of workloads provides a more elegant [...]
+
+Doris is designed to be a simple and single tightly coupled system, not depending on other systems. Doris provides high concurrent low latency point query performance, but also provides high throughput queries of ad-hoc analysis. Doris provides bulk-batch data loading, but also provides near real-time mini-batch data loading. Doris also provides high availability, reliability, fault tolerance, and scalability.
+
+= 3. Rationale
+
+Doris mainly integrates the technology of link:https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/42851.pdf[Google Mesa] and link:https://impala.apache.org[Apache Impala]. Unlike other popular SQL-on-Hadoop systems, it is designed to be a simple and single tightly coupled system, not depending on other systems.
+
+Mesa is a highly scalable analytic data storage system that stores critical measurement data related to Google's Internet advertising business. Mesa is designed to satisfy complex and challenging set of users’ and systems’ requirements, including near real-time data ingestion and query ability, as well as high availability, reliability, fault tolerance, and scalability for large data and query volumes.
+
+Impala is a modern, open-source MPP SQL engine architected from the ground up for the Hadoop data processing environment. At present, by virtue of its superior performance and rich functionality， Impala has been comparable to many commercial MPP database query engine. Mesa can satisfy the needs of many of our storage requirements, however Mesa itself does not provide a SQL query engine; Impala is a very good MPP SQL query engine, but the lack of a perfect distributed storage engine. So i [...]
+
+Learning from Mesa’s data model, we developed a distributed storage engine. Unlike Mesa, this storage engine does not rely on any distributed file system. Then we deeply integrate this storage engine with Impala query engine. Query compiling, query execution coordination and catalog management of storage engine are integrated to be frontend daemon; query execution and data storage are integrated to be backend daemon. With this integration, we implemented a single, full-featured, high per [...]
+
diff --git a/pages/index.md b/pages/index.md
deleted file mode 100644
index 2d6e960..0000000
--- a/pages/index.md
+++ /dev/null
@@ -1,33 +0,0 @@
-title=Apache Doris
-date=2018-09-28
-type=homepage
-status=published
-~~~~~~
-
-Apache Doris is a MPP-based interactive SQL data warehousing for reporting and analysis.
-
-Apache Doris mainly integrates the technology of Google Mesa and Apache Impala.
-Unlike other popular SQL-on-Hadoop systems, Apache Doris is designed to be a simple and single tightly coupled system, not depending on other systems. Apache Doris not only provides high concurrent low latency point query performance, but also provides high throughput queries of ad-hoc analysis.
-
-Apache Doris not only provides batch data loading, but also provides near real-time mini-batch data loading.
-
-Apache Doris also provides high availability, reliability, fault tolerance, and scalability. The simplicity (of developing, deploying and using) and meeting many data serving requirements in single system are the main features of Apache Doris.
-
-# Install
-Palo only supports Linux System.
-Oracle JDK 8.0+ and GCC 4.8.2+ are required.
-See the document of [INSTALL](https://github.com/baidu/palo/wiki/Palo-Install) and [Deploy & Update](https://github.com/baidu/palo/wiki/Palo-Deploy-%26-Upgrade)
-
-# User Guide
-See the [Palo Wiki](https://github.com/baidu/palo/wiki) for more information.
-
-# Contact us
-dev##doris.apache.org
-
-需要加入Palo微信技术讨论群的，请加微信号：morningman-cmy，然后备注一下：加入Palo技术讨论群
-（Palo开源一群已满）
-
-# Blogs
-1. [浅谈从Google Mesa到百度PALO](http://neoremind.com/2017/09/%E6%B5%85%E8%B0%88%E4%BB%8Egoogle-mesa%E5%88%B0%E7%99%BE%E5%BA%A6palo/comment-page-1/)
-2. [Apache Kylin VS Baidu Palo](https://blog.bcmeng.com/post/apache-kylin-vs-baidu-palo.html)
-
diff --git a/templates/menu.gsp b/templates/menu.gsp
index af7a06b..fd43b99 100644
--- a/templates/menu.gsp
+++ b/templates/menu.gsp
@@ -15,34 +15,14 @@
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Documents <b class="caret"></b></a>
<ul class="dropdown-menu">
- <%proposalGuides.each {guide -> %>
- <li><a href="${config.site_host}/${guide.uri}">${guide.title}</a></li>
- <%}%>
- </ul>
- </li>
- <li class="dropdown">
- <a href="#" class="dropdown-toggle" data-toggle="dropdown">Community <b class="caret"></b></a>
- <ul class="dropdown-menu">
- <%proposalGuides.each {guide -> %>
- <li><a href="${config.site_host}/${guide.uri}">${guide.title}</a></li>
- <%}%>
- </ul>
- </li>
- <li class="dropdown">
- <a href="#" class="dropdown-toggle" data-toggle="dropdown">Downloads <b class="caret"></b></a>
- <ul class="dropdown-menu">
<%guides.each {guide -> %>
<li><a href="${config.site_host}/${guide.uri}">${guide.title}</a></li>
<%}%>
- <li><a href="/clutch">Clutch Report</a></li>
- </ul>
- </li>
- <li class="dropdown">
- <a href="#" class="dropdown-toggle" data-toggle="dropdown">FAQs <b class="caret"></b></a>
- <ul class="dropdown-menu">
- <li><a href="${config.site_host}/faq.html">FAQs</a></li>
</ul>
</li>
+ <li><a href="${config.site_host}/community.html">Community </a></li>
+ <li><a href="${config.site_host}/downloads.html">Downloads </a></li>
+ <li><a href="${config.site_host}/faq.html">FAQs </a></li>
</ul>
</div><!--/.nav-collapse -->
</div>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org