PiTiVi: Let's go faster!

As I said in the last release announcement post, the PiTiVi community needs changes in the releasing process, and as newly appointed release manager I have the primary goal of making the development as dynamic as possible. The last release cycle lasted 8 months, which is way too long when we are supposed to be following the "release early, release often" philosophy. Avoiding it, is something we really want to work on, but I think a little explanation of why it happened is well needed:

• We had blocker bugs that could only be fixed by the main developers, and it was difficult for them to do so.
  
• The person in charge of releasing was much too busy to do the job, which is why I have now been appointed as new release manager and will do my best to find the time to do it well.
  
• We did not have any release schedule, which meant that we did not have any obligation concerning releases.
  

Also I want to explain a few of the reasons why I do believe this is something we really want to avoid:

• Users think nothing is happening, that the project is dying. Yet, as the activity on our git repository shows, rumors of our death have been greatly exaggerated.
  
• Potential contributors are hesitant to invest in the project because they think the project is dormant.
  
• Without a feature freeze, bugs tend to accumulate as new features land Contributors may be discouraged by the fact that they do not see their work reach the users quickly enough.
  
• There are many more reasons, as you can guess, but listing them all here would take too much time and I would have to delay the release ;-)
  

Therefore, we decided to take a set of measures concerning our release process to keep our current developers active and attract as many new contributors as possible. So here are the changes that are going to occur in the near future:

• First and foremost, starting from now, PiTiVi should follow the Gnome release schedule. This is not going to be easy, since our manpower is quite limited, but this is something that is really needed to ensure a healthy development pace.
• Have an official patch review policy: we want to "guarantee" that any patch that is sent to us will be reviewed *within 3 weeks*. This is also a great opportunity for new contributors who have experience in programming in general and would like to start by reading and improving other's code. Collaboration towards making a great patch is a great motivator! Upholding this goal will be a challenge, and your help in reviewing patches is very welcome.
  
• We want to make sure that deprecated libraries or broken/unmaintained features get removed as fast as possible. Dead code must die.
  

The project is pretty active these days, and I believe it is the right time to get those changes done. The feature list is becoming bigger and bigger and thanks to our very close relationship with the GStreamer multimedia framework, implementing new ones is becoming very simple. Also, the GStreamer community is very active and we are looking forward the GStreamer 1.0 release which should come out soon and will bring us new opportunities toward our goal of creating a video editor that can serve the needs of professional video editors.

So if you are interested in helping us making those changes happen, you are very welcome to have a look at our wiki page and our task list. I also warmly encourage you to join us on #pitivi on the freenode irc server, I am sure people will be happy to help you getting involved in this great software development project!