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
