| 1 |
pappy 07/10/27 21:30:00 |
| 2 |
|
| 3 |
Added: index.xml |
| 4 |
Log: |
| 5 |
adding preliminary version of project homepage |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/proj/en/extreme-security/projectmanagement/index.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/extreme-security/projectmanagement/index.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/extreme-security/projectmanagement/index.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: index.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version='1.0' encoding="UTF-8"?> |
| 16 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 17 |
|
| 18 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/extreme-security/projectmanagement/index.xml,v 1.1 2007/10/27 21:29:59 pappy Exp $ --> |
| 19 |
|
| 20 |
<guide link="/proj/en/extreme-security/projectmanagement/index.xml"> |
| 21 |
<title>Extreme Security Project Management</title> |
| 22 |
<author title="Author"> |
| 23 |
<mail link="pappy@g.o">Alexander Gabert</mail> |
| 24 |
</author> |
| 25 |
|
| 26 |
<!-- |
| 27 |
<author title="Contributor"> |
| 28 |
<mail link="XXX">YYY</mail> |
| 29 |
</author> |
| 30 |
<author title="Editor"> |
| 31 |
<mail link="XXX">YYY</mail> |
| 32 |
</author> |
| 33 |
--> |
| 34 |
|
| 35 |
<abstract> |
| 36 |
|
| 37 |
The management of the timetables and the excellence of processes in an open source development project is often underestimated. |
| 38 |
|
| 39 |
</abstract> |
| 40 |
<version>0.1</version> |
| 41 |
<date>2007-10-27</date> |
| 42 |
|
| 43 |
|
| 44 |
<chapter> |
| 45 |
<title> |
| 46 |
Introduction to project management |
| 47 |
</title> |
| 48 |
<section> |
| 49 |
<body> |
| 50 |
<p> |
| 51 |
The management of the timetables and the excellence of processes in an open source development project is often underestimated. |
| 52 |
</p> |
| 53 |
<p> |
| 54 |
However, this does not mean we cannot make a difference. For this reason there shall be a precise structure how development and interaction between developers takes place. |
| 55 |
From the first impression, this may seem bizarre and obscure, but when developers feel constrained to exact and clear processes developed by their own team, there is hope |
| 56 |
that the team can work better together and have more fun enjoying working solutions free of hidden bugs or concealed dependencies from a certain developer. |
| 57 |
</p> |
| 58 |
<!-- |
| 59 |
<note> |
| 60 |
</note> |
| 61 |
--> |
| 62 |
</body> |
| 63 |
</section> |
| 64 |
</chapter> |
| 65 |
|
| 66 |
<chapter> |
| 67 |
<title> |
| 68 |
Project management in source repositories |
| 69 |
</title> |
| 70 |
<section> |
| 71 |
<title> |
| 72 |
Repository structure |
| 73 |
</title> |
| 74 |
<body> |
| 75 |
<p> |
| 76 |
This is the typical layout of a source repository: |
| 77 |
</p> |
| 78 |
|
| 79 |
<pre caption="Normal SVN source repository"> |
| 80 |
167417 drwxr-xr-x 3 pappy pappy 4096 Oct 23 22:28 branches |
| 81 |
558597 drwxr-xr-x 3 pappy pappy 4096 Oct 23 22:28 tags |
| 82 |
14013668 drwxr-xr-x 6 pappy pappy 4096 Oct 23 22:28 trunk |
| 83 |
</pre> |
| 84 |
|
| 85 |
<p> |
| 86 |
There is nothing wrong with it. But there are ways to make it better for a team developing security technology. |
| 87 |
</p> |
| 88 |
|
| 89 |
<p> |
| 90 |
This is the expected structure in an extreme-security hosted project: |
| 91 |
</p> |
| 92 |
|
| 93 |
<pre caption="SVN source repository with review folder"> |
| 94 |
167417 drwxr-xr-x 3 pappy pappy 4096 Oct 23 22:28 branches |
| 95 |
14016466 drwxr-xr-x 2 pappy pappy 4096 Oct 27 22:07 review |
| 96 |
558597 drwxr-xr-x 3 pappy pappy 4096 Oct 23 22:28 tags |
| 97 |
14013668 drwxr-xr-x 6 pappy pappy 4096 Oct 23 22:28 trunk |
| 98 |
</pre> |
| 99 |
|
| 100 |
<p> |
| 101 |
In this scenario, the trunk is the mainline of development containing reviewed components from the branches of the developers |
| 102 |
or the development subteams (2-3 persons). |
| 103 |
</p> |
| 104 |
|
| 105 |
<p> |
| 106 |
Development of code and documentation is done in branches, then independently reviewed by a group of persons (must not be experts on the topic) |
| 107 |
and then either committed to the trunk by a reviewer or given back to the developer or the subteam with the sourcecode or documentation |
| 108 |
marked with "TODO" tags where it needs improvement or errors fixed. |
| 109 |
</p> |
| 110 |
|
| 111 |
<note> |
| 112 |
<!-- |
| 113 |
|
| 114 |
TODO |
| 115 |
|
| 116 |
- write development model (design, develop, review, publish) |
| 117 |
|
| 118 |
--> |
| 119 |
</note> |
| 120 |
|
| 121 |
</body> |
| 122 |
</section> |
| 123 |
</chapter> |
| 124 |
|
| 125 |
</guide> |
| 126 |
|
| 127 |
|
| 128 |
|
| 129 |
-- |
| 130 |
gentoo-commits@g.o mailing list |
Archives