Skip to content

Commit 1e4d248

Browse files
deanberrisdeanberris
committed
Fleshing out process.html
1 parent 77dc17e commit 1e4d248

File tree

1 file changed

+132
-1
lines changed

1 file changed

+132
-1
lines changed

‎process.html

Lines changed: 132 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,16 @@
88
</head>
99
<body data-spy="scroll" data-target=".cpp-netlib-docs-sidebar">
1010
<div id="wrap">
11+
<div class="navbar navbar-fixed-top navbar-inverse cpp-netlib-navbar">
12+
<div class="container">
13+
<ul class="nav">
14+
<li><a class="brand" href="index.html">cpp-netlib</a></li>
15+
<li class="active"><a href="process.html">Development Process</a></li>
16+
<li><a href="style-guide.html">Style Guide</a></li>
17+
<li><a href="proposals.html">Proposals</a></li>
18+
</ul>
19+
</div>
20+
</div>
1121
<header class="jumbotron subhead">
1222
<div class="container">
1323
<h1>Development Process</h1>
@@ -20,6 +30,7 @@ <h1>Development Process</h1>
2030
<ul class="nav nav-list" data-spy="affix" data-offset-top="150">
2131
<li><a href="#overview">Overview</a></li>
2232
<li><a href="#introduction">Introduction</a></li>
33+
<li><a href="#pull-requests">Pull Requests</a></li>
2334
</ul>
2435
</div>
2536
<div class="span9">
@@ -46,8 +57,128 @@ <h1>Introduction</h1>
4657
goal.</p>
4758
<p>If you haven't yet, please subscribe to the developers mailing
4859
list and introduce yourself before proceeding.</p>
49-
<p><a href="https://groups.google.com/forum/?fromgroups#!forum/cpp-netlib" class="btn btn-success" target="_blank">Subcribe</a></p>
60+
<p><a href="https://groups.google.com/group/cpp-netlib" class="btn btn-success" target="_blank">Subcribe</a></p>
61+
</section>
62+
<section id="pull-requests">
63+
<div class="page-header">
64+
<h1>Pull Requests</h1>
5065
</div>
66+
<p>The maintainers of the project review and merge <a href=""
67+
target="_blank">Pull Requests</a> (from here on out referred to
68+
as PR's) from contributors using the GitHub Pull Request feature.
69+
This allows the project to move forward using the Git distributed
70+
development workflow. If you need an introduction to git, please
71+
refer to the following links for git-specific information.</p>
72+
<ul>
73+
<li><a href="">ProGit</a> &mdash; a website dedicated to basic
74+
and advanced git usage.</li>
75+
<li><a href="">GitHub Git Setup</a> &mdash; the GitHub help pages
76+
on setting up git to work with GitHub.</li>
77+
</ul>
78+
<p>What follows in this section assumes that you're already
79+
familiar with the basic git workflow.</p>
80+
<h2>Forking the Repo</h2>
81+
<p>Forking requires that you already have a GitHub account.
82+
Before continuing, please make sure that you've signed up for a
83+
GitHub account (it's free to develop for open source projects)
84+
and have familiarized yourself with the different development
85+
workflows. It's important that you understand the GitHub workflow
86+
before continuing.</p>
87+
<p>The official repository is located in GitHub at <a
88+
href="https://github.com/cpp-netlib/cpp-netlib"
89+
target="_blank">https://github.com/cpp-netlib/cpp-netlib</a>.
90+
Before you can submit PR's you should first create your own fork
91+
of the repository on GitHub. You can fork the repository by
92+
clicking on <a
93+
href="https://github.com/cpp-netlib/cpp-netlib/fork_select"
94+
class="btn btn-success" target="_blank">Fork</a> at the upper
95+
right portion of the page.</p>
96+
<h2>Preparing a PR</h2>
97+
<p>Once you have a fork of the repo, determine to which branch
98+
you'd like to send a PR to. In the next section we describe the
99+
various branches we'll be dealing with in the course of
100+
development of a release.</p>
101+
<p>When you've determined the branch to which you'd like to send
102+
a PR to you can follow these steps to prepare your change for
103+
inclusion in the library.</p>
104+
<ol>
105+
<li><strong>Create an integration branch.</strong> This
106+
integration branch should be rooted off the branch you intend to
107+
send a PR to. For example, if you're sending a PR to
108+
<code>cpp-netlib/master</code> and your fork is
109+
<code>user/master</code>, you should create a
110+
<code>user/master-integration</code> branch.</li>
111+
<li><strong>Create a topic branch.</strong> From the integration
112+
branch, you can then create as many topic branches as you want.
113+
It's recommended that you isolate all experimentation to branches
114+
&mdash; once you're resonably sure that your work is good to go,
115+
merge your topic branch into the integration branch in your local
116+
repo, then push the changes to your GitHub repo.</li>
117+
<li><strong>Make sure your integration branch is up to
118+
date.</strong> To do this you should first pull changes to your
119+
local master (assuming that's where you'd like to send a pull
120+
request to), rebase your integration branch to the tip of master,
121+
then make sure all merge conflicts are dealt with. Proceed ony
122+
when your integration branch is up-to-date with the official
123+
branch you're going to send your PR to.</li>
124+
<li><strong>Send the PR.</strong> Once you're reasonably happy
125+
with the state of your integration branch, send off a PR to the
126+
official repo and set the destination branch as the branch you
127+
intend to send the change to.</li>
128+
<li><strong>Address Comments</strong> The maintainers will be
129+
reviewing your changes, and sometimes they may have comments they
130+
will ask you to address in your PR. You can do this by going back
131+
to the second step of this process, but you don't need to send
132+
another PR -- all you have to do is push your changes to your
133+
GitHub hosted integration branch and your PR will be updated
134+
automatically. That said, don't forget to update the discussion
135+
on the PR that you're ready for the PR to be reviewed again.</li>
136+
<li><strong>Your PR is merged.</strong> If you've done everything
137+
correctly up to this point, your PR should be cleanly merge-able
138+
into the branch you sent the PR to. A maintiner will merge you
139+
change into the project and you're now officially a contributor
140+
to the project!</li>
141+
</ol>
142+
<p>In case you have multiple PR's in flight, you may want to have
143+
multiple integration branches &mdash; that is, one integration
144+
branch per PR should be good to keep.</p>
145+
<h2>Working Branches</h2>
146+
<p>The project always has the latest bleeding edge versions of
147+
the library under development in the <code>master</code> branch.
148+
This version is explicitly unstable and subject to (potentially
149+
massive) changes over time.</p>
150+
<p>Once the state of <code>master</code> has stabilized and a
151+
release process is initiated by the project maintainers (it will
152+
be announced on the mailing list) a <code>version-devel</code>
153+
branch is started from master and a release candidate is
154+
prepared. For example, if a 1.0 release is initiated, a branch
155+
<code>1.0-devel</code> is started off master.</p>
156+
<p>A release candidate is tagged off of the
157+
<code>version-devel</code> branch on a regular basis, and is
158+
publicized as widely as possible. The tag name should be of the
159+
form <code>version-rcN</code>. Again as an example, the first
160+
release candidate for a 1.0 release will be tagged as
161+
<code>1.0.0-rc0</code>.</p>
162+
<p>All PR's for the upcoming version should go directly to the
163+
<code>version-devel</code> branch.</p>
164+
<p>During the stabilization of the <code>version-devel</code>
165+
branch, master remains open for PR's for new functionality, new
166+
accepted libraries, and API breaking changes.</p>
167+
<p>Once a release candidate is deemed "good to go" by the
168+
maintainers we tag the library (and submodules appropriately)
169+
with a tag of the form <code>version-final</code>. As with
170+
earlier examples, the tag for the 1.0 release would be
171+
<code>1.0.0-final</code>.</p>
172+
<h3>Patch Releases</h3>
173+
<p>Critical bug fixes go into the <code>version-devel</code>
174+
branch after a final release has been packaged. In case there's a
175+
need for update releases, the release candidate process is
176+
followed until another final version of the patch release is
177+
tagged.</p>
178+
<p>In our on-going example, this will be of the form
179+
<code>1.0.1-rc0</code>, <code>1.0.1-rc1</code>, and so on until
180+
it's stabilized &mdash; at which time a <code>1.0.1-final</code>
181+
is tagged and packaged.</p>
51182
</section>
52183
</div>
53184
</div>

0 commit comments

Comments
 (0)