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.h...@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 - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
