Better web site integration (bug tracker + wiki)


My name is Augustin and I use kdenlive on Kubuntu :)

I am also a Drupal developer, so I know Drupal very well. I developed many modules for Drupal.

I would like to post a follow up to the following thread:

I definitely think that for the good of the kdenlive project, the whole web site should be fully integrated. Users are more likely to contribute something if they don't have to use different logins for each part of the site. So this site should definitely use the Drupal bug tracker to replace Mantis. It might be a bit of work to do so at the beginning, but the long term benefits are worth it. We don't need to import all mantis bugs into the new bug tracker. The Mantis bug tracker can be cleaned little by little, as bugs are actually fixed and duplicates created in the new Drupal bug tracker.

Also, this web site should definitely have a wiki (a simple node type called 'wiki' should be enough to start with), to encourage users to improve on each other's tutorials. The tutorials themselves and the user manual should be like a wiki, editable by every (trusted) member.

Finally, I am not particularly fond of forums. Too much information is lost in active forums... but that's something I'd like to discuss later, after the rest of the web site is properly integrated.




Thanks for your remarks.

1) Drupal bug tracker is installed. Unfortunately, PHP is configured with 48M in each process, too little to load all Drupal code. I wrote jbm and I am waiting for the answer. We need 96M or 128M by PHP process maximum. Maybe a solution would be to change hosting companies. OVH is France is providing very cheap services.

2) Documentation is implemented in books. Everyone can ask for priviledges. But we should shoot video tutorials explaining how to write documentation.

3) I agree that forums are a loss of time compared to writing documentation. But it can act as a central point to discuss. The first goal would be to write documentation.

Before discussing further, I would like to solve this PHP memory issue.


Bonjour Jean-Michel,

It's good to know that you've planned to use the integrated bug tracker.

I am hosting my Drupal sites at dreamhost , where the memory limit is 90M by default but can be overridden with .htaccess. In any case, the memory is sufficient for my Drupal sites (inc. the project_issue.module).

You are using Drupal 6, right? There is no official release for the project*.modules. Have you checked that nothing in the following list of issues could be a problem for you?
Because of the lack of official, stable release for D6, my own sites are still using Drupal 5.

Btw, I wanted to write to you over a year ago, to advise you to use Drupal to integrate forum and bug tracker. I'm glad that you found your way here yourselves :)

I would like to state that I am against migrating the issue tracker to the versions of drupal issue tracking that I have seen. You should be able to demonstrate that drupal issue tracking can solve at least the problems that mantis issue tracking solves. That was not the case, last time we discussed this:

Feel free to hack something together to support single-login, but also note, that we do get a large number of bugs registered *even* with dual logins. More than the developers can really handle, it seems.



The point of having an integrated bug tracker is precisely to allow the wider, non-developer community to be able to help more effectively, e.g. by allowing users to help each other and transform support requests that litter the forums to be translated into better documentation.

But if you are against it, then I will not insist. I believe it will be in the long run a big loss for kdenlive generally, and for its developers specifically.

Now, it's up to whomever is making the decisions around here.

In the thread you point to, you only seem to care about single login. This is obviously crucial, but it's far from the only benefit of having a fully integrated web site.

Also, I repeat that I don't believe that migrating all the existing bugs is necessary. In any case, this is something that the non-developers could help you with. The developers only need to concentrate on what they do best and that others cannot do instead of them: coding and squashing bugs.