Gitorious Versioning, Roadmap, Issue Tracking: Chiliproject or Redmine
Rodrigo Rosenfeld Rosas
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?
Benjamin Podszun
Interested user only, no idea what my word's worth here.. ;-)
On Sun, Jul 3, 2011 at 3:23 PM, Rodrigo Rosenfeld Rosas
<rr.r...@gmail.com> wrote:
> 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.
Hell, yes.
> 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.
I'd welcome to see this. First, just as a central place to learn about
the current status of gitorious:
- We, the users, can see the roadmap, can track issues and see what's
fixed in which version/tag
- You, external contributors, can manage their spare time work much
more effectively
Of course, integrating a decent issue tracking system into gitorious
(in the future) would be awesome as well. Internally in my company
we're currently deploying gitorious and redmine, but so far gitorious
is mostly used to search for code/administrate repositories, while
redmine gets the heavy traffic (and is integrated via post-commit
hooks to update tickets from commit messages etc). So - I'm currently
torn about integrating redmine. Looking at user stories, you'd end up
stuffing the tool that 'does more' (for the enduser, at least) into
the slimmer/leaner one.
But for now, to have a better gitorious project status page: Great
idea in my tiny world.
Ben
Guilhem Bonnefille
> 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.
Of course, external issue-tracking is probably the most simple
solution. But why not promoting more and more distributed model? I
know that many distributed issue tracking tools exist. Why not
selecting and integrating one with gitorious? This would give
gitorious many advantages over other solution.
At the same time, you can regularly ignore my proposition as I do not
have any spare time to invest on this topic.
--
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_b...@hotmail.com
-=- mailto:guilhem.b...@gmail.com
-=- http://nathguil.free.fr/
Rodrigo Rosenfeld Rosas
> 2011/7/3 Rodrigo Rosenfeld Rosas<rr.r...@gmail.com>:
>> 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.
> Of course, external issue-tracking is probably the most simple
> solution. But why not promoting more and more distributed model? I
> know that many distributed issue tracking tools exist. Why not
> selecting and integrating one with gitorious? This would give
> gitorious many advantages over other solution.
Could you be more specific? Is there any specific tool you're talking
about. The ones I've seen cannot be compared to Redmine or Chiliproject
powerness...
What kind of benefits do you see in those distributed issue tracking
alternatives?
Guilhem Bonnefille
The simple answer: the same benefits as distributed version control.
The longer:
- synced with source code
- stored in the history (backup, local/forked bugs...)
- simply editable (vi/emacs is enough)
The matter is the lack of high level GUI. And, IMHO, a tool like
gitorious can do this.
Rodrigo Rosenfeld Rosas
Exactly! That is why I still would go with Redmine or Chiliproject since
their UI is awesome and UI is critical for this kind of system IMHO.
Also, delegating such a task to Gitorious is way too much extra work to
maintain IMHO and I would instead prefer some mountable application
based solution now that Rails 3.1 will support this concept as some
frameworks already do for Python, for instance...
Christian Johansen
Thanks for the initiative! See my responses below.
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.
Nothing to be sorry about. Thanks for keeping us updated.
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.
Agreed.
So, I'd like to suggest that we created a chiliproject.gitorious.org or issues.gitorious.org for managing Gitorious issues, versioning and roadmap.
This is a great suggestion. We've been delaying a decision in issue tracking for a long while, and I think it's time to just pick something and get started. We can always move later.
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.
A roadmap of some sort is a good idea. I don't think we'll be able to pin features down in such a detailed way, but we could at least advertise features in planning, have a discussion about them and indicate timespan for deployment of such features. We will also get started on documenting changesets and version numbers ASAP.
I will look at getting a Chiliproject setup up and running shortly, maybe I have some more feedback after that.
As for the discussion on issue tracking and Gitorious in general: I agree that if/when issue tracking becomes a part of Gitorious (pluggable in some way) - i.e. something we offer projects hosted with us - shipping something which is distributed is key. We've been mulling over this a lot, and even looked at a few such systems backed by Git. I don't know yet exactly how it would work, but I want an issue tracking system that:
- stores issues in plain text (so they can be put in Git)
- can be distributed
- has a CLI for programmer efficiency
- has pluggable nice UI for stake-holders
Christian
Guilhem Bonnefille
> As for the discussion on issue tracking and Gitorious in general: I agree
> that if/when issue tracking becomes a part of Gitorious (pluggable in some
> way) - i.e. something we offer projects hosted with us - shipping something
> which is distributed is key. We've been mulling over this a lot, and even
> looked at a few such systems backed by Git. I don't know yet exactly how it
> would work, but I want an issue tracking system that:
>
> stores issues in plain text (so they can be put in Git)
> can be distributed
> has a CLI for programmer efficiency
> has pluggable nice UI for stake-holders
>
> Obviously, as Rodrigo said, we likely won't be able to build something like
> that any time soon, but for what it's worth, these are some of my ideas on
> the topic.
So, please, take a look at ditz: http://ditz.rubyforge.org/
It's ruby.
It has plugable system.
It offers UI.
And it's a distributed issue tracking.
Wari Wahab
working and gitorious can look into this and show issues related to the
repo (or project if needed). Thanks for the pointer.
Rodrigo Rosenfeld Rosas
> ...
> I will look at getting a Chiliproject setup up and running shortly,
Feel free to count on me on this task if you need any help.
Best regards!
Pedro Kiefer
Having a pluggable system, for supporting chiliproject, redmine, jira, bugzilla, or some other issue tracker is probably the best solution on the long run.
Just my 2 cents.
Cheers,
Pedro
--
To post to this group, send email to gito...@googlegroups.com
To unsubscribe from this group, send email to
gitorious+...@googlegroups.com
Rodrigo Rosenfeld Rosas
> I don't see any advantage in having a distributed issue tracker, maybe
> there are some, but I think issue tracking is a central and unique
> service. You don't want (at least I don't see a reason for) Q&A,
> testing and management to have a clone of your repositories for adding
> bug reports. And you definitely don't want to have some issues added
> to a fork and not the main repository.
>
> Having a pluggable system, for supporting chiliproject, redmine, jira,
> bugzilla, or some other issue tracker is probably the best solution on
> the long run.
That's exactly what I think too.
Nagaraj
I am trying to integrate gitorious and chiliproject!
>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.
We are integrating chiliproject with gitorious, our aim is when a
project is created in gitorious corresponding issue tracking must be
created in chiliproject. We would like to have links(gantt/calendar,
issues, forums,etc...) from gitorious to chiliproject and vice versa.
We are eagerly looking for community support.
Thanks & Regards
Nagaraj P G
Rodrigo Rosenfeld Rosas
> Hi all,
>
> I am trying to integrate gitorious and chiliproject!
Great news! I was willing to do that after Gitorious has upgraded Rails
from 2 to 3.
Is the source-code somewhere?
Best regards,
Rodrigo.
>
>> 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.
> Yes I agree.
>
> We are integrating chiliproject with gitorious, our aim is when a
> project is created in gitorious corresponding issue tracking must be
> created in chiliproject. We would like to have links(gantt/calendar,
> issues, forums,etc...) from gitorious to chiliproject and vice versa.
>
> We are eagerly looking for community support.
>
> Thanks& Regards
Nagaraj
we are still going through the applications, db tables...
if somebody is doing please guide us.
Christian Johansen
So, please, take a look at ditz: http://ditz.rubyforge.org/
It's ruby.
It has plugable system.
It offers UI.
And it's a distributed issue tracking.
I have looked at it, and I find it very interesting. If memory serves me right, I think the missing piece in Ditz was the UI. But that can be built on top of it later anyway I guess.
Anyway, we're now concentrating on getting issues.gitorious.org up and running, and then we'll deal with issue tracking integration for projects later.
Christian
Rodrigo Rosenfeld Rosas
and I still want to help Gitorious to upgrade Rails, so I'll post-pone
my help.
But, if you need some assistance or want to discuss some approaches,
feel free to talk with me.
Best regards, Rodrigo.
Christian Johansen
I have now released Gitorious 2.0.0, a versioning "manifesto", an upgrade guide and an issue tracker :) Will make a separate post to announce these things.
Christian
--
To post to this group, send email to gito...@googlegroups.com
To unsubscribe from this group, send email to
--
MVH
Christian
Rodrigo Rosenfeld Rosas
> Hey guys,
>
> I have now released Gitorious 2.0.0, a versioning "manifesto", an
> upgrade guide and an issue tracker :) Will make a separate post to
> announce these things.
>
Great work, Christian! I'm awaiting for your approval in
issues.gitorious.org. Is there any reason why it is necessary to get the
administrator's approval?
Christian Johansen
Great work, Christian! I'm awaiting for your approval in issues.gitorious.org. Is there any reason why it is necessary to get the administrator's approval?Hey guys,
I have now released Gitorious 2.0.0, a versioning "manifesto", an upgrade guide and an issue tracker :) Will make a separate post to announce these things.
Hmm, did it say explicitly to wait for admin approval? That's not intentional. I just discovered that the server had no mail configuration, so maybe your activation mail got lost? Fixed both problems now, so you're activated.
Christian
Rodrigo Rosenfeld Rosas
Nagaraj
I am trying to integrate chiliproject with gitorious. The gitorious has project edit controller which lets users to specify bugtracker url, mailing list url. How can I generate the same projects in chiliproject? We need to have same user model for both applications.
Please guide me to start the Integration of both application.
I am using
Ruby on Rails Version: Ruby Enterprise Edition 2011.03
Server : Passenger + nginx
I use bundler to install gems.
gitorious : git clone git://gitorious.org/gitorious/mainline.git
chiliproject: git clone git://github.com/chiliproject/chiliproject.git
OS: Scientific Linux 6.1
Thanks
-- Nagaraj
Rodrigo Rosenfeld Rosas
not straightforward.
But I just don't have time right now for working on that...