Bug/issue tracker for OC development

[totsubo]

Quick question, do we have a bug/issue tracker for OC?

If not should we set one up? Do people have a preference or recommendation for an issue tracker?

[mic@]

Quick question, do we have a bug/issue tracker for OC?

We here at opencaching.de use RT ("Request Tracker") for email requests, bugs, features, to-do etc.
More information is available at http://requesttracker.wikia.com/wiki/HomePage
Or write an email to contact@opencaching.de and see it in live action 

[totsubo]

I'm familiar with RT and like it very much (along with Bugzilla; they have the cutest mascot!).

Does it make sense (and do people think it is worth the effort) to start an instance up for 'global' OC development issues?

I'm willing to offer up my site to set up an instance. (I have 0 experience setting up RT but it shouldn't be that hard, right?)

[oliver]

Does it make sense (and do people think it is worth the effort) to start an instance up for 'global' OC development issues?

I'm willing to offer up my site to set up an instance. (I have 0 experience setting up RT but it shouldn't be that hard, right?)

I think setting up bugtracker will make sense as soon as we start to write the common source. At the moment there are 2 spereate source code versions - having todo's of each code in one repository will be confusing. RT is nice ticket system and we use it for todo-management because i dont want to administrate a second (or third) system ... but for the common source, it would make sense to invest some time in a real good bugtracking solution.

[totsubo]

Oliver, you make some good points.

It seems that the blocking task at the moment is the merge of the code. Is there any way I can help with that? Is there a forum for that particular task or something in the bug tracker.

I'm willing and able to get my hands dirty with the code and contribute to getting the merge done. Just point me in the right direction

[oliver]

In my opinion, the following task have to be decided:

1. How do we decide what to do? (and who decides)

My problem at the moment is that i dont know who is the right person to talk with (in details). We have 2 big nodes (.de and .pl) and some smaller and newer ones (.cz was online before .pl, but .pl has more users). Is it okay to have 3 or max. 4 peoples that decide what way to go? Will the others accept that decision? We can discuss months about what solution is the best in theory - but best solution is nothing, if we dont start. The migration will cost a lot of time and we cannot invest that time to do other things. There may be a third alternative like using Zend-Framework. Wheter to use AGPL, GPL or something other.

2. What template engine to use?
(OC-handmade engine, smarty, zend, ...)

3. What license to use?

4. Public repository or not?

5. How to controll quality of source (code reviews, tests etc.)

6. Real modular system or very fine graded configurable system?

7. Object modell and database layer selection (like ORM or other patterns)

8. Choosing repository system (SVN, GIT or the other one)

Some of that decisions should be done by those peoples that have to work with the new source and have some coding experience with the OC code(s) and other sources. It might be required to know what the different OC sources already have implemented and how they are structured - we have to decide if we start from scratch or improve existing code. I started two times from scratch. The first time in 2003 and the second time in 2007. I know the required effort to bring the system into production use and how much work is required to implement all the neat stuff. If i would start from scratch again today, i would do some things in another way (if not, i would have learned nothing from the last 3 years). But it is required or can the existing code handle the changed requirements?

When we have done these decisions, we should start a new repository and (eventually) copy into that repository the existing codes (file by file, 100% review). One of the most important parts is to look very carefully to act within the choosen license and that we dont use codes that does not match into that license.