mirror of
https://github.com/openwrt/openwrt.git
synced 2024-12-27 17:18:59 +00:00
68 lines
3.2 KiB
TeX
68 lines
3.2 KiB
TeX
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:
|
|
|
|
\begin{itemize}
|
|
\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}
|
|
|
|
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
|
|
\item a specific software package would be seen as part of the official OpenWrt repository
|
|
\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:
|
|
|
|
\begin{itemize}
|
|
\item new package to be included in OpenWrt
|
|
\item fix for a bug that works for the reporter and has no known side effect
|
|
\item new features that can be added by modifying existing OpenWrt files
|
|
\end{itemize}
|
|
|
|
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.
|
|
|
|
\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}
|
|
|
|
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)
|
|
\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 cannot be reproduced by the developers (worksforme)
|
|
\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.
|
|
|
|
When a ticket is closed by a developer and marked as "fixed", the comment contains
|
|
the subversion changeset which corrects the bug.
|