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 mailing list, or drop by on our IRC Channel.