From: Robert M. <rob...@gm...> - 2011-06-23 07:39:15
|
Hi all, Since 1.2.x is almost 1 and a half years old, I think that this is a good time to wrap up a final 1.2.6 release and put the 1.2 branch into critical/security bugfix only mode. It would make maintenance easier and would allow us to focus on getting a first 1.3 milestone out the door, hopefully with some noteworthy improvements which would encourage our users to try it out. Up til now my policy was to apply fixes to both master-1.2.x and master, but that is getting a bit tiring, as sometimes they need manual tweaking. Thoughts? Robert -- Sent from my (old) computer |
From: Victor B. <vi...@fu...> - 2011-06-23 07:55:39
|
1.2.x branch is in a stable state and hence it should get mainly bug fixes and security fixes. I wouldn't however call 1.2.6 a final release. My guess is that we can't expect to reach that until we release 1.3.0 stable. On Thu, Jun 23, 2011 at 12:39 AM, Robert Munteanu <rob...@gm... > wrote: > Hi all, > > Since 1.2.x is almost 1 and a half years old, I think that this is a > good time to wrap up a final 1.2.6 release and put the 1.2 branch into > critical/security bugfix only mode. It would make maintenance easier > and would allow us to focus on getting a first 1.3 milestone out the > door, hopefully with some noteworthy improvements which would > encourage our users to try it out. Up til now my policy was to apply > fixes to both master-1.2.x and master, but that is getting a bit > tiring, as sometimes they need manual tweaking. > > Thoughts? > > Robert > > -- > Sent from my (old) computer > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Robert M. <rob...@gm...> - 2011-06-23 22:18:32
|
On Thu, Jun 23, 2011 at 10:55 AM, Victor Boctor <vi...@fu...> wrote: > 1.2.x branch is in a stable state and hence it should get mainly bug fixes > and security fixes. I wouldn't however call 1.2.6 a final release. My > guess is that we can't expect to reach that until we release 1.3.0 stable. That's a good point. What I was really meant to say was Let's put 1.2 into low maintenance mode - high priority fixes only - and put all the effort into 1.3 . I don't think backporting everything into 1.2 is worth the effort. We can decide on the issues we really want released soon with 1.2.x , put those into 1.2.6, and then focus as much as possible on 1.3 . > > On Thu, Jun 23, 2011 at 12:39 AM, Robert Munteanu > <rob...@gm...> wrote: >> >> Hi all, >> >> Since 1.2.x is almost 1 and a half years old, I think that this is a >> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >> critical/security bugfix only mode. It would make maintenance easier >> and would allow us to focus on getting a first 1.3 milestone out the >> door, hopefully with some noteworthy improvements which would >> encourage our users to try it out. Up til now my policy was to apply >> fixes to both master-1.2.x and master, but that is getting a bit >> tiring, as sometimes they need manual tweaking. >> >> Thoughts? >> >> Robert >> >> -- >> Sent from my (old) computer >> >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with >> vRanger. >> Installation's a snap, and flexible recovery options mean your data is >> safe, >> secure and there when you need it. Data protection magic? >> Nope - It's vRanger. Get your free trial download today. >> http://p.sf.net/sfu/quest-sfdev2dev >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Sent from my (old) computer |
From: David H. <d...@hx...> - 2011-06-23 09:18:43
|
On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: > Since 1.2.x is almost 1 and a half years old, I think that this is a > good time to wrap up a final 1.2.6 release and put the 1.2 branch into > critical/security bugfix only mode. I agree that a 1.2.6 release is probably needed sometime soon. There are however quite a number of issues on the 1.2.6 roadmap (see mantisbt.org/bugs) that I feel need some attention. Many have patches - although some of these need more work done before applying. > It would make maintenance easier > and would allow us to focus on getting a first 1.3 milestone out the > door, hopefully with some noteworthy improvements which would > encourage our users to try it out. Up til now my policy was to apply > fixes to both master-1.2.x and master, but that is getting a bit > tiring, as sometimes they need manual tweaking. I strongly agree that applying patches to both branches is a major hassle. Paul, Daryn and myself have started a number of branches on Github that primarily look at: * Removing ADOdb and replacing db_api with a new OO implementation based on PDO (much of this effort has already been completed). * Reorganising the directory structure (will probably need to be redone again once DB stuff is completed). * The use of templating - or at least major decoupling of UI and logic in the code. I get the feeling that it would have been better to make many of these changes to the master branch "as it happens". We're stuck in the situation at the moment where there are 3-4 very promising development branches that will not merge together. IMO the source code is not modular enough at the moment to allow for rewriting major MantisBT components in branches and then merging them back in again. Any thoughts? David |
From: John R. <jo...@no...> - 2011-06-23 11:59:59
|
On 06/23/2011 05:19 AM, David Hicks wrote: > On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: >> Since 1.2.x is almost 1 and a half years old, I think that this is a >> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >> critical/security bugfix only mode. > > I agree that a 1.2.6 release is probably needed sometime soon. There are > however quite a number of issues on the 1.2.6 roadmap (see > mantisbt.org/bugs) that I feel need some attention. Many have patches - > although some of these need more work done before applying. Would it be worth it to release 1.2.6 now and have someone focus on claering out the outstanding issues from 1.2.x and then make another release after that happens? Either way, I have no problem putting together a release as long as someone can write up some release notes so covering everything in the update. > ... > > I get the feeling that it would have been better to make many of these > changes to the master branch "as it happens". We're stuck in the > situation at the moment where there are 3-4 very promising development > branches that will not merge together. IMO the source code is not > modular enough at the moment to allow for rewriting major MantisBT > components in branches and then merging them back in again. > > Any thoughts? Perhaps it would be best to take whichever branch has the most divergence, merge that into 1.3.x, and then start some effort on updating the other branches to either reproduce the effort on the new master branch, or try a rebase and start fixing conflicts as they show up. It's going to be a lot of work, but it would be worth it. I'd imagine that the DB rework will likely not abe too affected by the restructuring efforts already in place, other than the files being renamed, so it might be easier to apply the reorg branch first, and then merge the database changes on top of that. If you want some help or guidance with this in Git, grab me on IRC, I'll gladly lend a hand. As for templating, do we actually have any semblance of a completed templating branch in place anywhere? Last I knew, templating efforts were only begun, and didn't yet cover the majority of the codebase. Cheers -- John Reese noswap.com |
From: Robert M. <rob...@gm...> - 2011-06-23 22:29:37
|
On Thu, Jun 23, 2011 at 2:59 PM, John Reese <jo...@no...> wrote: > On 06/23/2011 05:19 AM, David Hicks wrote: >> On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: >>> Since 1.2.x is almost 1 and a half years old, I think that this is a >>> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >>> critical/security bugfix only mode. >> >> I agree that a 1.2.6 release is probably needed sometime soon. There are >> however quite a number of issues on the 1.2.6 roadmap (see >> mantisbt.org/bugs) that I feel need some attention. Many have patches - >> although some of these need more work done before applying. > > Would it be worth it to release 1.2.6 now and have someone focus on > claering out the outstanding issues from 1.2.x and then make another > release after that happens? Either way, I have no problem putting > together a release as long as someone can write up some release notes so > covering everything in the update. The more I think about it, the more I am convinced we need to set dates. For instance, let's say we aim to release 1.2.6 on July the 11th . All commits go in by July the 7th . Whoever loses this train catches the next one. After all, a release with some fixes now and the rest later is better than a release with all the fixes later. That assumes, of course, that the effort needed to make a release is not too big - but that's something I don't know. I hope it's not over a couple of hours though. Robert > >> ... >> >> I get the feeling that it would have been better to make many of these >> changes to the master branch "as it happens". We're stuck in the >> situation at the moment where there are 3-4 very promising development >> branches that will not merge together. IMO the source code is not >> modular enough at the moment to allow for rewriting major MantisBT >> components in branches and then merging them back in again. >> >> Any thoughts? > > Perhaps it would be best to take whichever branch has the most > divergence, merge that into 1.3.x, and then start some effort on > updating the other branches to either reproduce the effort on the new > master branch, or try a rebase and start fixing conflicts as they show > up. It's going to be a lot of work, but it would be worth it. > > I'd imagine that the DB rework will likely not abe too affected by the > restructuring efforts already in place, other than the files being > renamed, so it might be easier to apply the reorg branch first, and then > merge the database changes on top of that. If you want some help or > guidance with this in Git, grab me on IRC, I'll gladly lend a hand. > > As for templating, do we actually have any semblance of a completed > templating branch in place anywhere? Last I knew, templating efforts > were only begun, and didn't yet cover the majority of the codebase. > > Cheers > > -- > John Reese > noswap.com > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Robert M. <rob...@gm...> - 2011-07-13 09:12:03
|
On Thu, Jun 23, 2011 at 2:59 PM, John Reese <jo...@no...> wrote: > On 06/23/2011 05:19 AM, David Hicks wrote: >> On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: >>> Since 1.2.x is almost 1 and a half years old, I think that this is a >>> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >>> critical/security bugfix only mode. >> >> I agree that a 1.2.6 release is probably needed sometime soon. There are >> however quite a number of issues on the 1.2.6 roadmap (see >> mantisbt.org/bugs) that I feel need some attention. Many have patches - >> although some of these need more work done before applying. > > Would it be worth it to release 1.2.6 now and have someone focus on > claering out the outstanding issues from 1.2.x and then make another > release after that happens? Either way, I have no problem putting > together a release as long as someone can write up some release notes so > covering everything in the update. > >> ... I do not plan to provide more fixes in the short term ( next month) for 1.2.x . Is there anyone who is interested in getting a few more fixes in ? The roadmap is at http://www.mantisbt.org/bugs/roadmap_page.php?version_id=114 . Robert |
From: Damien R. <dam...@me...> - 2011-07-13 09:56:03
|
On Thu, Jun 23, 2011 at 2:59 PM, John Reese<jo...@no...> wrote: > Would it be worth it to release 1.2.6 now and have someone focus on > claering out the outstanding issues from 1.2.x and then make another > release after that happens? +1 On 13.07.2011 11:11, Robert Munteanu wrote: > Is there anyone who is interested in getting a few more > fixes in ? I have a few minor fixes to the built-in time tracking for which I'm finishing testing, hope to get it done by end of the week. Also, 2 issues which I was discussing with David yesterday - http://www.mantisbt.org/bugs/view.php?id=5926 which I think is ready to go, just need to be committed - http://www.mantisbt.org/bugs/view.php?id=12948 I have not had time to test it yet but I think should be included if possible. Damien |
From: Robert M. <rob...@gm...> - 2011-06-23 22:26:39
|
On Thu, Jun 23, 2011 at 12:19 PM, David Hicks <d...@hx...> wrote: > On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: >> Since 1.2.x is almost 1 and a half years old, I think that this is a >> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >> critical/security bugfix only mode. > > I agree that a 1.2.6 release is probably needed sometime soon. There are > however quite a number of issues on the 1.2.6 roadmap (see > mantisbt.org/bugs) that I feel need some attention. Many have patches - > although some of these need more work done before applying. Random thought #1: Push some of these to 1.3 and release once all are done ? I will do so for some of mine, e.g. 0008657: [api soap] custom filters 0012478: [db oracle] Installation with Oracle fails Random thought #2: Make time-based releases, which I am a great fan of. But I'm not sure how that would work, given that we contribute mostly in our spare time. We could aim for 'stable' 1.2 releases every 6 / 8 / 12 weeks and push out the door whatever is ready. > >> It would make maintenance easier >> and would allow us to focus on getting a first 1.3 milestone out the >> door, hopefully with some noteworthy improvements which would >> encourage our users to try it out. Up til now my policy was to apply >> fixes to both master-1.2.x and master, but that is getting a bit >> tiring, as sometimes they need manual tweaking. > > I strongly agree that applying patches to both branches is a major > hassle. > > Paul, Daryn and myself have started a number of branches on Github that > primarily look at: > > * Removing ADOdb and replacing db_api with a new OO implementation based > on PDO (much of this effort has already been completed). > > * Reorganising the directory structure (will probably need to be redone > again once DB stuff is completed). > > * The use of templating - or at least major decoupling of UI and logic > in the code. > > I get the feeling that it would have been better to make many of these > changes to the master branch "as it happens". We're stuck in the > situation at the moment where there are 3-4 very promising development > branches that will not merge together. IMO the source code is not > modular enough at the moment to allow for rewriting major MantisBT > components in branches and then merging them back in again. > > Any thoughts? To echo John's thoughts, let's start merging them to master. Otherwise the bits will rot and decompose.The sooner the better. I am willing to test things manually myself, and also having the SOAP API tests in place does give us a little safety net. Given that you hinted that the code is not modular enough right now, perhaps - like John said - merging the 'reorg' branch first would give us the freedom to work independently in branches. Robert > > David > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Sent from my (old) computer |
From: John R. <jo...@no...> - 2011-06-24 00:25:33
|
On 06/23/2011 06:29 PM, Robert Munteanu wrote: > That assumes, of course, that the effort needed to make a release is > not too big - but that's something I don't know. I hope it's not over > a couple of hours though. I've been meaning for a long time to document the entire process I go through when preparing for and building a new release. Off the top of my head, it involves: - Ensuring the latest master-x is reasonably stable - Incrementing the version number in code - Writing up release notes for the new version, including deciding whether it's a security or maintenance release - Running a build script to generate the release tarballs - Renaming version 1.x.x to final name on public tracker - Creating new 1.x.x version and re-targetting unresolved issues - Closing resolved issues - Uploading and configuring release tarballs to sf.net - Sending release announcement to email lists, blog, and twitter It generally takes me about an hour or more in total, between writing the announcements, re-learning how to upload files to sf.net every single time, and generating the release announcements. Next time I go through the process, I'd like to write down details about every step I take, so that I don't need to be the bottleneck, although I have absolutely no problem with being the one to put in the time and effort. It's the least I can do for the project, esp since I haven't been able to contribute much in the way of code lately. Cheers -- John Reese noswap.com |
From: Robert M. <rob...@gm...> - 2011-06-24 08:02:22
|
On Fri, Jun 24, 2011 at 3:25 AM, John Reese <jo...@no...> wrote: > On 06/23/2011 06:29 PM, Robert Munteanu wrote: >> That assumes, of course, that the effort needed to make a release is >> not too big - but that's something I don't know. I hope it's not over >> a couple of hours though. > > I've been meaning for a long time to document the entire process I go > through when preparing for and building a new release. Off the top of > my head, it involves: > > - Ensuring the latest master-x is reasonably stable > - Incrementing the version number in code > - Writing up release notes for the new version, including deciding > whether it's a security or maintenance release I think this should probably be done by each developer, as we change the code. Eclipse has a new and noteworthy format I really like ( see http://www.eclipse.org/swt/R3_7/new_and_noteworthy.html for instance ) . Perhaps we can emulate it on the wiki? > - Running a build script to generate the release tarballs > - Renaming version 1.x.x to final name on public tracker > - Creating new 1.x.x version and re-targetting unresolved issues > - Closing resolved issues > - Uploading and configuring release tarballs to sf.net > - Sending release announcement to email lists, blog, and twitter > > It generally takes me about an hour or more in total, between writing > the announcements, re-learning how to upload files to sf.net every > single time, and generating the release announcements. > > Next time I go through the process, I'd like to write down details about > every step I take, so that I don't need to be the bottleneck, although I > have absolutely no problem with being the one to put in the time and > effort. It's the least I can do for the project, esp since I haven't > been able to contribute much in the way of code lately. Perhaps next time you can make a small addition to the wiki? It would be good to have it written down. Including the time requirements. Robert > > Cheers > > -- > John Reese > noswap.com > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: metrof_mark <ma...@me...> - 2011-06-24 13:56:47
|
On Fri, 24 Jun 2011 11:02:15 +0300, Robert Munteanu wrote: > On Fri, Jun 24, 2011 at 3:25 AM, John Reese <jo...@no...> wrote: >> On 06/23/2011 06:29 PM, Robert Munteanu wrote: >>> That assumes, of course, that the effort needed to make a release >>> is >>> not too big - but that's something I don't know. I hope it's not >>> over >>> a couple of hours though. >> >> I've been meaning for a long time to document the entire process I >> go >> through when preparing for and building a new release. Off the top >> of >> my head, it involves: >> >> - Ensuring the latest master-x is reasonably stable >> - Incrementing the version number in code >> - Writing up release notes for the new version, including deciding >> whether it's a security or maintenance release > > I think this should probably be done by each developer, as we change > the code. Eclipse has a new and noteworthy format I really like ( see > http://www.eclipse.org/swt/R3_7/new_and_noteworthy.html for instance > ) > . Perhaps we can emulate it on the wiki? I have a simple web tool that scans for all SVN commit messages between two tags or two revisions. It saves the messages and allows a person to just click checkboxes to put them into categories. Then you can format the resulting change log into text or wiki syntax (just headers and bullet points). But it's a good starting point for remembering what went into a release. If this seems at all useful I can clean it up and add git support (which I've been meaning to do for a while). >> - Running a build script to generate the release tarballs >> - Renaming version 1.x.x to final name on public tracker >> - Creating new 1.x.x version and re-targetting unresolved issues >> - Closing resolved issues >> - Uploading and configuring release tarballs to sf.net >> - Sending release announcement to email lists, blog, and twitter >> >> It generally takes me about an hour or more in total, between >> writing >> the announcements, re-learning how to upload files to sf.net every >> single time, and generating the release announcements. >> >> Next time I go through the process, I'd like to write down details >> about >> every step I take, so that I don't need to be the bottleneck, >> although I >> have absolutely no problem with being the one to put in the time and >> effort. It's the least I can do for the project, esp since I >> haven't >> been able to contribute much in the way of code lately. > > Perhaps next time you can make a small addition to the wiki? It would > be good to have it written down. Including the time requirements. > > Robert > >> >> Cheers >> >> -- >> John Reese >> noswap.com >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and >> makes >> sense of it. Business sense. IT sense. Common sense.. >> http://p.sf.net/sfu/splunk-d2d-c1 >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> |
From: Robert M. <rob...@gm...> - 2011-06-24 14:06:03
|
On Fri, Jun 24, 2011 at 4:56 PM, metrof_mark <ma...@me...> wrote: > On Fri, 24 Jun 2011 11:02:15 +0300, Robert Munteanu wrote: >> On Fri, Jun 24, 2011 at 3:25 AM, John Reese <jo...@no...> wrote: >>> On 06/23/2011 06:29 PM, Robert Munteanu wrote: >>>> That assumes, of course, that the effort needed to make a release >>>> is >>>> not too big - but that's something I don't know. I hope it's not >>>> over >>>> a couple of hours though. >>> >>> I've been meaning for a long time to document the entire process I >>> go >>> through when preparing for and building a new release. Off the top >>> of >>> my head, it involves: >>> >>> - Ensuring the latest master-x is reasonably stable >>> - Incrementing the version number in code >>> - Writing up release notes for the new version, including deciding >>> whether it's a security or maintenance release >> >> I think this should probably be done by each developer, as we change >> the code. Eclipse has a new and noteworthy format I really like ( see >> http://www.eclipse.org/swt/R3_7/new_and_noteworthy.html for instance >> ) >> . Perhaps we can emulate it on the wiki? > > > I have a simple web tool that scans for all SVN commit messages > between > two tags or two revisions. It saves the messages and allows a person > to > just click checkboxes to put them into categories. Then you can > format > the resulting change log into text or wiki syntax (just headers and > bullet points). But it's a good starting point for remembering what > went into a release. > > If this seems at all useful I can clean it up and add git support > (which I've been meaning to do for a while). That sounds interesting and might be helpful, so you could give it a shot. We still have to generate nice human-readable ( not developer-readable ) descriptions and screenshots if we go this way. Robert > > >>> - Running a build script to generate the release tarballs >>> - Renaming version 1.x.x to final name on public tracker >>> - Creating new 1.x.x version and re-targetting unresolved issues >>> - Closing resolved issues >>> - Uploading and configuring release tarballs to sf.net >>> - Sending release announcement to email lists, blog, and twitter >>> >>> It generally takes me about an hour or more in total, between >>> writing >>> the announcements, re-learning how to upload files to sf.net every >>> single time, and generating the release announcements. >>> >>> Next time I go through the process, I'd like to write down details >>> about >>> every step I take, so that I don't need to be the bottleneck, >>> although I >>> have absolutely no problem with being the one to put in the time and >>> effort. It's the least I can do for the project, esp since I >>> haven't >>> been able to contribute much in the way of code lately. >> >> Perhaps next time you can make a small addition to the wiki? It would >> be good to have it written down. Including the time requirements. >> >> Robert >> >>> >>> Cheers >>> >>> -- >>> John Reese >>> noswap.com >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure >>> contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and >>> makes >>> sense of it. Business sense. IT sense. Common sense.. >>> http://p.sf.net/sfu/splunk-d2d-c1 >>> _______________________________________________ >>> mantisbt-dev mailing list >>> man...@li... >>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >>> > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Daryn W. <da...@ii...> - 2011-06-24 15:11:00
|
Time based releases are a great idea for teams that have dedicated developers with plenty of time to contribute. In our case, all of our developers are randomly available for ever changing lengths of time. I believe it is simply unworkable for us at this time. The reorg branch is probably the easiest to get up to date and in place. I vote to release 1.2.6 and merge the reorg branch into master. The db update is the next logical merge in my opinion. I would like to see a bit more work on it first but it's nearly there. My branches ( refactor, templates, stored filters ) are not really ready to merge in as they have been primarily experimental and need significantly more work and/or thought. Some (filters,my view/dashboard) would be much better redesigned as part of a larger rewrite. With a reorg branch in place though I believe I could break these experimental branches into smaller commit-able features and hopefully contribute something useful. Daryn On Thu, Jun 23, 2011 at 5:26 PM, Robert Munteanu <rob...@gm...>wrote: > On Thu, Jun 23, 2011 at 12:19 PM, David Hicks <d...@hx...> wrote: > > On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: > >> Since 1.2.x is almost 1 and a half years old, I think that this is a > >> good time to wrap up a final 1.2.6 release and put the 1.2 branch into > >> critical/security bugfix only mode. > > > > I agree that a 1.2.6 release is probably needed sometime soon. There are > > however quite a number of issues on the 1.2.6 roadmap (see > > mantisbt.org/bugs) that I feel need some attention. Many have patches - > > although some of these need more work done before applying. > > Random thought #1: > > Push some of these to 1.3 and release once all are done ? I will do > so for some of mine, e.g. > > 0008657: [api soap] custom filters > 0012478: [db oracle] Installation with Oracle fails > > Random thought #2: > > Make time-based releases, which I am a great fan of. But I'm not sure > how that would work, given that we contribute mostly in our spare > time. We could aim for 'stable' 1.2 releases every 6 / 8 / 12 weeks > and push out the door whatever is ready. >> It would make maintenance easier >> and would allow us to focus on getting a first 1.3 milestone out the > >> door, hopefully with some noteworthy improvements which would > >> encourage our users to try it out. Up til now my policy was to apply > >> fixes to both master-1.2.x and master, but that is getting a bit > >> tiring, as sometimes they need manual tweaking. > > > > I strongly agree that applying patches to both branches is a major > > hassle. > > > > Paul, Daryn and myself have started a number of branches on Github that > > primarily look at: > > > > * Removing ADOdb and replacing db_api with a new OO implementation based > > on PDO (much of this effort has already been completed). > > > > * Reorganising the directory structure (will probably need to be redone > > again once DB stuff is completed). > > > > * The use of templating - or at least major decoupling of UI and logic > > in the code. > > > > I get the feeling that it would have been better to make many of these > > changes to the master branch "as it happens". We're stuck in the > > situation at the moment where there are 3-4 very promising development > > branches that will not merge together. IMO the source code is not > > modular enough at the moment to allow for rewriting major MantisBT > > components in branches and then merging them back in again. > > > > Any thoughts? > > To echo John's thoughts, let's start merging them to master. Otherwise > the bits will rot and decompose.The sooner the better. I am willing to > test things manually myself, and also having the SOAP API tests in > place does give us a little safety net. > > Given that you hinted that the code is not modular enough right now, > perhaps - like John said - merging the 'reorg' branch first would give > us the freedom to work independently in branches. > > Robert > > > > > David |
From: Robert M. <rob...@gm...> - 2011-06-25 07:57:52
|
On Fri, Jun 24, 2011 at 5:58 PM, Daryn Warriner <da...@ii...> wrote: > Time based releases are a great idea for teams that have dedicated > developers with plenty of time to contribute. In our case, all of our > developers are randomly available for ever changing lengths of time. I > believe it is simply unworkable for us at this time. Sadly, I think you're right :| > The reorg branch is probably the easiest to get up to date and in place. I > vote to release 1.2.6 and merge the reorg branch into master. The db update > is the next logical merge in my opinion. I would like to see a bit more > work on it first but it's nearly there. + 1 from me, let's get some of the bigger changes into master. Robert > My branches ( refactor, templates, stored filters ) are not really ready to > merge in as they have been primarily experimental and need significantly > more work and/or thought. Some (filters,my view/dashboard) would be much > better redesigned as part of a larger rewrite. With a reorg branch in place > though I believe I could break these experimental branches into > smaller commit-able features and hopefully contribute something useful. > Daryn > On Thu, Jun 23, 2011 at 5:26 PM, Robert Munteanu <rob...@gm...> > wrote: >> >> On Thu, Jun 23, 2011 at 12:19 PM, David Hicks <d...@hx...> wrote: >> > On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: >> >> Since 1.2.x is almost 1 and a half years old, I think that this is a >> >> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >> >> critical/security bugfix only mode. >> > >> > I agree that a 1.2.6 release is probably needed sometime soon. There are >> > however quite a number of issues on the 1.2.6 roadmap (see >> > mantisbt.org/bugs) that I feel need some attention. Many have patches - >> > although some of these need more work done before applying. >> >> Random thought #1: >> >> Push some of these to 1.3 and release once all are done ? I will do >> so for some of mine, e.g. >> >> 0008657: [api soap] custom filters >> 0012478: [db oracle] Installation with Oracle fails >> >> Random thought #2: >> >> Make time-based releases, which I am a great fan of. But I'm not sure >> how that would work, given that we contribute mostly in our spare >> time. We could aim for 'stable' 1.2 releases every 6 / 8 / 12 weeks >> and push out the door whatever is ready. >> >> >> It would make maintenance easier >> >> >> and would allow us to focus on getting a first 1.3 milestone out the >> >> door, hopefully with some noteworthy improvements which would >> >> encourage our users to try it out. Up til now my policy was to apply >> >> fixes to both master-1.2.x and master, but that is getting a bit >> >> tiring, as sometimes they need manual tweaking. >> > >> > I strongly agree that applying patches to both branches is a major >> > hassle. >> > >> > Paul, Daryn and myself have started a number of branches on Github that >> > primarily look at: >> > >> > * Removing ADOdb and replacing db_api with a new OO implementation based >> > on PDO (much of this effort has already been completed). >> > >> > * Reorganising the directory structure (will probably need to be redone >> > again once DB stuff is completed). >> > >> > * The use of templating - or at least major decoupling of UI and logic >> > in the code. >> > >> > I get the feeling that it would have been better to make many of these >> > changes to the master branch "as it happens". We're stuck in the >> > situation at the moment where there are 3-4 very promising development >> > branches that will not merge together. IMO the source code is not >> > modular enough at the moment to allow for rewriting major MantisBT >> > components in branches and then merging them back in again. >> > >> > Any thoughts? >> >> To echo John's thoughts, let's start merging them to master. Otherwise >> the bits will rot and decompose.The sooner the better. I am willing to >> test things manually myself, and also having the SOAP API tests in >> place does give us a little safety net. >> >> Given that you hinted that the code is not modular enough right now, >> perhaps - like John said - merging the 'reorg' branch first would give >> us the freedom to work independently in branches. >> >> Robert >> >> > >> > David > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Sent from my (old) computer |
From: Daryn W. <da...@ii...> - 2011-06-24 16:44:08
|
Here is a link to the new folder layout branch. I've rebased it against current master. The webserver document root should be pointed at the public directory. This works for me on linux apache. I don't have a windows server so if someone could try setting it up and testing on windows that would be helpful. https://github.com/daryn/mantisbt/tree/folder-layout/public Thanks, Daryn On Fri, Jun 24, 2011 at 9:58 AM, Daryn Warriner <da...@ii...> wrote: > Time based releases are a great idea for teams that have dedicated > developers with plenty of time to contribute. In our case, all of our > developers are randomly available for ever changing lengths of time. I > believe it is simply unworkable for us at this time. > > The reorg branch is probably the easiest to get up to date and in place. I > vote to release 1.2.6 and merge the reorg branch into master. The db update > is the next logical merge in my opinion. I would like to see a bit more > work on it first but it's nearly there. > > My branches ( refactor, templates, stored filters ) are not really ready to > merge in as they have been primarily experimental and need significantly > more work and/or thought. Some (filters,my view/dashboard) would be much > better redesigned as part of a larger rewrite. With a reorg branch in place > though I believe I could break these experimental branches into > smaller commit-able features and hopefully contribute something useful. > > Daryn > > On Thu, Jun 23, 2011 at 5:26 PM, Robert Munteanu < > rob...@gm...> wrote: > >> On Thu, Jun 23, 2011 at 12:19 PM, David Hicks <d...@hx...> wrote: >> > On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: >> >> Since 1.2.x is almost 1 and a half years old, I think that this is a >> >> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >> >> critical/security bugfix only mode. >> > >> > I agree that a 1.2.6 release is probably needed sometime soon. There are >> > however quite a number of issues on the 1.2.6 roadmap (see >> > mantisbt.org/bugs) that I feel need some attention. Many have patches - >> > although some of these need more work done before applying. >> >> Random thought #1: >> >> Push some of these to 1.3 and release once all are done ? I will do >> so for some of mine, e.g. >> >> 0008657: [api soap] custom filters >> 0012478: [db oracle] Installation with Oracle fails >> >> Random thought #2: >> >> Make time-based releases, which I am a great fan of. But I'm not sure >> how that would work, given that we contribute mostly in our spare >> time. We could aim for 'stable' 1.2 releases every 6 / 8 / 12 weeks >> and push out the door whatever is ready. > > > >> It would make maintenance easier > > >> and would allow us to focus on getting a first 1.3 milestone out the >> >> door, hopefully with some noteworthy improvements which would >> >> encourage our users to try it out. Up til now my policy was to apply >> >> fixes to both master-1.2.x and master, but that is getting a bit >> >> tiring, as sometimes they need manual tweaking. >> > >> > I strongly agree that applying patches to both branches is a major >> > hassle. >> > >> > Paul, Daryn and myself have started a number of branches on Github that >> > primarily look at: >> > >> > * Removing ADOdb and replacing db_api with a new OO implementation based >> > on PDO (much of this effort has already been completed). >> > >> > * Reorganising the directory structure (will probably need to be redone >> > again once DB stuff is completed). >> > >> > * The use of templating - or at least major decoupling of UI and logic >> > in the code. >> > >> > I get the feeling that it would have been better to make many of these >> > changes to the master branch "as it happens". We're stuck in the >> > situation at the moment where there are 3-4 very promising development >> > branches that will not merge together. IMO the source code is not >> > modular enough at the moment to allow for rewriting major MantisBT >> > components in branches and then merging them back in again. >> > >> > Any thoughts? >> >> To echo John's thoughts, let's start merging them to master. Otherwise >> the bits will rot and decompose.The sooner the better. I am willing to >> test things manually myself, and also having the SOAP API tests in >> place does give us a little safety net. >> >> Given that you hinted that the code is not modular enough right now, >> perhaps - like John said - merging the 'reorg' branch first would give >> us the freedom to work independently in branches. >> >> Robert >> >> > >> > David > > |
From: Robert M. <rob...@gm...> - 2011-06-25 07:56:38
|
On Fri, Jun 24, 2011 at 7:43 PM, Daryn Warriner <da...@ii...> wrote: > Here is a link to the new folder layout branch. I've rebased it against > current master. The webserver document root should be pointed at the public > directory. This works for me on linux apache. I don't have a windows > server so if someone could try setting it up and testing on windows that > would be helpful. > https://github.com/daryn/mantisbt/tree/folder-layout/public > Thanks, > Daryn I see that the SOAPI API now lives under application/services/soap . Does it still respond to api/soap/mantisconnect.php calls ? I will try to fire up a windows VM and install your branch today. Hopefully I will remember how to :-) Robert > > On Fri, Jun 24, 2011 at 9:58 AM, Daryn Warriner <da...@ii...> wrote: >> >> Time based releases are a great idea for teams that have dedicated >> developers with plenty of time to contribute. In our case, all of our >> developers are randomly available for ever changing lengths of time. I >> believe it is simply unworkable for us at this time. >> The reorg branch is probably the easiest to get up to date and in place. >> I vote to release 1.2.6 and merge the reorg branch into master. The db >> update is the next logical merge in my opinion. I would like to see a bit >> more work on it first but it's nearly there. >> My branches ( refactor, templates, stored filters ) are not really ready >> to merge in as they have been primarily experimental and need significantly >> more work and/or thought. Some (filters,my view/dashboard) would be much >> better redesigned as part of a larger rewrite. With a reorg branch in place >> though I believe I could break these experimental branches into >> smaller commit-able features and hopefully contribute something useful. >> Daryn >> On Thu, Jun 23, 2011 at 5:26 PM, Robert Munteanu >> <rob...@gm...> wrote: >>> >>> On Thu, Jun 23, 2011 at 12:19 PM, David Hicks <d...@hx...> wrote: >>> > On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote: >>> >> Since 1.2.x is almost 1 and a half years old, I think that this is a >>> >> good time to wrap up a final 1.2.6 release and put the 1.2 branch into >>> >> critical/security bugfix only mode. >>> > >>> > I agree that a 1.2.6 release is probably needed sometime soon. There >>> > are >>> > however quite a number of issues on the 1.2.6 roadmap (see >>> > mantisbt.org/bugs) that I feel need some attention. Many have patches - >>> > although some of these need more work done before applying. >>> >>> Random thought #1: >>> >>> Push some of these to 1.3 and release once all are done ? I will do >>> so for some of mine, e.g. >>> >>> 0008657: [api soap] custom filters >>> 0012478: [db oracle] Installation with Oracle fails >>> >>> Random thought #2: >>> >>> Make time-based releases, which I am a great fan of. But I'm not sure >>> how that would work, given that we contribute mostly in our spare >>> time. We could aim for 'stable' 1.2 releases every 6 / 8 / 12 weeks >>> and push out the door whatever is ready. >>> >>> >> It would make maintenance easier >>> >>> >> and would allow us to focus on getting a first 1.3 milestone out the >>> >> door, hopefully with some noteworthy improvements which would >>> >> encourage our users to try it out. Up til now my policy was to apply >>> >> fixes to both master-1.2.x and master, but that is getting a bit >>> >> tiring, as sometimes they need manual tweaking. >>> > >>> > I strongly agree that applying patches to both branches is a major >>> > hassle. >>> > >>> > Paul, Daryn and myself have started a number of branches on Github that >>> > primarily look at: >>> > >>> > * Removing ADOdb and replacing db_api with a new OO implementation >>> > based >>> > on PDO (much of this effort has already been completed). >>> > >>> > * Reorganising the directory structure (will probably need to be redone >>> > again once DB stuff is completed). >>> > >>> > * The use of templating - or at least major decoupling of UI and logic >>> > in the code. >>> > >>> > I get the feeling that it would have been better to make many of these >>> > changes to the master branch "as it happens". We're stuck in the >>> > situation at the moment where there are 3-4 very promising development >>> > branches that will not merge together. IMO the source code is not >>> > modular enough at the moment to allow for rewriting major MantisBT >>> > components in branches and then merging them back in again. >>> > >>> > Any thoughts? >>> >>> To echo John's thoughts, let's start merging them to master. Otherwise >>> the bits will rot and decompose.The sooner the better. I am willing to >>> test things manually myself, and also having the SOAP API tests in >>> place does give us a little safety net. >>> >>> Given that you hinted that the code is not modular enough right now, >>> perhaps - like John said - merging the 'reorg' branch first would give >>> us the freedom to work independently in branches. >>> >>> Robert >>> >>> > >>> > David > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Sent from my (old) computer |
From: David H. <d...@hx...> - 2011-06-25 12:37:17
|
On Fri, 2011-06-24 at 11:43 -0500, Daryn Warriner wrote: > Here is a link to the new folder layout branch. I've rebased it > against current master. The webserver document root should be pointed > at the public directory. This works for me on linux apache. I don't > have a windows server so if someone could try setting it up and > testing on windows that would be helpful. > > https://github.com/daryn/mantisbt/tree/folder-layout/public Thanks for updating this Daryn. I'll perform some testing, send some patches your way if needed and then hopefully we can merge it into the master branch ASAP. I'd also be interested in taking Paul's database API work and merging it across into this branch. I have tested Paul's db branch fairly extensively and have provided patches where needed. It seems to be working quite well from what I have seen. It does need some further code cleanups, however they can happen once it's merged. David |
From: Daryn W. <da...@ii...> - 2011-06-26 04:32:01
|
Paul's db branch with your (David) github patches merged with folder-layout and modified for namespaces. https://github.com/daryn/mantisbt/tree/db-on-restructure I was able to install and run from this. I only tested on linux with mysql (i think mysql is all that works right now anyway). I did not try an upgrade. Happy testing. Daryn On Sat, Jun 25, 2011 at 7:37 AM, David Hicks <d...@hx...> wrote: > On Fri, 2011-06-24 at 11:43 -0500, Daryn Warriner wrote: > > Here is a link to the new folder layout branch. I've rebased it > > against current master. The webserver document root should be pointed > > at the public directory. This works for me on linux apache. I don't > > have a windows server so if someone could try setting it up and > > testing on windows that would be helpful. > > > > https://github.com/daryn/mantisbt/tree/folder-layout/public > > Thanks for updating this Daryn. > > I'll perform some testing, send some patches your way if needed and then > hopefully we can merge it into the master branch ASAP. > > I'd also be interested in taking Paul's database API work and merging it > across into this branch. I have tested Paul's db branch fairly > extensively and have provided patches where needed. It seems to be > working quite well from what I have seen. It does need some further code > cleanups, however they can happen once it's merged. > > David > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: David H. <d...@hx...> - 2011-06-26 05:13:09
|
On Sat, 2011-06-25 at 23:31 -0500, Daryn Warriner wrote: > Paul's db branch with your (David) github patches merged with > folder-layout and modified for namespaces. > > https://github.com/daryn/mantisbt/tree/db-on-restructure > > > I was able to install and run from this. I only tested on linux with > mysql (i think mysql is all that works right now anyway). I did not > try an upgrade. Happy testing. Great! Thanks Daryn. I propose that this branch be merged into master in one weeks time - the one week being an opportunity to test this branch. It will probably break on other database servers until we're finished rewriting queries to SQL:2008 standards. Once rewritten we'll need to do some query rewriting (per database backend) to handle instances where database servers don't understand SQL:2008 syntax. David |
From: Robert M. <rob...@gm...> - 2011-06-26 20:27:57
|
Should I file any problems as bugs targeted towards 1.3.x ? For instance, uploading attachments fails E_ERRORClass 'MantisBT\Db\stdClass' not found Filename: DriverAbstract.php Line: 223 Also, what should I do to get the SOAP API back? By running the SOAP tests I'll get some decent indicator of whether some areas of MantisBT function as expected ( or not ). Robert On Sun, Jun 26, 2011 at 8:13 AM, David Hicks <d...@hx...> wrote: > On Sat, 2011-06-25 at 23:31 -0500, Daryn Warriner wrote: > > Paul's db branch with your (David) github patches merged with > > folder-layout and modified for namespaces. > > > > https://github.com/daryn/mantisbt/tree/db-on-restructure > > > > > > I was able to install and run from this. I only tested on linux with > > mysql (i think mysql is all that works right now anyway). I did not > > try an upgrade. Happy testing. > > Great! Thanks Daryn. I propose that this branch be merged into master in > one weeks time - the one week being an opportunity to test this branch. > It will probably break on other database servers until we're finished > rewriting queries to SQL:2008 standards. Once rewritten we'll need to do > some query rewriting (per database backend) to handle instances where > database servers don't understand SQL:2008 syntax. > > David > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Sent from my (old) computer |
From: John R. <jo...@no...> - 2011-06-26 21:31:44
|
I would say yes, file issues as bugs against 1.3 -- John Reese noswap.com Sent from my Android phone. Robert Munteanu <rob...@gm...> wrote: Should I file any problems as bugs targeted towards 1.3.x ? For instance, uploading attachments fails E_ERRORClass 'MantisBT\Db\stdClass' not found Filename: DriverAbstract.php Line: 223 Also, what should I do to get the SOAP API back? By running the SOAP tests I'll get some decent indicator of whether some areas of MantisBT function as expected ( or not ). Robert On Sun, Jun 26, 2011 at 8:13 AM, David Hicks <d...@hx...> wrote: On Sat, 2011-06-25 at 23:31 -0500, Daryn Warriner wrote: > Paul's db branch with your (David) github patches merged with > folder-layout and modified for namespaces. > > https://github.com/daryn/mantisbt/tree/db-on-restructure > > > I was able to install and run from this. I only tested on linux with > mysql (i think mysql is all that works right now anyway). I did not > try an upgrade. Happy testing. Great! Thanks Daryn. I propose that this branch be merged into master in one weeks time - the one week being an opportunity to test this branch. It will probably break on other database servers until we're finished rewriting queries to SQL:2008 standards. Once rewritten we'll need to do some query rewriting (per database backend) to handle instances where database servers don't understand SQL:2008 syntax. David ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Sent from my (old) computer |
From: Robert M. <rob...@gm...> - 2011-07-03 18:14:34
|
There you go: http://www.mantisbt.org/bugs/view.php?id=13114 http://www.mantisbt.org/bugs/view.php?id=13115 http://www.mantisbt.org/bugs/view.php?id=13116 Other than that, the application seems stable for me on PHP 5.3.5 / MySQL 5.1.53 . Robert On Mon, Jun 27, 2011 at 12:31 AM, John Reese <jo...@no...> wrote: > I would say yes, file issues as bugs against 1.3 > -- > John Reese > noswap.com > Sent from my Android phone. > > Robert Munteanu <rob...@gm...> wrote: >> >> Should I file any problems as bugs targeted towards 1.3.x ? >> >> For instance, uploading attachments fails >> >> >> E_ERRORClass 'MantisBT\Db\stdClass' not found >> >> Filename: DriverAbstract.php >> >> >> Line: 223 >> >> Also, what should I do to get the SOAP API back? By running the SOAP tests >> I'll get some decent indicator of whether some areas of MantisBT function as >> expected ( or not ). >> >> Robert >> >> On Sun, Jun 26, 2011 at 8:13 AM, David Hicks <d...@hx...> wrote: >>> >>> On Sat, 2011-06-25 at 23:31 -0500, Daryn Warriner wrote: >>> > Paul's db branch with your (David) github patches merged with >>> > folder-layout and modified for namespaces. >>> > >>> > https://github.com/daryn/mantisbt/tree/db-on-restructure >>> > >>> > >>> > I was able to install and run from this. I only tested on linux with >>> > mysql (i think mysql is all that works right now anyway). I did not >>> > try an upgrade. Happy testing. >>> >>> Great! Thanks Daryn. I propose that this branch be merged into master in >>> one weeks time - the one week being an opportunity to test this branch. >>> It will probably break on other database servers until we're finished >>> rewriting queries to SQL:2008 standards. Once rewritten we'll need to do >>> some query rewriting (per database backend) to handle instances where >>> database servers don't understand SQL:2008 syntax. >>> >>> David >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense.. >>> http://p.sf.net/sfu/splunk-d2d-c1 >>> _______________________________________________ >>> mantisbt-dev mailing list >>> man...@li... >>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >>> >> >> >> >> -- >> Sent from my (old) computer > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Sent from my (old) computer |
From: Robert M. <rob...@gm...> - 2011-07-13 10:06:53
|
> On 13.07.2011 11:11, Robert Munteanu wrote: >> Is there anyone who is interested in getting a few more >> fixes in ? > > I have a few minor fixes to the built-in time tracking for which I'm > finishing testing, hope to get it done by end of the week. > > Also, 2 issues which I was discussing with David yesterday > > - http://www.mantisbt.org/bugs/view.php?id=5926 which I think is ready > to go, just need to be committed > - http://www.mantisbt.org/bugs/view.php?id=12948 I have not had time to > test it yet but I think should be included if possible. > > Damien Sounds good. Please reply when all of your planned fixes are committed so we know we can go ahead with the release from your point of view. Thanks, Robert > > > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Damien R. <dam...@me...> - 2011-07-15 16:11:57
|
Hi all, On 13.07.2011 12:06, Robert Munteanu wrote: > Please reply when all of your planned fixes are committed > so we know we can go ahead with the release from your point of view. > > On 07/13/2011 12:01 PM, Damien Regad wrote: >> I have a few minor fixes to the built-in time tracking for which I'm >> finishing testing, hope to get it done by end of the week. I think I'm done for now with bug fixes on Time tracking, and I've also ported all the changes to master. >> - http://www.mantisbt.org/bugs/view.php?id=5926 which I think is ready >> to go, just need to be committed This is done as well. >> - http://www.mantisbt.org/bugs/view.php?id=12948 I have not had time to >> test it yet but I think should be included if possible. I was not able to reproduce the problem, and posted a note on the issue yesterday. I propose to give the reporter (sveyret) a few days to respond. Other than that, I'm ready for 1.2.6 :-) Damien |