qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Qpid > Qpid Project Developers' Guide
Date Tue, 14 May 2013 08:04:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2042/9/21/_/styles/combined.css?spaceKey=qpid&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Project+Developers%27+Guide">Qpid
Project Developers&#39; Guide</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~phil@philharveyonline.com">Phil
Harvey</a>
    </h4>
        <br/>
                         <h4>Changes (46)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-unchanged" >h2. Purpose <br> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">This
guide, written by Rafael Schloming, gives both Qpid committers and submitters a useful introduction
to project etiquette, shedding light on how we do things &amp; why. Following this etiquette
makes the path to righteousness less long and winding ! <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">This
page describes how we do things and why. It includes  guidelines on communication, collaboration
and design. This guide was  originally written by Rafael Schloming. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2.
Maintainers <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h2.
Tell others what you&#39;re working on <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >The Qpid project consists of a
number of major components <span class="diff-added-words"style="background-color: #dfd;">
</span> spread across almost as many different languages. Thus it is rare for <span
class="diff-added-words"style="background-color: #dfd;"> </span> qpid committers
to be experts in every single area of the project. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >As such it is expected that qpid
committers make some effort <span class="diff-added-words"style="background-color: #dfd;">
</span> to reach out to their teammates before directly modifying components <span
class="diff-added-words"style="background-color: #dfd;"> </span> that are outside
their chosen areas. <br></td></tr>
            <tr><td class="diff-unchanged" > <br>You should use the dev
list to reach out to Qpid developers and comment on any JIRAs you&#39;re progressing.
<br> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2.
Patch Submission <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h2.
How to submit and apply patches <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >As a committer it can be difficult
to decide whether/how to <span class="diff-added-words"style="background-color: #dfd;">
</span> provide feedback when someone submits a patch. Often it is tempting to <span
class="diff-added-words"style="background-color: #dfd;"> </span> just fix up the
patch and avoid the slower and sometimes awkward process <span class="diff-added-words"style="background-color:
#dfd;"> </span> of telling someone that they got some part of it wrong. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >However, it is necessary to ensure
that those who submit <span class="diff-added-words"style="background-color: #dfd;">
</span> patches get to learn what they need to know in order to become a valued <span
class="diff-added-words"style="background-color: #dfd;"> </span> qpid committer.
<br></td></tr>
            <tr><td class="diff-unchanged" > <br>In that spirit, here are
a few guidelines for contributing patch submissions and how we handle them: <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">
<br></td></tr>
            <tr><td class="diff-changed-lines" >* Submitters should produce the
final patch(s) as applied to <span class="diff-added-words"style="background-color: #dfd;">
</span> the tree. Producing a patch that needs little or no rework is a key <span
class="diff-added-words"style="background-color: #dfd;"> </span> skill for a qpid
committer. <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">
<br></td></tr>
            <tr><td class="diff-changed-lines" >* Maintainers may make requests
for &#39;trivial&#39; updates to the <span class="diff-added-words"style="background-color:
#dfd;"> </span> patch. Such requests are vital to ensuring that contributers	get
<span class="diff-added-words"style="background-color: #dfd;"> </span> familiar
with subtle yet important aspects of the code, stylistic <span class="diff-added-words"style="background-color:
#dfd;"> </span> conventions, etc. <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">
<br></td></tr>
            <tr><td class="diff-changed-lines" >* Make sure the submitter is familiar
with project etiquette <span class="diff-added-words"style="background-color: #dfd;">
</span> so they understand why we make seemingly trivial requests. We&#39;ll ask
new <span class="diff-added-words"style="background-color: #dfd;"> </span> contributers
to read this etiquette info for that reason <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">!</span>
<span class="diff-added-words"style="background-color: #dfd;">\!</span> <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">
<br></td></tr>
            <tr><td class="diff-changed-lines" >* A one-time patch from someone
