Changes between Version 2 and Version 3 of Guidelines

Timestamp:

08/16/07 12:29:36 (8 years ago)

Author:

brecht

Comment:

--

Guidelines

@@ -5 +5 @@
 This page discusses some guidelines about using the !BePorts' Trac site.
 
-== Merging with the main tree ==
+== Merging ==
 
-A port should aim to get merged with the original software's main source tree. Many open source projects use the GNU [http://en.wikipedia.org/wiki/GNU_build_system Autotools] in order to be portable on a source level. While the concept is great, [http://www.gnu.org/software/autoconf/ Autoconf] and [http://www.gnu.org/software/automake/ Automake] are quite daunting. It is however worthwhile to learn at least a minimum about the GNU autotools. It will only help you. The PortingTips contains links to more information about Autoconf and Automake.
+A port should eventually be merged with the original software's main source tree. Many open source projects use the GNU [http://en.wikipedia.org/wiki/GNU_build_system Autotools] in order to be portable on a source level. While the concept is great, [http://www.gnu.org/software/autoconf/ Autoconf] and [http://www.gnu.org/software/automake/ Automake] are quite daunting. It is however worthwhile to learn at least a minimum about the GNU Autotools. The PortingTips contain links to more information about Autoconf and Automake.
 
 == The PortLog ==
 
-versions, revisions
+When porting an application or library, it is strongly advised you keep a log of:
 
-category/port
+ * what options are necessary for building on BeOS; and 
+ * what problems you run into, and the solutions to them.
 
-problems -> ticket (linking)
-solutions
+This information can be very helpful to others, after all.
+
+When you get stuck and give up (hey, don't feel bad), create a new ticket explaining the problem. Also link to this ticket from within the port's PortLog. Consult TracLinks on how to do that. The tickets should be assigned to the component that corresponds to the port's category. It's all self-explanatory, really.
 
 == Platforms ==
 
+Because of the incompatibilities between the various BeOS platforms, a port should be tested on all of them. '''BONE''' binaries however, should be able to run on Dano and Zeta, from what I hear. Correct me (Brecht) if I'm wrong. So that's one target for the three of those. '''R5''' (5.0.3) and '''Haiku''' are very different from BONE and are therefor two other targets.
+
+The status of a port is described by the following keywords:
+
+ * ''untested'': not tested on this platform
+ * ''broken'': doesn't build
+ * ''unstable'': builds, but fails tests or has obvious flaws
+ * ''stable'': passes tests and seems to be working as it should
+
+== Layout ==
+
+It would be nice if the layout of the portlogs would be consistent. Unfortunately, (currently) there is no way of enforcing this. Please use the following template:
+
+{{{
+[[TOC]]
+
+= category/port =
+
+== version 1.0 ==
+
+||r5||status||
+||bone||status||
+||haiku||status||
+
+=== revision 1 (user) ===
+}}}