Just thought of another thing. The target version, which i believe we will use for our fix for version, should also be multi-selectable. This is for the case where we fix an issue in a maintenance release. For example we will have an issue that we are fixing in 1.1.3, 1.2.1 and 1.3
- Justin On 2010-08-25, at 1:03 PM, Justin Obara wrote: > I've played with Redmine a bit more, and have a few more comments. > > Areas we need to address, some of these may have been mentioned before. > > Can't see commits to a specific issue from the issue itself > This could be due to the fact that the issue numbers no longer match > No "Affects Version" option > Needs to be multi-selectable > Needs to contain all version numbers > Can't change the default order of the fields displayed when viewing a list of > issues. > You can select which fields to show, but not the order they appear > We need a way to preserve all of our old Issue Numbers from Jira > This is to preserve references from our mail archives and other places > Should each project have their own numbering, rather than have them all > increment together? > Can't create filters based on description or comments > We use this in jira to "tag" issues for bug parade and other speciality > filters > Categories aren't multi-selectable. Can only assign a single category to an > Issue. Some of the issues are cross cutting > > I've also found a few plugins that might be useful, but I'm not sure how good > they are. > > Code Review > http://www.redmine.org/boards/3/topics/9627 > > Drafts > http://www.redmine.org/boards/3/topics/13930 > > Screenshot Paste > http://www.redmine.org/wiki/redmine/PluginScreenshotPaste > > Thanks > Justin > > On 2010-08-23, at 10:14 AM, Jamon Camisso wrote: > >> 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.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