passing through may need <span class="diff-added-words"style="background-color: #dfd;">
</span> nothing more than a polite thank you regardless of the content. If a <span
class="diff-added-words"style="background-color: #dfd;"> </span> submitter does aim
for committership, best to make it plain you&#39;re <span class="diff-added-words"style="background-color:
#dfd;"> </span> planning to stay around on the project. <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">
<br></td></tr>
            <tr><td class="diff-changed-lines" >* Break up unrelated changes.
It wouldn&#39;t be considered <span class="diff-added-words"style="background-color:
#dfd;"> </span> correct for a committer to glom together too many unrelated changes
<span class="diff-added-words"style="background-color: #dfd;"> </span> within
a single commit, and so we won&#39;t commit this kind of patch from <span class="diff-added-words"style="background-color:
#dfd;"> </span> submitters. <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">
<br></td></tr>
            <tr><td class="diff-unchanged" >* You need a JIRA for any patch to
be attached to, which should accurately describe the change. <br> <br></td></tr>
            <tr><td class="diff-changed-lines" >h2. <span class="diff-added-words"style="background-color:
#dfd;">How to design and implement</span> Big Ideas <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >Every so often someone has a Big
Idea that they get excited <span class="diff-added-words"style="background-color: #dfd;">
</span> about and want to go do. They generally mail the list about it to give <span
class="diff-added-words"style="background-color: #dfd;"> </span> people the opportunity
to comment, and then when nobody says anything <span class="diff-added-words"style="background-color:
#dfd;"> </span> they go off and do it. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-changed-lines" >Fast forward six months later
they <span class="diff-added-words"style="background-color: #dfd;"> </span> commit/merge/enable/publish
the result of their Big Idea, and suddenly <span class="diff-added-words"style="background-color:
#dfd;"> </span> everyone understands the full implications, and not everyone is happy.
<br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3.
Guidelines <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">To
ensure the success of a Big Idea, it is important to: <br>* Communicate it well. <br>*
Design it well. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">So,
here are a few guidelines for making sure this doesn&#39;t happen, starting with how to
write a good proposal for a Big Idea: <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Guidelines
for doing this are described below. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*
Make sure your proposal is recognizable as a proposal. An easy way to avoid ambiguity is to
start a new thread for your proposal and stick &quot;proposal&quot; somewhere in the
subject. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h3.
Communication Guidelines <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">So,
here are a few guidelines for making sure this doesn&#39;t happen, starting with how to
write a good proposal for a Big Idea: <br>* Make sure your proposal is recognizable
as a proposal. An  easy way to avoid ambiguity is to start a new thread for your proposal
 and stick &quot;proposal&quot; somewhere in the subject. <br></td></tr>
            <tr><td class="diff-changed-lines" >* Understand who and what your
proposal <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">e</span><span
class="diff-added-chars"style="background-color: #dfd;">a</span>ffects,</span>
and make <span class="diff-added-words"style="background-color: #dfd;"> </span>
this clear. If you think X&#39;s implementation of Y doesn&#39;t deserve to live <span
class="diff-added-words"style="background-color: #dfd;"> </span> and you&#39;re
going to rewrite the whole thing from scratch then make this <span class="diff-added-words"style="background-color:
#dfd;"> </span> very clear so X can object sooner rather than later. <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">
<br></td></tr>
            <tr><td class="diff-unchanged" >* Make sure you call out loudly that
