future roadmap
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
future roadmap
by thebugslayer
::
Rate this Message:
Hi Peter,
I really like to see jTrac providing similar features that Trac(python) provides. Wiki+Issues+Subversion are just a must have, attractive combo for any project management. I would trade war deployment vs TracInstall anytime. Any news as to jTrac's future roadmap and release? -- theBUGslayer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users |
|
|
Re: future roadmap
by ptrthomas
::
Rate this Message:
Hi,
Appreciate your interest and I completely agree that Wiki + Subversion is a must. JTrac development has admittedly slowed down over the last 2-3 months. Some patches have started to come in though and we hope to have development in full-swing very soon. (Day-job kinda getting in the way). Honestly never expected that something that sounds as simple as an issue-tracker would have so many layers to it :) Any ideas on the wiki-engine to embed would be welcome. I was thinking of Radeox, bit about it here: http://stephan.reposita.org/archives/2007/08/20/forking-radeox-a-new-wiki-render-engine/ Thanks, Peter. On 10/19/07, thebugslayer <thebugslayer@...> wrote: Hi Peter, ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users |
|
|
Re: future roadmap
by thebugslayer
::
Rate this Message:
Peter,
I have used VQWiki and XWiki (just as end user though) and they both are ready to use out of the box. VQWiki is simpler and lighter, while XWiki seems to be bigger but with larger user community with richer feature set. I have not dealt with Radeox. In regardless, I think one of the main attraction and good feature of any wiki should provide is API set to easily add different set of syntax parser. As we already know almost every engine out there has it's own syntax rules. Been able to a most popular rule like in Confluence etc, will allow user to migrate easily. -Zemian On 10/19/07, Peter Thomas <ptrthomas@...> wrote: > Hi, > > Appreciate your interest and I completely agree that Wiki + Subversion is a > must. > > JTrac development has admittedly slowed down over the last 2-3 months. Some > patches have started to come in though and we hope to have development in > full-swing very soon. (Day-job kinda getting in the way). Honestly never > expected that something that sounds as simple as an issue-tracker would have > so many layers to it :) > > Any ideas on the wiki-engine to embed would be welcome. I was thinking of > Radeox, bit about it here: > > http://stephan.reposita.org/archives/2007/08/20/forking-radeox-a-new-wiki-render-engine/ > > Thanks, > > Peter. > > > On 10/19/07, thebugslayer <thebugslayer@...> wrote: > > > > Hi Peter, > > > > I really like to see jTrac providing similar features that > > Trac(python) provides. Wiki+Issues+Subversion are just a must have, > > attractive combo for any project management. I would trade war > > deployment vs TracInstall anytime. > > > > Any news as to jTrac's future roadmap and release? > > > > -- > > theBUGslayer > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > j-trac-users mailing list > > j-trac-users@... > > https://lists.sourceforge.net/lists/listinfo/j-trac-users > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > j-trac-users mailing list > j-trac-users@... > https://lists.sourceforge.net/lists/listinfo/j-trac-users > > -- theBUGslayer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users |
|
|
Re: future roadmap
by Staffan Olsson
::
Rate this Message:
Hi,
I agree that every development project needs a documentation system that developers can update swiftly and as a community. However I must add to the debate that when I chose jTrac, one reason was that it is only an issue tracker. A documentation system is a different project. It may be the same developers and the same frameworks, but I can't see a reson for releasing them together. For a reason not to: look at the complexity of the Trac project. Features like bookmarkable URLs, single sign-on and XML/JSON services would allow integration with any documentation system. I personally prefer html documents in the svn repository and an option to edit online using tinymce or wymeditor. /Staffan On 10/20/07, thebugslayer <thebugslayer@...> wrote: > Peter, > > I have used VQWiki and XWiki (just as end user though) and they both > are ready to use out of the box. VQWiki is simpler and lighter, while > XWiki seems to be bigger but with larger user community with richer > feature set. > > I have not dealt with Radeox. > > In regardless, I think one of the main attraction and good feature of > any wiki should provide is API set to easily add different set of > syntax parser. As we already know almost every engine out there has > it's own syntax rules. Been able to a most popular rule like in > Confluence etc, will allow user to migrate easily. > > -Zemian > > On 10/19/07, Peter Thomas <ptrthomas@...> wrote: > > Hi, > > > > Appreciate your interest and I completely agree that Wiki + Subversion is a > > must. > > > > JTrac development has admittedly slowed down over the last 2-3 months. Some > > patches have started to come in though and we hope to have development in > > full-swing very soon. (Day-job kinda getting in the way). Honestly never > > expected that something that sounds as simple as an issue-tracker would have > > so many layers to it :) > > > > Any ideas on the wiki-engine to embed would be welcome. I was thinking of > > Radeox, bit about it here: > > > > http://stephan.reposita.org/archives/2007/08/20/forking-radeox-a-new-wiki-render-engine/ > > > > Thanks, > > > > Peter. > > > > > > On 10/19/07, thebugslayer <thebugslayer@...> wrote: > > > > > > Hi Peter, > > > > > > I really like to see jTrac providing similar features that > > > Trac(python) provides. Wiki+Issues+Subversion are just a must have, > > > attractive combo for any project management. I would trade war > > > deployment vs TracInstall anytime. > > > > > > Any news as to jTrac's future roadmap and release? > > > > > > -- > > > theBUGslayer > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > j-trac-users mailing list > > > j-trac-users@... > > > https://lists.sourceforge.net/lists/listinfo/j-trac-users > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > j-trac-users mailing list > > j-trac-users@... > > https://lists.sourceforge.net/lists/listinfo/j-trac-users > > > > > > > -- > theBUGslayer > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > j-trac-users mailing list > j-trac-users@... > https://lists.sourceforge.net/lists/listinfo/j-trac-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users |
|
|
Re: future roadmap
by Saurb
::
Rate this Message:
We have been using JTrac in our organization for over six months now with
encouraging results. I badly needed some of the new features introduced in 2.1. Unfortunately we could not migrate to 2.1 Beta due to bugs with the related item functionality! With the limited set of developers actively working on JTrac, we should concentrate on core features/bugs fixes rather than trying to build add-on features like a Wiki engine. WiKi is not an essential component of issue tracking. My personal opinion is that we should be able to figure out ways to integrate best of breed open source WiKis with JTrac rather than spending time trying to embed a WiKi within JTrac. I think interfacing with third party products (LDAP support, Subversion integration, etc.) will add more value that trying to embed them within JTrac. We also migrated to Subversion (from VSS) recently. Here is how Jtrac can integrate with Subversion: 1. TortoiseSVN client can be easily configured to prompt for a JTrac ID when checking in changes to the Subversion repository. With friendly URLs in JTrac 2.1, we can easily configure Tortoise to create a hyperlink to the JTrac item ID from the Subversion commit log. 2. Programmatically add a history record in Jtrac from a Subversion post commit trigger with the list of files that were checked in for a particular jTrac task. We use https to access Subversion. So we can easily link to a file in Subversion with a URL in Jtrac comment text. We will need JTrac to support HTML tags for this. Thanks, Saurabh -----Original Message----- From: j-trac-users-bounces@... [mailto:j-trac-users-bounces@...] On Behalf Of thebugslayer Sent: Saturday, October 20, 2007 7:21 AM To: JTrac users mailing-list Subject: Re: [jtrac-users] future roadmap Peter, I have used VQWiki and XWiki (just as end user though) and they both are ready to use out of the box. VQWiki is simpler and lighter, while XWiki seems to be bigger but with larger user community with richer feature set. I have not dealt with Radeox. In regardless, I think one of the main attraction and good feature of any wiki should provide is API set to easily add different set of syntax parser. As we already know almost every engine out there has it's own syntax rules. Been able to a most popular rule like in Confluence etc, will allow user to migrate easily. -Zemian On 10/19/07, Peter Thomas <ptrthomas@...> wrote: > Hi, > > Appreciate your interest and I completely agree that Wiki + Subversion is a > must. > > JTrac development has admittedly slowed down over the last 2-3 months. Some > patches have started to come in though and we hope to have development in > full-swing very soon. (Day-job kinda getting in the way). Honestly never > expected that something that sounds as simple as an issue-tracker would have > so many layers to it :) > > Any ideas on the wiki-engine to embed would be welcome. I was thinking of > Radeox, bit about it here: > > http://stephan.reposita.org/archives/2007/08/20/forking-radeox-a-new-wiki-re nder-engine/ > > Thanks, > > Peter. > > > On 10/19/07, thebugslayer <thebugslayer@...> wrote: > > > > Hi Peter, > > > > I really like to see jTrac providing similar features that > > Trac(python) provides. Wiki+Issues+Subversion are just a must have, > > attractive combo for any project management. I would trade war > > deployment vs TracInstall anytime. > > > > Any news as to jTrac's future roadmap and release? > > > > -- > > theBUGslayer > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > j-trac-users mailing list > > j-trac-users@... > > https://lists.sourceforge.net/lists/listinfo/j-trac-users > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > j-trac-users mailing list > j-trac-users@... > https://lists.sourceforge.net/lists/listinfo/j-trac-users > > -- theBUGslayer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users |
|
|
Re: future roadmap
by rafaeluchoa
::
Rate this Message:
Saurabh Banerjee escreveu: > We have been using JTrac in our organization for over six months now with > encouraging results. I badly needed some of the new features introduced in > 2.1. Unfortunately we could not migrate to 2.1 Beta due to bugs with the > related item functionality! > Me too. > With the limited set of developers actively working on JTrac, we should > concentrate on core features/bugs fixes rather than trying to build add-on > features like a Wiki engine. WiKi is not an essential component of issue > tracking. My personal opinion is that we should be able to figure out ways > to integrate best of breed open source WiKis with JTrac rather than spending > time trying to embed a WiKi within JTrac. > > I think interfacing with third party products (LDAP support, Subversion > integration, etc.) will add more value that trying to embed them within > JTrac. > more significants will be essential. > We also migrated to Subversion (from VSS) recently. Here is how Jtrac can > integrate with Subversion: > > 1. TortoiseSVN client can be easily configured to prompt for a JTrac ID when > checking in changes to the Subversion repository. With friendly URLs in > JTrac 2.1, we can easily configure Tortoise to create a hyperlink to the > JTrac item ID from the Subversion commit log. > > 2. Programmatically add a history record in Jtrac from a Subversion post > commit trigger with the list of files that were checked in for a particular > jTrac task. We use https to access Subversion. So we can easily link to a > file in Subversion with a URL in Jtrac comment text. We will need JTrac to > support HTML tags for this. > > > Thanks, > Saurabh > > > > _______________________________________________________ Yahoo! Mail - Sempre a melhor opção para você! Experimente já e veja as novidades. http://br.yahoo.com/mailbeta/tudonovo/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users |
|
|
Re: future roadmap
by TimP-3
::
Rate this Message:
Staffan Olsson wrote on 20 October 2007 07:25:
> Hi, > > I agree that every development project needs a documentation system > that developers can update swiftly and as a community. However I must > add to the debate that when I chose jTrac, one reason was that it is > only an issue tracker. A documentation system is a different project. > It may be the same developers and the same frameworks, but I can't see > a reson for releasing them together. For a reason not to: look at the > complexity of the Trac project. > > Features like bookmarkable URLs, single sign-on and XML/JSON services > would allow integration with any documentation system. I personally > prefer html documents in the svn repository and an option to edit > online using tinymce or wymeditor. > > /Staffan It seems to me that it is crucial to have sensible, persistent, human readable urls. My jtrac urls are currently of the form http://192.168.2.87:8080/app/item/VMS-69/ These urls lead to an internal error if you are not logged in. (Error should not be hidden from user as it currently is). What should be happening is a login challenge and then passing through to the requested url when authorised. It seems that the app element of the url does not contribute anything. The url scheme I am most familiar with is: <host>/<db name>/<table name>/<record identifier>/<action> I am very much in agreement that jtrac should not try to become a complete documentation system. It should however have documented examples of it integrating nicely with other products. just my 2p TimP ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ j-trac-users mailing list j-trac-users@... https://lists.sourceforge.net/lists/listinfo/j-trac-users |
| Free embeddable forum powered by Nabble | Forum Help |
