tweaks for 2M devices
[openwrt.git] / docs / bugs.tex
index ab513d4..b4f502c 100644 (file)
@@ -1,15 +1,19 @@
-OpenWrt as an open source software opens its developpment to the community by having a publicly browseable subversion repository. The Trac software which comes along with a Subversion frontend,  a Wiki and a ticket reporting system is used as an interface between developpers, users and contributors in order to make the whole developpment process much easier and efficient.
+OpenWrt as an open source software opens its development to the community by
+having a publicly browseable subversion repository. The Trac software which
+comes along with a Subversion frontend,  a Wiki and a ticket reporting system 
+is used as an interface between developers, users and contributors in order to 
+make the whole development process much easier and efficient.
 
 
-We make distinction between two kinds of people within the Trac system :
+We make distinction between two kinds of people within the Trac system:
 
 \begin{itemize}
 
 \begin{itemize}
-\item developpers, able to report, close and fix tickets
+\item developers, able to report, close and fix tickets
 \item reporters, able to add a comment, patch, or request ticket status
 \end{itemize}
 
 \subsubsection{Opening a ticket}
 
 \item reporters, able to add a comment, patch, or request ticket status
 \end{itemize}
 
 \subsubsection{Opening a ticket}
 
-A reporter might want to open a ticket for the following reasons :
+A reporter might want to open a ticket for the following reasons:
 
 \begin{itemize}
 \item a bug affects a specific hardware and/or software and needs to be fixed
 
 \begin{itemize}
 \item a bug affects a specific hardware and/or software and needs to be fixed
@@ -17,7 +21,7 @@ A reporter might want to open a ticket for the following reasons :
 \item a feature should be added or removed from OpenWrt
 \end{itemize}
 
 \item a feature should be added or removed from OpenWrt
 \end{itemize}
 
-Regarding the kind of ticket that is open, a patch is welcome in those cases :
+Regarding the kind of ticket that is open, a patch is welcome in those cases:
 
 \begin{itemize}
 \item new package to be included in OpenWrt
 
 \begin{itemize}
 \item new package to be included in OpenWrt
@@ -25,22 +29,39 @@ Regarding the kind of ticket that is open, a patch is welcome in those cases :
 \item new features that can be added by modifying existing OpenWrt files
 \end{itemize}
 
 \item new features that can be added by modifying existing OpenWrt files
 \end{itemize}
 
-In order to include a patch, you need to produce it, this can be done by using the \textbf{svn diff} command which generates the differences between your local copy (modified) and the version on the OpenWrt repository (unmodified yet). Then attach the patch with a description, using the "Attach" button.
+Once the ticket is open, a developer will take care of it, if so, the ticket is marked
+as "accepted" with the developer name. You can add comments at any time to the ticket,
+even when it is closed.
 
 
-Once the ticket is open, a developper will take care of it, if so, the ticket is marked as "accepted" with the developper name. You can add comments at any time to the ticket, even when it is closed.
+\subsubsection{Submitting patches}
+
+In order to include a patch to a ticket, you need to output it, this can be done by using the \textbf{svn diff} command which generates the differences between your local copy (modified) and the version on the OpenWrt repository (unmodified yet). Then attach the patch with a description, using the "Attach" button.
+
+Your patch must respect the following conventions :
+
+\begin{itemize}
+\item it has to work, with no side effect on other platforms, distributions, packages ...
+\item it must have a reason to be included in OpenWrt : bug fix, enhancement, feature adding/removing
+\item the patch name should be named like that : <index number>-this\_fixes\_bug\_foo\_and\_bar.patch
+\item if several, they have to be indexed with an integer number : 100-patch1, 200-patch2 ...
+\end{itemize}
+
+Your patch will be read and most likely be used as-is by the developpers if it is clean and working. If not, the patch will be accepted anyway and modified to be OpenWrt-rules compliant
 
 \subsubsection{Closing a ticket}
 
 
 \subsubsection{Closing a ticket}
 
-A ticket might be closed by a developper because :
+A ticket might be closed by a developer because:
 
 \begin{itemize}
 \item the problem is already fixed (wontfix)
 \item the problem described is not judged as valid, and comes along with an explanation why (invalid)
 
 \begin{itemize}
 \item the problem is already fixed (wontfix)
 \item the problem described is not judged as valid, and comes along with an explanation why (invalid)
-\item the developpers know that this bug will be fixed upstream (wontfix)
+\item the developers know that this bug will be fixed upstream (wontfix)
 \item the problem is very similar to something that has already been reported (duplicate)
 \item the problem is very similar to something that has already been reported (duplicate)
-\item the problem cannot be reproduced by the developpers (worksforme)
+\item the problem cannot be reproduced by the developers (worksforme)
 \end{itemize}
 
 \end{itemize}
 
-A the same time, the reporter may want to get the ticket closed since he is not longer able to trigger the bug, or found it invalid by himself.
+A the same time, the reporter may want to get the ticket closed since he is not 
+longer able to trigger the bug, or found it invalid by himself.
 
 
-When a ticket is closed by a developper and marked as "fixed", the comment contains the subversion changeset which corrects the bug.
\ No newline at end of file
+When a ticket is closed by a developer and marked as "fixed", the comment contains 
+the subversion changeset which corrects the bug.
This page took 0.024951 seconds and 4 git commands to generate.