you intend to kill feature A, even if you think no-one on earth should care. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">*
Even if you&#39;re going to write an Atari emulator, and you&#39;re  100% sure that
it won&#39;t overlap with anything in the rest of the  project, make sure you understand
how and why it relates to the rest of  the project in general, and make that clear. <br>*
Be concrete. Often a proposal of the form &quot;hey, I did a  little of this, here is
a proof-of-concept, I&#39;d like to do it for real  now&quot; is far more effective
than a proposal of the form &quot;hey, I have this  vague idea about this, I&#39;m
going to vaguely suggest it would be good if  someone did it&quot;. <br>* Talk about
the long term implications of your proposal. If  it&#39;s code then someone needs to maintain
it, and committers will expect  this to be you. Make clear your intentions. <br>* Never
assume silence implies complicity, more likely it  means people didn&#39;t understand
the implications of your proposal, or  didn&#39;t have time to figure out why they didn&#39;t
like it. Ask again \! <br>* The bigger your idea is, the more time and effort you  should
spend on the proposal, and ensuring that you get positive  responses and deal with the comments
and feedback provided in your  actual implementation. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*
Even if you&#39;re going to write an Atari emulator, and you&#39;re 100% sure that
it won&#39;t overlap with anything in the rest of the project, make sure you understand
how and why it relates to the rest of the project in general, and make that clear. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h4.
Talk early, talk often <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*
Be concrete. Often a proposal of the form &quot;hey, I did a little of this, here is a
proof-of-concept, I&#39;d like to do it for real now&quot; is far more effective than
a proposal of the form &quot;hey, I have this vague idea about this, I&#39;m going
to vaguely suggest it would be good if someone did it&quot;. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">No
matter how incredibly excellent your proposal is, there is  going to need to be some discussion
before the result of your Big Idea  is blessed. Here are some things you can do to help that
discussion go  smoothly: <br>* Make frequent progress reports. Every hour/day/week/month
 you spend working without telling people what you&#39;re doing is an  hour/day/week/month
of your time that you risk wasting. <br>* Define milestones and make them visible to
the rest of the  project. Just like a concrete proof-of-concept can help a proposal, it  helps
to give people a concrete look at what you&#39;re doing while it&#39;s in  progress.
This can go a long way towards avoiding surprises. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*
Talk about the long term implications of your proposal. If it&#39;s code then someone
needs to maintain it, and committers will expect this to be you. Make clear your intentions.
<br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h4.
Notify others when you&#39;re nearly ready to commit <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*
Never assume silence implies complicity, more likely it means people didn&#39;t understand
the implications of your proposal, or didn&#39;t have time to figure out why they didn&#39;t
like it. Ask again ! <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">When
the time does come to commit/merge/enable/publish your  Big Idea, it really shouldn&#39;t
be a surprise to anyone if you&#39;ve followed  the steps up until now, but make sure
you let people know in advance by  making note in your final few progress reports of when
you expect to be  finished, and sending a note to the dev list a day or so before you  flip
the big switch. <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*
The bigger your idea is, the more time and effort you should spend on the proposal, and ensuring
that you get positive responses and deal with the comments and feedback provided in your actual
implementation. <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h3.
Design guidelines <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3.
Talk early, talk often <br> <br>No matter how incredibly excellent your proposal
is, there is going to need to be some discussion before the result of your Big Idea is blessed.
Here are some things you can do to help that discussion go smoothly: <br> <br>*
Make frequent progress reports. Every hour/day/week/month you spend working without telling
people what you&#39;re doing is an hour/day/week/month of your time that you risk wasting.
<br> <br>* Define milestones and make them visible to the rest of the project.
Just like a concrete proof-of-concept can help a proposal, it helps to give people a concrete
look at what you&#39;re doing while it&#39;s in progress. This can go a long way towards
avoiding surprises. <br> <br>h3. And finally ..... <br> <br>When the
time does come to commit/merge/enable/publish your Big Idea, it really shouldn&#39;t be
a surprise to anyone if you&#39;ve followed the steps up until now, but make sure you
let people know in advance by making note in your final few progress reports of when you expect
to be finished, and sending a note to the dev list a day or so before you flip the big switch.
<br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">A
common cause of poor software is that important aspects of  the design were not considered
early on. Use the checklist below to help  you avoid this. <br>* *Impact on public interfaces*,
e.g. <br>** Interoperability with implementations in other languages <br>** Backwards
compatibility <br>** Documentation (docbook, HTML, etc) <br>* *Performance* <br>*
*Security* <br>* *Favour incremental change* \- consider if the change can be split
into several smaller ones. This can reduce risk and accelerate &quot;time to market&quot;
<br>* *Automated testing* approach: <br>** For testing the new code, <br>**
and for regression-testing existing functionality that may be affected. <br>* *Operational
implications*, e.g. <br>** Logging <br>** Monitoring <br>** Management <br>*
*Threading* model <br>* *Memory* management <br>* *Platform-specific considerations*,
particularly when considering C+\+ code or language bindings <br>* Implications of executing
the code in non-trivial set-ups, especially: <br>** High availability <br>** During
failover <br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h2><a name="QpidProjectDevelopers%27Guide-Purpose"></a>Purpose</h2>

