Hi there!
First of all, since I'm moving my job I'm using my free time and energy
focusing on this change, so I'm delaying the OpenID test writing for
now, sorry.
Then, I would like to start a discussion of a feature I always missed in
Gitorious. That discussion is also in alignment with the recent concerns
about Gitorious versioning.
Mailing list are ineffective as an issue tracking system and Gitorious
definitely needs an issue tracking system.
Writing a good tracking system from scratch and integrating it to
Gitorious is too much work. That means it won't happen any time soon. It
also means more code to maintain.
Using an external issue-tracking system integrated to Gitorious, as the
Ruby language does with Redmine, seems to be the way to go for now.
Have been using Redmine for 4 years now (and its fork Chiliproject more
recently), I can tell you it is a comprehensive issue tracking system,
supporting roadmap, versioning, wiki, forum, documents, attachments, VCS
(SCM) integration and several interesting plugins like scrum-pm and many
others. It is amazing for various reasons (I'll list only the ones I
think apply to Gitorious, skipping subprojects, time-tracking, etc):
- clean interface (really!)
- fast (specially from a user's perspective)
- easy to install and set up
- a lot customizable (really!)
- flexible role-based access control and flow settings
- gantt/calendar
- easily extensible with plugins
- translated to several languages (user preference)
- notifications by e-mail of issues and activities being watched
according to user's preference
- RSS feeds for lots of items like project tasks, my tasks, news,
commits, activities among others
It has good test coverage and I've never seen any problem with Redmine
or Chiliproject itself (I use some other plugins that are neither well
written nor have a test suite).
I would recommend Chiliproject over Redmine for some reasons:
- Chiliproject fork seems to have more contributors;
- the main repository is tracked with Git (Redmine is tracked with
Subversion), which makes it easy to contribute in my opinion;
- dependencies are managed with Bundler already (both still use Rails 2.3).
So, I'd like to suggest that we created a chiliproject.gitorious.org or
issues.gitorious.org for managing Gitorious issues, versioning and roadmap.
Of course that, being a separate application, it would only apply to
Gitorious itself and not for projects hosted in Gitorious.org, but that
is a start already. We can include this integrated issue tracking system
per Gitorious project in some roadmap.
We could start registering some planning already, like the suggested
roadmap (I'm using the 3 numbering scheme, but it doesn't matter for
what I'm talking about):
Version 1.0.0 - current version
Version 1.1.0:
- migration to Rails 3
- migration to Devise
- replacing of several plugins by new ones and new APIs like
the ones written for searching and queuing.
Version 1.2.0:
- support for more authentication systems integration, like LDAP
and others supported by OmniAuth
Version 1.3.0:
- JRuby support
- one-click-install
Version 1.4.0:
- support for multiple languages instead of defining a single
language in gitorious.yml
- changing locales/language.rb to locales/language.yml (maybe this
should go to 1.1.0 or 1.2.0)
- add some integrated issue tracking system per project
These version numbering suggestions will of course depend on Gitorious
priority, demand and availability from developers that will work on each
feature. But we'll be able to get more feedback and contributions this
way... Relying only in a mailing system is a very poor feedback solution.
Thoughts?
--
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com
