Redmine and Jira

Mon Aug 23 14:14:24 UTC 2010

Hi Justin,

Interesting that the custom field option applies to all projects. What
about making a list of versions prefixed with the project identifier
e.g. [engage] 0.3. This seems inelegant, but if moving to Redmine is a
viable option given some work, I'll write the plugin myself :)

Jamon

On 08/23/2010 10:04 AM, Justin Obara wrote:
> Hi Jamon, 
> 
> So it seems that it doesn't have a means for specifying the affects versions. I did some googling and found that this is a feature that a bunch of people seem to want. Here's a link to a feature request filed for it.
> 
> http://www.redmine.org/issues/1675
> 
> Hopefully this will be implemented soon, although the request was made over 2 years ago.
> 
> Thanks
> Justin
> 
> On 2010-08-23, at 9:50 AM, Jamon Camisso wrote:
> 
>> Hi Justin,
>>
>> You're correct that version numbers are in the admin section for a
>> project, I've added 0.3 and 0.4 for Engage. If you login (details
>> forthcoming) and take a look at
>> <http://redmine.fluidproject.org/issues/592> you'll be able to update
>> the issue and assign a version number to it. I'm not sure if reimporting
>> would pick up on the numbers now or not.
>>
>> Jamon
>>
>> On 08/23/2010 09:28 AM, Justin Obara wrote:
>>> Hi Jamon,
>>>
>>> Another thing that seems to be missing, but could just be due to the import, is the version numbers. In Jira we are able to specify the affects versions (what versions does a particular bug affect) and the fix for version (when will/was a bug fixed). There seems to be a field for target version. I would assume this is akin to Jira's fix for version; however, none of the issues seem to have this populated. 
>>>
>>> As Antranig mentioned there may be more features that are locked away in an admin section. I don't remember if you've setup an admin account for me or not, but could you help me get access to the admin section. 
>>>
>>> Thanks
>>> Justin
>>> On 2010-08-20, at 1:38 PM, Jamon Camisso wrote:
>>>
>>> Hi Antranig,
>>>
>>> On 08/19/2010 11:24 PM, Antranig Basman wrote:
>>>>>> Hi there Jamon - thanks a lot for this experiment. I have to say at the
>>>>>> outset I am quite pleased with Redmine... the rendering is a bit
>>>>>> simplistic, but at the very least it is VERY QUICK. I could never
>>>>>> understand why after so many years Atlassian showed such desultory
>>>>>> interest in improving their really pretty incompetently slow load times.
>>>>>> Pages on Redmine load pretty much instantly whereas even on a pretty
>>>>>> fast connection I could wait 3-4 seconds before seeing any rendering on
>>>>>> even a simple JIRA or Confluence page.
>>>
>>> Jira 4 was a major regression in that respect, I attempted to optimize
>>> Postgresql for Jira as well, but it made little difference. I'm
>>> cautiously optimistic that performance with Redmine which uses Ruby on
>>> Rails will remain better.
>>>
>>>>>> That said, I see a few important things missing that will make life a
>>>>>> bit difficult - for example although redmins supports the concept of a
>>>>>> "category" which I guess is the JIRA equivalent of a "component", it
>>>>>> doesn't allow you to easily navigate to a set of issues that relate to
>>>>>> that component. Also the JIRA feature of being able to prefix an issue
>>>>>> with a "project code" such as FLUID, ENGAGE, or KETTLE was crucially
>>>>>> useful to be able to keep issues referred to unambiguously when working
>>>>>> on several projects. For example right now for me it is very important
>>>>>> to be able to distinguish between CSPACE and FLUID issues.
>>>
>>> I've edited the issue view and added [<%= @project.identifier %>] which
>>> will output something like [deca] Bug #123. The number isn't tied to the
>>> Tracker (bug) or the identifier (deca), but at least the information is
>>> present as to what belongs where now.
>>>
>>>>>> The rendering of diffs and direct views into the repository are a very
>>>>>> nice and welcome feature -
>>>>>> http://redmine.fluidproject.org/projects/fluid/repository/revisions/9992/diff/trunk/src/webapp/components/pager/js/Pager.js
>>>>>>
>>>>>> this aspect reminds me of "trac" but redmine feels a bit better put
>>>>>> together than trac - although I will reserve judgement until I can try
>>>>>> out the wiki :)
>>>
>>> Redmine will also work with Git, Mercurial, Bazaar, Darcs, CVS given the
>>> correct URIs and credentials.
>>>
>>>>>> The "activity" view is great. A joint stream of SVN and JIRA events is a
>>>>>> really helpful resource.
>>>
>>> As with other systems, linking to a specific revision or file is
>>> possible using a few keyword/symbol operators. Consider:
>>>
>>> fluid-engage-kettle/trunk/src/main/webapp/services/kettleDemo/html/kettle.html
>>>
>>> To view it in the repository viewer, there are multiple options:
>>> First is to use source:@8582 which will browse to the root of the SVN
>>> repository for revision 8582.
>>>
>>> Another option is to specify a file like:
>>> source:trunk/src/main/webapp/services/kettleDemo/html/kettle.html
>>>
>>> Combining the two, to view a specific line number of a specific revision
>>> of a file one would use:
>>> source:trunk/src/main/webapp/services/kettleDemo/html/kettle.html at 8582#L29
>>>
>>>>>> Sadly the handling of URLs for search views is no more competent than in
>>>>>> JIRA. For example in trying to create a view of "Framework" issues,
>>>>>> after I apply the necessary filter, I get to yet another unbookmarkable
>>>>>> view of the form
>>>>>> http://redmine.fluidproject.org/projects/fluid/issues?set_filter=1&tracker_id=1
>>>>>>
>>>>>> You'd think that developers would start learning how the web was meant
>>>>>> to work after a mere 20 years.
>>>
>>> There is a feature complete REST API - I can envision using IRC to
>>> update/retrieve issues on the site.
>>>
>>>>>> It's possible that some of these issues could be resolved by some
>>>>>> configuration - or it might be, that, like JIRA, quite a few features
>>>>>> are mysteriously "invisible" until you get an account and log on. It
>>>>>> looks like my account is already imported, so if you could send me the
>>>>>> details I'd be interested in trying it out further. Also I'd like to try
>>>>>> out the wiki features but only get 404s so far when I try to navigate in
>>>>>> - I'm much more dissatisfied with Confluence than I am with JIRA. I'm
>>>>>> excited that the Redmine developers are open to accessibility work - and
>>>>>> perhaps they would be more responsive to general feature requests too.
>>>
>>> Those 404 errors are because there is no content at the moment.
>>> Migrating from Confluence to Redmine is an option, but it would take
>>> everyone pitching in and copying a few pages over to share the work. I
>>> would be elated to move off maintaining Confluence in terms of
>>> maintaining sites. Redmine code lives in Git and SVN, and upgrades
>>> between versions are as simple as a git checkout in place.
>>>
>>>>>> Overall I am impressed - I'm not sure I'm confident trusting all of our
>>>>>> issue tracking to it immediately. I guess the only real "blocker" in my
>>>>>> view is the lack of project prefixes on issue numbers. That seems to be
>>>>>> a "must have" JIRA feature. Hopefully one can't patent something so
>>>>>> trivial :)
>>>
>>> Glad you like it so far. I've put those prefixes into the template and
>>> set you up as an administrator so you can have full access. I agree that
>>> it will take some time and more testing to get a feel for Redmine, and
>>> that switching systems is not something to take lightly.
>>>
>>> Regards, Jamon
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>
> 