<p>This page describes how we do things and why. It includes  guidelines on communication,
collaboration and design. This guide was  originally written by Rafael Schloming.</p>

<h2><a name="QpidProjectDevelopers%27Guide-Tellotherswhatyou%27reworkingon"></a>Tell
others what you're working on</h2>

<p>The Qpid project consists of a number of major components  spread across almost as
many different languages. Thus it is rare for  qpid committers to be experts in every single
area of the project.</p>

<p>As such it is expected that qpid committers make some effort  to reach out to their
teammates before directly modifying components  that are outside their chosen areas.</p>

<p>You should use the dev list to reach out to Qpid developers and comment on any JIRAs
you're progressing.</p>

<h2><a name="QpidProjectDevelopers%27Guide-Howtosubmitandapplypatches"></a>How
to submit and apply patches</h2>

<p>As a committer it can be difficult to decide whether/how to  provide feedback when
someone submits a patch. Often it is tempting to  just fix up the patch and avoid the slower
and sometimes awkward process  of telling someone that they got some part of it wrong.</p>

<p>However, it is necessary to ensure that those who submit  patches get to learn what
they need to know in order to become a valued  qpid committer.</p>

<p>In that spirit, here are a few guidelines for contributing patch submissions and
how we handle them:</p>
<ul>
	<li>Submitters should produce the final patch(s) as applied to  the tree. Producing
a patch that needs little or no rework is a key  skill for a qpid committer.</li>
	<li>Maintainers may make requests for 'trivial' updates to the  patch. Such requests
are vital to ensuring that contributers	get  familiar with subtle yet important aspects of
the code, stylistic  conventions, etc.</li>
	<li>Make sure the submitter is familiar with project etiquette  so they understand
why we make seemingly trivial requests. We'll ask new  contributers to read this etiquette
info for that reason &#33;</li>
	<li>A one-time patch from someone passing through may need  nothing more than a polite
thank you regardless of the content. If a  submitter does aim for committership, best to make
it plain you're  planning to stay around on the project.</li>
	<li>Break up unrelated changes. It wouldn't be considered  correct for a committer
to glom together too many unrelated changes  within a single commit, and so we won't commit
this kind of patch from  submitters.</li>
	<li>You need a JIRA for any patch to be attached to, which should accurately describe
the change.</li>
</ul>


<h2><a name="QpidProjectDevelopers%27Guide-HowtodesignandimplementBigIdeas"></a>How
to design and implement Big Ideas</h2>

<p>Every so often someone has a Big Idea that they get excited  about and want to go
do. They generally mail the list about it to give  people the opportunity to comment, and
then when nobody says anything  they go off and do it.</p>

<p>Fast forward six months later they  commit/merge/enable/publish the result of their
Big Idea, and suddenly  everyone understands the full implications, and not everyone is happy.</p>

<p>To ensure the success of a Big Idea, it is important to:</p>
<ul>
	<li>Communicate it well.</li>
	<li>Design it well.</li>
</ul>


<p>Guidelines for doing this are described below.</p>

<h3><a name="QpidProjectDevelopers%27Guide-CommunicationGuidelines"></a>Communication
Guidelines</h3>

<p>So, here are a few guidelines for making sure this doesn't happen, starting with
how to write a good proposal for a Big Idea:</p>
<ul>
	<li>Make sure your proposal is recognizable as a proposal. An  easy way to avoid ambiguity
is to start a new thread for your proposal  and stick "proposal" somewhere in the subject.</li>
	<li>Understand who and what your proposal affects, and make  this clear. If you think
