Development Guidelines

If you plan to develop or suggest patches for Umit, you are invited to take a look at our Development Guidelines. The goal of this document is to help us keep things organized and well structured, so we can keep the Umit evolvement in an ascending pace, always.

These guidelines are under development. We're currently working to set all the useful guidelines here. If you have any doubts, contact us through our development mailing list, or drop by at our IRC channel.

Developers Meetings

Our goal is to place scheduled online meetings, where we can gather Umit's developers discuss the most important decisions, hunt some bugs, develop a new feature and close some tickets. As we're all volunteers, we can't dedicate 40h/week on the project, but I'm sure we can manage to provide 4/5 hours per week on these meetings so keep the development pace. All meetings are going to be previously scheduled in this wiki page, so we can all manage to attend.

The meetings are going to be held on our IRC Channel, and as our developers live in different time zones (with time zones varying from GMT-3 to GMT+8), we'll consider the GMT as official time zone. If we find any problem with this time zone, we're open to change it in order to facilitate the attendance of the higher number of developers.

Sending and Commiting Patches

  • Patches should be sent only after creating a ticket
  • The patch must be attached to the ticket created, instead of being sent to our mailing list
  • If you are a developer with commit rights, you are not allowed to commit patches written by another developer with commit rights
  • If you are a developer with commit rights, who sent a patch, you better commit it within 24 hours you got the aproval of your patch. Failing to do that, the last statement is revoked, and any developer with commit rights should commit it.
  • Before applying a patch, some discussion should take place. We don't intend to discuss everything, sometimes all we need is at least one person revising and testing your code to ensure everything is ok.
  • Don't suppose that everything is a bug. Sometimes, we have do take some wierd paths to make everything work on multiple platforms. Ask before considering something already developed as a bug or defect.
  • Read our Development Style Guide prior to code anything.
  • If you have any doubts, ask on our development [[lists|mailing list] or drop by on our [wikiirc IRC Channel]].

Namespaces

In order to ensure a constant growth and code quality, the community decided upon mailing list discussion the new namespace. All softwares under Umit Project umbrella should comply with this new namespace structure, and all future ones as well.

Every module, must have the "umit." prefix in its name. That's the main root for all library, module or package that we currently maintain or that one day we may maintain.

It is then, necessary to ponder on the following namespace based on the scope of the software, module, package or library. For example: if it is something related to Umit Network Scanner, than it should go under "umit.scan.". If it is a GUI related code, it should go under "umit.scan.gui.". If it is related to Umit Network Scanner main interface, it should remain there ("umit.scan.gui"), otherwise, if it is related to a brand new feature named FooBar, for example, then it should go under "umit.scan.gui.foobar".

The first part, umit, stands for Umit Project, and it keeps lifetime reference to our Organization. The second part, scan, stands for our Umit Network Scanner which is a scope smaller than umit. The logic should follow the same rule until the end of the tree, and the developer should always try to think about its code and were it is supposed to be used before creating its namespace. Any doubts, don't hesitate on asking for help in our development mailing list.

In order to create your namespace, all you should do is to create the respective directories, and put the necessary init.py files in each directory to ensure that you have an importable module. Supposing that a developer wants to create the following namespace: "umit.foo.bar.gui"

$ mkdir -p umit/foo/bar/gui
$ touch umit/+init+.py
$ touch umit/foo/+init+.py
$ touch umit/foo/bar/+init+.py
$ touch umit/foo/bar/gui/+init+.py

After taking these steps, he may start developing his brand new GUI module inside umit.foo.bar.gui.

By the time this document was written, the current namespace was according to the following:

  • umit -> This is the base module name for the namespace.
    • umit.higwidgets
    • umit.db -> Currently this module is inside umit.db in the trunk. Only the part related to Umit Network Scanner is going to be moved into umit.scan.db. The part that may be used by other projects must remain in umit.db
    • umit.plugin -> The current plugin module should be moved out of pm and umit, and be used by both through a unique namespace. The part related to pm or umit, should go under their respective namespaces (umit.scan.plugin and umit.pm.plugin)
    • umit.scan -> The scan refers to our scanning interface, which is Umit Network Scanner.
      • umit.scan.core -> Our current umit.core module
      • umit.scan.radialnet -> RadialNet
        • umit.scan.radialnet.core -> Our current umit.core.radialnet module
        • umit.scan.radialnet.gui -> The current umit.gui.radialnet module
      • umit.scan.qs -> Quick Scan
      • umit.scan.bt -> Bluetooth Scanner
      • umit.scan.zion -> The Zion frontend
        • umit.scan.zion.gui -> The Zion gui module
      • umit.scan.preferences -> Preferences Window
        • umit.scan.preferences.gui -> The Preferences Window gui modules moved into our main gui module.
        • umit.scan.preferences.core -> The main Preferences Window module
          • umit.scan.preferences.core.actions
      • umit.scan.ieditor -> Interface Editor
        • umit.scan.ieditor.gui -> The current umit.interfaceeditor module, but renamed to ieditor for short and moved into umit.scan.gui instead of feature the root umit.scan.
      • umit.scan.nse_facilitator -> NSE Facilitator
        • umit.scan.nse_facilitator.gui -> The current umitNSEFacilitator module, moved into our main gui module.
      • umit.scan.inventory -> Network Inventory
        • umit.scan.inventory.gui -> The Network Inventory, moved into our main gui module.
      • umit.scan.merger -> The current umit.merger
      • umit.scan.export -> The current umitExport module from Preferences Window branch
      • umit.scan.web -> The web interface for our network scanner
        • umit.scan.web.control -> The control layer of the web interface scanner
        • umit.scan.web.view -> The view layer of the web interface scanner
      • umit.scan.gui -> Our current umit.gui module
    • umit.common -> Here we should put the common parts, like I18N, config files manipulation, Nmap XML files manipulation, etc.
    • umit.zion -> The Zion backend
      • umit.zion.core
      • umit.zion.db
      • umit.zion.out
      • umit.zion.scan
      • umit.zion.sp
    • umit.umpa -> The UMPA library.
      • umit.umpa.extensions
      • umit.umpa.protocols
      • umit.umpa.sniffing
      • umit.umpa.utils
    • umit.bt_sniffer -> The Bluetooth Sniffer library.
      • umit.bt_sniffer.core
      • umit.bt_sniffer.firmware
    • umit.pm -> The Packet Manipulation Interface.
      • umit.pm.backend
      • umit.pm.core
      • umit.pm.gui.bt_sniffer -> Bluetooth Sniffer interface.
      • umit.pm.gui
      • umit.pm.manager
      • umit.pm.moo