| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667 |
- 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.
|