X's implementation of Y doesn't deserve to live  and you're going to rewrite the whole thing
from scratch then make this  very clear so X can object sooner rather than later.</li>
	<li>Make sure you call out loudly that you intend to kill feature A, even if you think
no-one on earth should care.</li>
	<li>Even if you're going to write an Atari emulator, and you're  100% sure that it
won't overlap with anything in the rest of the  project, make sure you understand how and
why it relates to the rest of  the project in general, and make that clear.</li>
	<li>Be concrete. Often a proposal of the form "hey, I did a  little of this, here is
a proof-of-concept, I'd like to do it for real  now" is far more effective than a proposal
of the form "hey, I have this  vague idea about this, I'm going to vaguely suggest it would
be good if  someone did it".</li>
	<li>Talk about the long term implications of your proposal. If  it's code then someone
needs to maintain it, and committers will expect  this to be you. Make clear your intentions.</li>
	<li>Never assume silence implies complicity, more likely it  means people didn't understand
the implications of your proposal, or  didn't have time to figure out why they didn't like
it. Ask again &#33;</li>
	<li>The bigger your idea is, the more time and effort you  should spend on the proposal,
and ensuring that you get positive  responses and deal with the comments and feedback provided
in your  actual implementation.</li>
</ul>


<h4><a name="QpidProjectDevelopers%27Guide-Talkearly%2Ctalkoften"></a>Talk
early, talk often</h4>

<p>No matter how incredibly excellent your proposal is, there is  going to need to be
some discussion before the result of your Big Idea  is blessed. Here are some things you can
do to help that discussion go  smoothly:</p>
<ul>
	<li>Make frequent progress reports. Every hour/day/week/month  you spend working without
telling people what you're doing is an  hour/day/week/month of your time that you risk wasting.</li>
	<li>Define milestones and make them visible to the rest of the  project. Just like
a concrete proof-of-concept can help a proposal, it  helps to give people a concrete look
at what you're doing while it's in  progress. This can go a long way towards avoiding surprises.</li>
</ul>


<h4><a name="QpidProjectDevelopers%27Guide-Notifyotherswhenyou%27renearlyreadytocommit"></a>Notify
others when you're nearly ready to commit</h4>

<p>When the time does come to commit/merge/enable/publish your  Big Idea, it really
shouldn't be a surprise to anyone if you've followed  the steps up until now, but make sure
you let people know in advance by  making note in your final few progress reports of when
you expect to be  finished, and sending a note to the dev list a day or so before you  flip
the big switch.</p>

<h3><a name="QpidProjectDevelopers%27Guide-Designguidelines"></a>Design
guidelines</h3>

<p>A common cause of poor software is that important aspects of  the design were not
considered early on. Use the checklist below to help  you avoid this.</p>
<ul>
	<li><b>Impact on public interfaces</b>, e.g.
	<ul>
		<li>Interoperability with implementations in other languages</li>
		<li>Backwards compatibility</li>
		<li>Documentation (docbook, HTML, etc)</li>
	</ul>
	</li>
	<li><b>Performance</b></li>
	<li><b>Security</b></li>
	<li><b>Favour incremental change</b> &#45; consider if the change can
be split into several smaller ones. This can reduce risk and accelerate "time to market"</li>
	<li><b>Automated testing</b> approach:
	<ul>
		<li>For testing the new code,</li>
		<li>and for regression-testing existing functionality that may be affected.</li>
	</ul>
	</li>
	<li><b>Operational implications</b>, e.g.
	<ul>
		<li>Logging</li>
		<li>Monitoring</li>
		<li>Management</li>
	</ul>
	</li>
	<li><b>Threading</b> model</li>
	<li><b>Memory</b> management</li>
	<li><b>Platform-specific considerations</b>, particularly when considering
C+&#43; code or language bindings</li>
	<li>Implications of executing the code in non-trivial set-ups, especially:
	<ul>
		<li>High availability</li>
		<li>During failover</li>
	</ul>
	</li>
</ul>

    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Project+Developers%27+Guide">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=17268828&revisedVersion=4&originalVersion=3">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Project+Developers%27+Guide?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org


Mime
View raw message