sbugs-develop Mailing List for sBugs Defect Tracking System
Status: Alpha
Brought to you by:
sholder
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(9) |
Feb
(2) |
Mar
(4) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <no...@so...> - 2002-05-25 17:12:15
|
Bugs item #560188, was opened at 2002-05-24 08:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421165&aid=560188&group_id=38041 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Stephen Holder (sholder) Assigned to: Stephen Holder (sholder) Summary: Wrong instructions in install.txt Initial Comment: In install.txt, the instructions for setting the jdbc url are incorrect. They refer to changing database.properties, when in fact the database connection attributes are now controlled by poolman.xml. install.txt needs to be updated to contain the correct information. ---------------------------------------------------------------------- >Comment By: Stephen Holder (sholder) Date: 2002-05-25 10:12 Message: Logged In: YES user_id=294492 Updated the INSTALL file with the correct instructions. Its in CVS, will be included in 0.6 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421165&aid=560188&group_id=38041 |
From: <no...@so...> - 2002-05-24 15:43:23
|
Bugs item #560188, was opened at 2002-05-24 08:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421165&aid=560188&group_id=38041 Category: None Group: None Status: Open Resolution: None Priority: 8 Submitted By: Stephen Holder (sholder) Assigned to: Stephen Holder (sholder) Summary: Wrong instructions in install.txt Initial Comment: In install.txt, the instructions for setting the jdbc url are incorrect. They refer to changing database.properties, when in fact the database connection attributes are now controlled by poolman.xml. install.txt needs to be updated to contain the correct information. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421165&aid=560188&group_id=38041 |
From: <no...@so...> - 2002-03-29 06:52:36
|
Bugs item #536638, was opened at 2002-03-28 22:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421165&aid=536638&group_id=38041 Category: usability Group: None Status: Open Resolution: None Priority: 6 Submitted By: Stephen Holder (sholder) Assigned to: Stephen Holder (sholder) Summary: can't modify saved searches Initial Comment: You should be able to view the terms of a saved search,so you can tell what it is searching by. It would also be very helpful to be able to modify a saved search, or at least delete it so that you can create a new one with the same name. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421165&aid=536638&group_id=38041 |
From: <no...@so...> - 2002-03-26 02:16:26
|
Feature Requests item #534986, was opened at 2002-03-25 18:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=534986&group_id=38041 Category: usability Group: New Functionality Status: Open Priority: 5 Submitted By: Stephen Holder (sholder) Assigned to: Nobody/Anonymous (nobody) Summary: Link duplicate defects Initial Comment: Users should be able to mark one defect as being a duplicate of another. If defect A is a duplicate of defect B, then when viewing either A or B there should be a quick and convenient way to navigate to the linked defect. This could possibly be extended to allow arbitrary linkage between defects, with the type of link selectable, allowing options such as "duplicate", "related functionality", "dependency", etc. Just duplicates would make for a good start, though. If no one else wants to work on this, I'll try to give it a go for the 0.7 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=534986&group_id=38041 |
From: <no...@so...> - 2002-03-26 02:13:22
|
Feature Requests item #534984, was opened at 2002-03-25 18:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=534984&group_id=38041 Category: None Group: New Functionality Status: Open Priority: 6 Submitted By: Stephen Holder (sholder) Assigned to: Nobody/Anonymous (nobody) Summary: Need to be able to add attachments Initial Comment: Users should be able to add attachments to defects. This is necessary for screen shots of errors, log files, etc. Basically, just need to add an appropriate table to the database, and add links to the defect details pages to add / view / remove attachments. If no one else does it, I'll try to implement this for the 0.7 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=534984&group_id=38041 |
From: <no...@so...> - 2002-03-25 07:00:35
|
Feature Requests item #534556, was opened at 2002-03-24 23:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=534556&group_id=38041 Category: Interface Group: Next Release Status: Open Priority: 7 Submitted By: Stephen Holder (sholder) Assigned to: Nobody/Anonymous (nobody) Summary: Administration UI Initial Comment: Currently, the only way to change the various configuration options is to write SQL directly to the database. There are also one or two spots where things are hard coded that should really be configurable without needing a re-compile. We need to write a nice UI to enable an administrator to: 1) Add or remove users 2) Set the initial state/initial assigned to user that defects should be set to 3) Configure the the allowed states/priorites 4) Configure the allowed transitions between states. For the most part, these are all pretty straightforward. #4 is really the only tricky one, and that is from a usability standpoint - implementing it shouldn't be too tough. I'm planning to get started on this at some point relatively soon, unless someone else wants to volunteer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=534556&group_id=38041 |
From: Stephen H. <sh...@go...> - 2002-02-02 23:25:27
|
Just tried a quick test with just Tomcat, and everything seems to work fine. Thanks, Per. On Saturday 02 February 2002 11:20, you wrote: > OK, I just checked in the JBoss-Tomcat support. The issue in 2.4.4. has to > do with JNDI binding of the DataSource. > > The only two features of JBoss-Tomcat used is hot deploy and Connection > Pooling. This is to make it possible to run Tomcat standalone if desired. > > There is a new target in the ant script that creates and puts the war file > in the JBoss deploy directory. I switched some things around so that I did > not have to duplicate a lot of code but as far as I can tell all the "old > stuff" still works. > > To switch from using PoolMan to use a JBoss defined data source do the > following: > 1. Edit database.properties and set pool.lookup=JNDI. You might want to > adjust the other JNDI stuff as well > 2. Edit jboss.jcml to set up the XA data source. > > Please let me know if you have any problems. > > Best regards, > Per > |
From: Per N. <per...@no...> - 2002-02-02 19:20:59
|
OK, I just checked in the JBoss-Tomcat support. The issue in 2.4.4. has to do with JNDI binding of the DataSource. The only two features of JBoss-Tomcat used is hot deploy and Connection Pooling. This is to make it possible to run Tomcat standalone if desired. There is a new target in the ant script that creates and puts the war file in the JBoss deploy directory. I switched some things around so that I did not have to duplicate a lot of code but as far as I can tell all the "old stuff" still works. To switch from using PoolMan to use a JBoss defined data source do the following: 1. Edit database.properties and set pool.lookup=JNDI. You might want to adjust the other JNDI stuff as well 2. Edit jboss.jcml to set up the XA data source. Please let me know if you have any problems. Best regards, Per > -----Original Message----- > From: Dewayne McNair [mailto:dm...@dm...] > Sent: Friday, January 25, 2002 2:32 PM > To: Per Nyfelt > Subject: Re: sbugs -- jboss > > > Thanks, that would be great. If you want to just send me a ZIP of your > stuff, that would be cool, too. I can take care of getting it to work on > JBoss 2.4.4. > > Thanks again, > > Dewayne > > ----- Original Message ----- > From: "Per Nyfelt" <per...@no...> > To: "Dewayne McNair" <dm...@us...> > Sent: Friday, January 25, 2002 4:45 AM > Subject: RE: sbugs -- jboss > > > > Sure, I'll try to check in my stuff this week-end. It is not working on > > JBoss 2.4.4. though (only 2.4.0) and I doubt I will find time to make it > > work this week-end. > > > > Regards, > > Per > > > > > -----Original Message----- > > > From: nobody [mailto:no...@so...]On Behalf Of > Dewayne McNair > > > Sent: Wednesday, January 23, 2002 10:18 PM > > > To: per...@no... > > > Subject: sbugs -- jboss > > > > > > > > > Hi, > > > > > > > > > > > > I saw your posting in the sbugs project about > > > > > > porting it to JBoss. I was actually about to > > > > > > attempt the same thing. Did you guys make any > > > > > > progress? Can you share what you have? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Dewayne > > > > > > > > > |
From: Stephen H. <sh...@go...> - 2002-01-25 19:25:18
|
On Fri, 25 Jan 2002, Per Nyfelt wrote: > Hi, > > I'm sorry for disappearing. I am swamped with work right now and it will be > another two weeks before I can get my hands on Sbugs again. > No worries, I've been in a similar situation... Hopefully, things will clear up enough in a week or two to that I'll be able to get some stuff done. > > Z)? Its a bit more complicated to implement, but gives users a lot of > > flexibility. > > Sounds good. How to vision that being defined/set-up? > hehe, that's the tricky part :). It will probably require moving security out of the basic users table. Something along the lines of a seperate table for security functions assigned to users. Each row would have something along the lines of the user_id of the user its assigned to, the function name/id, and an optional parameter... When doing security checks, you could then pass parameters (i.e., the state transitioning to) when appropriate... building a UI to grant/revoke permissions to a user might be a pain, but should be doable... Anyway, thats just an initial idea. I'm not planning on trying to implement it for a little while, so any suggestions/thoughts would still be good. -Steve |
From: Per N. <per...@no...> - 2002-01-25 10:37:03
|
Hi, I'm sorry for disappearing. I am swamped with work right now and it will be another two weeks before I can get my hands on Sbugs again. > -----Original Message----- > From: sbu...@li... > [mailto:sbu...@li...]On Behalf Of Stephen > Holder > Sent: Wednesday, January 09, 2002 10:32 PM > To: sbu...@li... > Subject: [Sbugs-develop] cvs updates, security, etc. > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >OK i attach the scripts to this e-mail. > Thanks. I went ahead and added them to cvs in the source/db_scripts > directory. I also added a shell script to initialize the > database for mysql, > similar to the postgresql script. I haven't tested it, though, > so if you get > the chance to verify that it works, that would be great. I will test it and let you know. The mySQL inability to handle sub selects is a challenging one. Sub selects is planned two releases away for mySQL. In theory most queries using sub selects could be rewritten using joins. I'll take a closer look to see if that is a possibility for us. > >We could probably keep it > >as an option even i.e. either use Poolman to connect to the DB > or set up the > >datasource with JBoss and use the built in connection pool > there. I'll check > >if it's possible to change type between Tomcat standalone and > JBoss-Tomcat > >by just setting a property... > For now, it would be awesome if we could keep things working > either way, at > least for a little while, and as long as its not too much of a problem to > maintain. For me, there is still definite advantage in keeping > the footprint > as small as possible for right now - I'm running to sBugs at home > to track > various projects I'm working on, and its not exactly high-end > machines :), so > only having to run Tomcat is preferable to Tomcat+JBoss. As soon as it > starts to become unwieldy to maintain, though, requiring JBoss is > probably ok. Sounds good and I have found a way to do this by using a couple of properties. Good thing is that it should then be possible to run in any full J2EE app server (EJB+Servlet containers) or Standalone Tomcat (or probably any other standalone servlet container). I still cannot get my code to run on the new 2.4.4 version of JBoss with integrated Tomcat 4.0.1 though. Something has changed with their connection pool implementation that I haven't found the answer for yet and until i do there is not much point of checking in code that will not work on the current stable JBoss-Tomcat version. I just need a day to figure it out so no big deal, it's just a matter of getting that day. > >I think there should be at least two levels of user access: > >1. User level - can add new bugs, update/edit bug details, priority, > >severity and close a bug > >2. Developer level - all that user can do + ability to take on a > bug (could > >be many developers working on one bug) and update state (submitted, > >assigned...). > > > >Later it might make sense with an admin level as well but for know those > >changes can be done with straight SQL i think. > > > Hmm... One of my goals was to have the whole state/transition model be > completely customizable in the database, with no logic hard-coded > in the main > sbugs engine. In order to give, say, users the ability to close > bugs, but > make no other state changes, we'll need to assign permissions on a > per-transition basis, which isn't a bad idea... what if we came > up with a > list of standard permissions (create new bug, edit bug details, etc.) and > parameterized permissions ( perform transitions A and B, but not > transition > Z)? Its a bit more complicated to implement, but gives users a lot of > flexibility. Sounds good. How to vision that being defined/set-up? Best regards, Per |
From: Stephen H. <sh...@go...> - 2002-01-10 05:33:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >OK i attach the scripts to this e-mail. Thanks. I went ahead and added them to cvs in the source/db_scripts directory. I also added a shell script to initialize the database for mysql, similar to the postgresql script. I haven't tested it, though, so if you get the chance to verify that it works, that would be great. >We could probably keep it >as an option even i.e. either use Poolman to connect to the DB or set up the >datasource with JBoss and use the built in connection pool there. I'll check >if it's possible to change type between Tomcat standalone and JBoss-Tomcat >by just setting a property... For now, it would be awesome if we could keep things working either way, at least for a little while, and as long as its not too much of a problem to maintain. For me, there is still definite advantage in keeping the footprint as small as possible for right now - I'm running to sBugs at home to track various projects I'm working on, and its not exactly high-end machines :), so only having to run Tomcat is preferable to Tomcat+JBoss. As soon as it starts to become unwieldy to maintain, though, requiring JBoss is probably ok. >I think there should be at least two levels of user access: >1. User level - can add new bugs, update/edit bug details, priority, >severity and close a bug >2. Developer level - all that user can do + ability to take on a bug (could >be many developers working on one bug) and update state (submitted, >assigned...). > >Later it might make sence with an admin level as well but for know those >changes can be done with straight SQL i think. > Hmm... One of my goals was to have the whole state/transition model be completely customizable in the database, with no logic hard-coded in the main sbugs engine. In order to give, say, users the ability to close bugs, but make no other state changes, we'll need to assign permissions on a per-transition basis, which isn't a bad idea... what if we came up with a list of standard permissions (create new bug, edit bug details, etc.) and parameterized permissions ( perform transitions A and B, but not transition Z)? Its a bit more complicated to implement, but gives users a lot of flexibility. >Here are some of things I'm >thinking of: >1. Take care of mySQL's current inability to handle sub selects >2. Add project context and ability to switch between projects if involved in >more than one >3. Ability to add and remove users from a user interface >4. Make it possible to add screen shots >5. Simplify some of the navigation (use combo box to pick user name in >"assigned to" and "owner" in search screen instead of text box.) Cool. For now, I'm going to start on being able to save defect queries (i.e., every day I do a search for all bugs where user=sholder and priority=1 or 2 and state=opened), cuz I'm getting tired of entering the same stuff all the time. I'll also start thinking about how to implement the security stuff, so I can hopefully do that next. - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PLaA5tbtqsVlV4IRAq7wAJ9xz6enpwu6jyM8YjhW4HJ9KLHV3ACfUYn/ y3hQCyBadv5CMKdD3Sf0wCA= =vuxW -----END PGP SIGNATURE----- |
From: Per N. <per...@no...> - 2002-01-09 09:09:06
|
> Hi Per - > I'd love to have you get involved in the project - any help is always > appreciated. :) great! > Making sure sbugs runs on mySQL would be great. Its one of those things > that I've wanted to do, but since I'm running PostgreSQL I just never > found time to make it a priority. If you've already done the port, we > can go ahead and just add your scripts to cvs. OK i attach the scripts to this e-mail. I was a little rushed to get it up and running so some things are not good ( the inserts in transitions-mysql.sql springs to mind) and I can clean it up later. It's good enough to get it working though. > I had tentatively planned to work on some of the admin interfaces next, > but I'm realizing that I'm gonna need to flesh out the security model > more, too. Right now there is a vague notion of a user having permissions > to perform various actions, but I haven't really thought out in any detail > what those actions should be or the real specifics of how they should > work. Do you guys have any input on how you'd like this stuff to work? I think there should be at least two levels of user access: 1. User level - can add new bugs, update/edit bug details, priority, severity and close a bug 2. Developer level - all that user can do + ability to take on a bug (could be many developers working on one bug) and update state (submitted, assigned...). Later it might make sence with an admin level as well but for know those changes can be done with straight SQL i think. > > I'm torn on the issue of moving to JBoss/EJBs... I thought about using > JBoss for a long time when I first started sbugs, but just couldn't > convince myself that sbugs really needed anything that an EJB server > offered. I hadn't considered JMS - do you see much of a need for it at > your company? I don't think I'm ready to commit to going EJB just yet, > but I could probably be persuaded - at the least, it would give me enough > experience with JBoss that I might be able to convince my boss at work > that we don't need to pay for weblogic :). Either way, though, > it seems like > getting some of the other functionality done first might be a better idea, > and then we can evaluate whether or not to do it. Agreed. It's just that i find it very easy to plug in any database you want, the JMX stuff gives you run time configuration change possibilities. Even though we might not use any EJB's right now and just keep deploying a war file, JBoss hotdeploy is nice thing to have and when the day comes to use EJB's or JMS it's there already waiting to be used. The latest stable version, 2.4.4. comes integrated with Tomcat 4.0.1. I was working on the version prior to that (JB 2.4.0 and Tomcat 3.2.3) when i did the port and I have it all working on my machine and the changes to make it work is very minor. I have some issues getting it to run on the latest version that i'm looking at (we're about to upgrade at my company). We could probably keep it as an option even i.e. either use Poolman to connect to the DB or set up the datasource with JBoss and use the built in connection pool there. I'll check if it's possible to change type between Tomcat standalone and JBoss-Tomcat by just setting a property... > Is there a particular set of functionality you're interested in tackling > first? If you have a sourceforge account I can give you cvs access, just > let me know your username. Thanks, I've sent you my SF id separately. Here are some of things I'm thinking of: 1. Take care of mySQL's current inability to handle sub selects 2. Add project context and ability to switch between projects if involved in more than one 3. Ability to add and remove users from a user interface 4. Make it possible to add screen shots 5. Simplify some of the navigation (use combo box to pick user name in "assigned to" and "owner" in search screen instead of text box.) Best regards, Per |
From: Stephen H. <sh...@go...> - 2002-01-09 03:59:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You should be added to the project now, and be able to update cvs, as well as bug reports, etc. Let me know if anything doesn't work that shold. - -Steve On Tuesday 08 January 2002 10:00, you wrote: > Thanks for your reply. I'll send a reply to the mailing list. > My SF id is per_nyfelt. > > Regards, > Per > - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8O08o5tbtqsVlV4IRAuLNAJ40Tp2llhTf+7oxUNEviXRS/vGZFQCeJ/0w i82lV41ZNIIYqZo8mW+o+44= =lhah -----END PGP SIGNATURE----- |
From: Stephen H. <sh...@go...> - 2002-01-09 03:52:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry 'bout the trouble, 0.5 is fixed now. I had accidently included some configuration files that were specific to my setup, I removed them and replaced them with generic ones. - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8O01+5tbtqsVlV4IRAuDgAKC1Xt1/lBL9pJFmtLRjd/jz5rPd4ACdHdwt i2+GRCBKv5jojYLiYBteNW8= =aaom -----END PGP SIGNATURE----- |
From: Stephen H. <sh...@go...> - 2002-01-08 03:33:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have just released version 0.5 of sBugs. This release includes a major extension to the sBugs architecture, enabling transition handlers to be defined for each state change a defect goes through. The default distribution includes handlers to assign defects on appropriate changes, and to email all interested parties on any change. Upgrading from 0.4.2: Other than installing the new java code, there are a few database changes to make as well. Please run the scripts database/transitions.sql and database/transition_handlers.sql, in that order. You will also have to change the users table to include an email address column, as follows: alter table sbugs_user add column email_addr varchar( 25 ); Please see the changelog for a complete list of all changes. - -Steve - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Ofdb5tbtqsVlV4IRAkyMAKDOAGSMllfDVMUtWrcLIxtcsw1ecgCg2wdZ a8iIN96DvMI/Zx/0LVa6IqM= =MPt2 -----END PGP SIGNATURE----- |
From: Stephen H. <sh...@go...> - 2002-01-07 18:23:18
|
Hi Per - I'd love to have you get involved in the project - any help is always appreciated. :) Making sure sbugs runs on mySQL would be great. Its one of those things that I've wanted to do, but since I'm running PostgreSQL I just never found time to make it a priority. If you've already done the port, we can go ahead and just add your scripts to cvs. I actually just finished e-mail functionality, and was planning to make an 0.5 release tonight when I get home that includes it. I had tentatively planned to work on some of the admin interfaces next, but I'm realizing that I'm gonna need to flesh out the security model more, too. Right now there is a vague notion of a user having permissions to perform various actions, but I haven't really thought out in any detail what those actions should be or the real specifics of how they should work. Do you guys have any input on how you'd like this stuff to work? I'm torn on the issue of moving to JBoss/EJBs... I thought about using JBoss for a long time when I first started sbugs, but just couldn't convince myself that sbugs really needed anything that an EJB server offered. I hadn't considered JMS - do you see much of a need for it at your company? I don't think I'm ready to commit to going EJB just yet, but I could probably be persuaded - at the least, it would give me enough experience with JBoss that I might be able to convince my boss at work that we don't need to pay for weblogic :). Either way, though, it seems like getting some of the other functionality done first might be a better idea, and then we can evaluate whether or not to do it. Is there a particular set of functionality you're interested in tackling first? If you have a sourceforge account I can give you cvs access, just let me know your username. -Steve On Mon, 7 Jan 2002, Per Nyfelt wrote: > Hi, > > I've spent the weekend looking through the code. The code looks nice and > clean so I would like to contribute to this project if my suggestions are > found acceptable. > > We run JBoss-Tomcat with a mySQL back-end at work and would like for sbugs > to run in that environment. In order for that to work I made the following > changes: > > 1. Port the sql scripts over to mySQL syntax > 2. Set up a connection pool in JBoss and changed ConnectionPool to retrieve > the Datasource from JNDI instead of using Poolman: > Context ctx = new InitialContext(); > source = > (DataSource)ctx.lookup(jdbcProps.getString("pool.jndiName")); > 3. Added flush=true to the jsp's that has the footer: > <jsp:include page="footer.jsp" flush="true" /> > > 4. Added a deploy.ejb target to the build script to speed up the development > cycle. > > How about switching to use JBoss-Tomcat as the back-end instead (PostgreSQL > works fine with JBoss so the database would be at the users choice)? Then > there is EJB's, JMS, Connection Pooling, clustering etc. etc. that will be > very handy when sbugs grows more mature and needs to scale. > > There is a lot of functionality to add such as administration, ability to > include screenshots in the bugreport, e-mail Notification of submitted bugs > to interested parties, etc. etc. Me and my colleagues would be happy to help > out with that. > > Best regards, > Per > > > _______________________________________________ > Sbugs-develop mailing list > Sbu...@li... > https://lists.sourceforge.net/lists/listinfo/sbugs-develop > |
From: Per N. <per...@no...> - 2002-01-07 13:06:19
|
Hi, I've spent the weekend looking through the code. The code looks nice and clean so I would like to contribute to this project if my suggestions are found acceptable. We run JBoss-Tomcat with a mySQL back-end at work and would like for sbugs to run in that environment. In order for that to work I made the following changes: 1. Port the sql scripts over to mySQL syntax 2. Set up a connection pool in JBoss and changed ConnectionPool to retrieve the Datasource from JNDI instead of using Poolman: Context ctx = new InitialContext(); source = (DataSource)ctx.lookup(jdbcProps.getString("pool.jndiName")); 3. Added flush=true to the jsp's that has the footer: <jsp:include page="footer.jsp" flush="true" /> 4. Added a deploy.ejb target to the build script to speed up the development cycle. How about switching to use JBoss-Tomcat as the back-end instead (PostgreSQL works fine with JBoss so the database would be at the users choice)? Then there is EJB's, JMS, Connection Pooling, clustering etc. etc. that will be very handy when sbugs grows more mature and needs to scale. There is a lot of functionality to add such as administration, ability to include screenshots in the bugreport, e-mail Notification of submitted bugs to interested parties, etc. etc. Me and my colleagues would be happy to help out with that. Best regards, Per |
From: Stephen H. <sh...@go...> - 2001-12-09 01:20:41
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, I had a lot less time to work on sBugs than I thought I would, so unfortunately 0.5 is not quite done yet. The new state transition architecture is in place, though, so I thought I would go ahead and give anyone who cares a sneak peek at whats coming. This is definetly unpolished - the default state configuration should be considered just for testing, it will probably change before the official 0.5 release, plus there are a few transitions that don't have pages yet. But the major bugs have been ironed out, and hopefully it won't take too much longer before I'm ready for an official 0.5. In addition to the architecture enhancements, this release also finally includes db connection pooling (courtesy of poolman (http://poolman.sourceforge.net). You'll want to tweak the configuration in poolman.xml, but I noticed a definite improvement in response time on my laptop (for systems w/ more resources, its not as noticeable, unless you're supporting a fair number of users at once). - -Steve - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Ekst5tbtqsVlV4IRAgxpAJ9BO6PfWS5LOgGi6M5Iy0LGCohPwACg2pVq ah5i1PiBpbTasT3EyeStS9Y= =xVEa -----END PGP SIGNATURE----- |
From: Stephen H. <sh...@go...> - 2001-10-22 04:21:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I realized that I goofed big time and was missing a bunch of files in CVS. I'm pretty sure the actual releases were missing some important stuff too. This fixes all of that, I ran through the process of installing from scratch, so I'm about 99% sure this one works :). This also adds a database creation script, to make the process of setting up the sBugs database a bit easier, as well as including the PostgreSQL jdbc drivers in the distribution so you don't have to install them yourself. Struts is also included in CVS now, so building should be much more straightforward. - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE703RK5tbtqsVlV4IRAoZqAJwI0hfcYHTtTA+DUHFQSUwjbFv2LQCeO3/8 VgDr/Uc9YU+rDv/4Ni0TLis= =IziN -----END PGP SIGNATURE----- |
From: <no...@so...> - 2001-10-22 00:45:55
|
Feature Requests item #473541, was opened at 2001-10-21 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=473541&group_id=38041 Category: usability Group: None Status: Open Priority: 5 Submitted By: Stephen Holder (sholder) Assigned to: Stephen Holder (sholder) Summary: save defect queries Initial Comment: Certain queries (all open defects, for example) get run frequently. It would be very convenient to be able to save these queries and run them with one click, rather than re-entering them every time. Ideally, they would be able to be saved on both a system-wide and individual user level. This shouldn't be too hard to implement, we just need 1 additional table to store the search terms and an indicator of who owns the search. This is currently slated for release 0.6, unless someone else implements it first. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=421168&aid=473541&group_id=38041 |
From: Stephen H. <sh...@go...> - 2001-10-20 22:19:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a bug fix release, with some UI enhancements. It makes navigating alot easier, as common pages are now easily accessible - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE70c4D5tbtqsVlV4IRAoivAKDUhb8zftPw8H/VUBN0/k6S7fojFgCcDH9m nWnE+px0bJlpMG6rHvdC5mI= =Ra09 -----END PGP SIGNATURE----- |
From: Stephen H. <sh...@go...> - 2001-10-20 20:33:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Test to make sure dev list is working - -- PGP public key available at: http://www.gothcafe.com/~sholder -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE70bUv5tbtqsVlV4IRAmKHAKCBa56XM65r3AzTojMsGYJ/0m2p5gCfT+WH KBIETX1jL1t/tDE+O0DlqSo= =7mMz -----END PGP SIGNATURE----- |