From: P R. <pa...@ma...> - 2014-04-04 20:16:56
|
As I think victor knows from my private email's last weekend, I'm really passionate about fixing the Database Layer properly. I'm also really passionate about getting it out to users in a stable and well tested way. We have a habit of not getting releases out, or not testing them properly. Therefore, I'm keen to set a fixed date for a 2.0 release - my proposal for that is 30th April. This is a date that I think is realistically achievable, given what I believe we would need to do before that point. Scope: To avoid feature creep and not getting a release out at this point, I'd like to suggest we stick to 5-10 changes. * New Db Layer I've got an infinite amount of time to get this merged, and fully tested. It's not fair on users who are struggling to make Mantis work on non-mysql DB's not to do this. As already promised, I'll send a daily update on progress of this feature, so we can focus testing and ensure this is 100% stable and tested. We need to ensure api changes that plugin authors may need to follow are well documented. I will be taking some common plugin's and generating a 2.x version as part of the testing, so this should ensure that end users are not caught out with a non-working plugin. * Testing Coverage Improvements To aid in ensuring that we can state the above db layer is stable and tested * Once 1-2 above are done, work with Victor to ensure we have a decent notification API/framework Whilst there are other things I'd like to add/improve in Mantis, for now, the above 3 things are my primary focus (in pretty much the order listed above) Would be useful to know if anyone else would be able to commit to finishing any other new features before 30th April.? Timeline to achieving above goals: * Weekend 4th-6th April o Ensure schema generation on MSSQL o Ensure schema generation on PGSQL o Ensure schema generation on mysql o Ensure schema generation on Oracle o Provide Benchmark figures to mantisbt-dev list of memory/performance improvements of new db layer o Identify edge cases from previous bugs that may need testing. Clone previous bugs on mantisbt.org/bugs to keep history but allow us to re-test and confirm they are still fixed. * 6th-7th April o Generate Tarball that some select/keen end users of pgsql/mssql/oracle and help confirm functuality o Email Word/PDF document to mantisbt-dev list highlighting steps to install our 4 database engines with PHP so that we all have a chance to test future database layer changes in a Virtual Machine or whatever prior to sending to master. Hopefully this will help ensure we don't end up with 'bad schema' updates in the future - especially given some of us are not familiar with some of our database backends * 8th-11th April o Db Layer testing / work out how to handle any db-unique 'issues' without requiring plugin author's etc to understand full details of our 4 database platforms. * 12th-13th April o Get notification API changes merged in * 14th April o 2.0.0a1 ? * 15th - 20th April o Update any remaining Plugins with new db api support * 21st-30th April o Improve Mantis Documentation * 30th April o 2.0.0? |
From: Damien R. <dr...@ma...> - 2014-04-06 13:50:11
|
I am fine with what you wrote on principle, except for 1. the timeline 2. ditching 1.3 And I'm not sure that just having a new DB layer is enough incentive for people to upgrade - I think we would need something that adds end-user value there (e.g. improved UI). On 04.04.2014 22:16, P Richards wrote: > As I think victor knows from my private email’s last weekend, I’m really > passionate about fixing the Database Layer properly. I’m also really > passionate about getting it out to users in a stable and well tested way. > > > > We have a habit of not getting releases out, or not testing them > properly. Therefore, I’m keen to set a fixed date for a 2.0 release – my > proposal for that is 30^th April. This is a date that I think is > realistically achievable, given what I believe we would need to do > before that point. > > > > Scope: > > > > To avoid feature creep and not getting a release out at this point, I’d > like to suggest we stick to 5-10 changes. > > > > · New Db Layer > > I’ve got an infinite amount of time to get this merged, and fully > tested. It’s not fair on users who are struggling to make Mantis work on > non-mysql DB’s not to do this. As already promised, I’ll send a daily > update on progress of this feature, so we can focus testing and ensure > this is 100% stable and tested. > > We need to ensure api changes that plugin authors may need to follow are > well documented. > > I will be taking some common plugin’s and generating a 2.x version as > part of the testing, so this should ensure that end users are not caught > out with a non-working plugin. > > · Testing Coverage Improvements > > To aid in ensuring that we can state the above db layer is stable and tested > > · Once 1-2 above are done, work with Victor to ensure we have a > decent notification API/framework > > Whilst there are other things I’d like to add/improve in Mantis, for > now, the above 3 things are my primary focus (in pretty much the order > listed above) > > > > Would be useful to know if anyone else would be able to commit to > finishing any other new features before 30^th April…? > > > > Timeline to achieving above goals: > > > > · Weekend 4^th -6^th April > > o Ensure schema generation on MSSQL > > o Ensure schema generation on PGSQL > > o Ensure schema generation on mysql > > o Ensure schema generation on Oracle > > o Provide Benchmark figures to mantisbt-dev list of memory/performance > improvements of new db layer > > o Identify edge cases from previous bugs that may need testing. Clone > previous bugs on mantisbt.org/bugs to keep history but allow us to > re-test and confirm they are still fixed. > > · 6^th -7^th April > > o Generate Tarball that some select/keen end users of > pgsql/mssql/oracle and help confirm functuality > > o Email Word/PDF document to mantisbt-dev list highlighting steps to > install our 4 database engines with PHP so that we all have a chance to > test future database layer changes in a Virtual Machine or whatever > prior to sending to master. Hopefully this will help ensure we don’t end > up with ‘bad schema’ updates in the future – especially given some of us > are not familiar with some of our database backends > > · 8^th -11^th April > > o Db Layer testing / work out how to handle any db-unique ‘issues’ > without requiring plugin author’s etc to understand full details of our > 4 database platforms. > > · 12^th -13^th April > > o Get notification API changes merged in > > · 14^th April > > o 2.0.0a1 ? > > · 15^th – 20^th April > > o Update any remaining Plugins with new db api support > > · 21^st -30^th April > > o Improve Mantis Documentation > > · 30^th April > > o 2.0.0? > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Robert M. <rob...@gm...> - 2014-04-09 08:25:34
|
On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad <dr...@ma...> wrote: > I am fine with what you wrote on principle, except for > > 1. the timeline > 2. ditching 1.3 > > And I'm not sure that just having a new DB layer is enough incentive for > people to upgrade - I think we would need something that adds end-user > value there (e.g. improved UI). +1 to the above. I hope a new 1.3 will be incentive enough for people to upgrade. I greatly look forward to an improved DB layer, which is easier to (unit) test and more technically sound, that that can really come in a follow-up feature release. Robert > > > > On 04.04.2014 22:16, P Richards wrote: >> As I think victor knows from my private email’s last weekend, I’m really >> passionate about fixing the Database Layer properly. I’m also really >> passionate about getting it out to users in a stable and well tested way. >> >> >> >> We have a habit of not getting releases out, or not testing them >> properly. Therefore, I’m keen to set a fixed date for a 2.0 release – my >> proposal for that is 30^th April. This is a date that I think is >> realistically achievable, given what I believe we would need to do >> before that point. >> >> >> >> Scope: >> >> >> >> To avoid feature creep and not getting a release out at this point, I’d >> like to suggest we stick to 5-10 changes. >> >> >> >> · New Db Layer >> >> I’ve got an infinite amount of time to get this merged, and fully >> tested. It’s not fair on users who are struggling to make Mantis work on >> non-mysql DB’s not to do this. As already promised, I’ll send a daily >> update on progress of this feature, so we can focus testing and ensure >> this is 100% stable and tested. >> >> We need to ensure api changes that plugin authors may need to follow are >> well documented. >> >> I will be taking some common plugin’s and generating a 2.x version as >> part of the testing, so this should ensure that end users are not caught >> out with a non-working plugin. >> >> · Testing Coverage Improvements >> >> To aid in ensuring that we can state the above db layer is stable and tested >> >> · Once 1-2 above are done, work with Victor to ensure we have a >> decent notification API/framework >> >> Whilst there are other things I’d like to add/improve in Mantis, for >> now, the above 3 things are my primary focus (in pretty much the order >> listed above) >> >> >> >> Would be useful to know if anyone else would be able to commit to >> finishing any other new features before 30^th April…? >> >> >> >> Timeline to achieving above goals: >> >> >> >> · Weekend 4^th -6^th April >> >> o Ensure schema generation on MSSQL >> >> o Ensure schema generation on PGSQL >> >> o Ensure schema generation on mysql >> >> o Ensure schema generation on Oracle >> >> o Provide Benchmark figures to mantisbt-dev list of memory/performance >> improvements of new db layer >> >> o Identify edge cases from previous bugs that may need testing. Clone >> previous bugs on mantisbt.org/bugs to keep history but allow us to >> re-test and confirm they are still fixed. >> >> · 6^th -7^th April >> >> o Generate Tarball that some select/keen end users of >> pgsql/mssql/oracle and help confirm functuality >> >> o Email Word/PDF document to mantisbt-dev list highlighting steps to >> install our 4 database engines with PHP so that we all have a chance to >> test future database layer changes in a Virtual Machine or whatever >> prior to sending to master. Hopefully this will help ensure we don’t end >> up with ‘bad schema’ updates in the future – especially given some of us >> are not familiar with some of our database backends >> >> · 8^th -11^th April >> >> o Db Layer testing / work out how to handle any db-unique ‘issues’ >> without requiring plugin author’s etc to understand full details of our >> 4 database platforms. >> >> · 12^th -13^th April >> >> o Get notification API changes merged in >> >> · 14^th April >> >> o 2.0.0a1 ? >> >> · 15^th – 20^th April >> >> o Update any remaining Plugins with new db api support >> >> · 21^st -30^th April >> >> o Improve Mantis Documentation >> >> · 30^th April >> >> o 2.0.0? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com > > > > ------------------------------------------------------------------------------ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- http://robert.muntea.nu/ |
From: Damien R. <dr...@ma...> - 2014-04-15 13:39:01
|
On 09.04.2014 10:25, Robert Munteanu wrote: > On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad <dr...@ma...> wrote: >> I am fine with what you wrote on principle, except for >> >> 1. the timeline >> 2. ditching 1.3 >> >> And I'm not sure that just having a new DB layer is enough incentive for >> people to upgrade - I think we would need something that adds end-user >> value there (e.g. improved UI). > > +1 to the above. I hope a new 1.3 will be incentive enough for people > to upgrade. So far we have * 2 votes (Robert and I) for immediate release of 1.3 alpha (=master) now and 2.x (=db api + other stuff) later * 1 vote (Paul) to forget 1.3 release and go straight for 2.x Can we please have a response from others on this (Victor, Roland ?) and then take a decision on principle ? Once we have that, we can discuss and agree on the timeline. I would like to add that 2 weeks ago I reluctantly (and somewhat silently) agreed to postpone cutting 1.3.0a1 as it were, to give Paul a chance to complete the DB api so we could review it, and also because I did not have the time or the energy to argue my case. However, the recent wave of updates and pull requests show that he's not only doing that, but instead effectively working on "Paul's 2.0" branch, i.e. changes to configuration, new testing tool (selenium/saucelab), new documentation format (?), etc This is not to say that these efforts are bad, quite the contrary in fact, but I'd like to stay focused on releasing and avoid digressions causing unnecessary delays. Thanks in advance for your feedback. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Paul R. <pa...@ma...> - 2014-04-15 14:46:29
|
"However, the recent wave of updates and pull requests show that he's not only doing that, but instead effectively working on "Paul's 2.0" branch, i.e. changes to configuration, new testing tool (selenium/saucelab), new documentation format (?), etc" Er, 1) Changes to configuration is an old separate patch from 1-2 years ago - Either you or Atrol, I'm pretty sure commented on that patch back then, so I'd hardly call it new work. 2) saucelab/selenium are phpunit tests... I'd hardly call it a new tool. Given that so far when I 'tested' the schema generation in 1.3 for oracle, I hit 2 bugs - that stopped an installation, I'm not sure that complaining about steps to improve testing of our DB support is beneficial? Especially given that my main issue with 1.3 is it's not fair to users to release another broken version of Mantis, and your view is that 1.3 fixes a lot of DB issues - and then my attempt to get it to install ends in failure. On Tue, Apr 15, 2014 at 2:38 PM, Damien Regad <dr...@ma...> wrote: > On 09.04.2014 10:25, Robert Munteanu wrote: > > On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad <dr...@ma...> > wrote: > >> I am fine with what you wrote on principle, except for > >> > >> 1. the timeline > >> 2. ditching 1.3 > >> > >> And I'm not sure that just having a new DB layer is enough incentive for > >> people to upgrade - I think we would need something that adds end-user > >> value there (e.g. improved UI). > > > > +1 to the above. I hope a new 1.3 will be incentive enough for people > > to upgrade. > > So far we have > > * 2 votes (Robert and I) for immediate release of 1.3 alpha (=master) > now and 2.x (=db api + other stuff) later > * 1 vote (Paul) to forget 1.3 release and go straight for 2.x > > Can we please have a response from others on this (Victor, Roland ?) and > then take a decision on principle ? Once we have that, we can discuss > and agree on the timeline. > > I would like to add that 2 weeks ago I reluctantly (and somewhat > silently) agreed to postpone cutting 1.3.0a1 as it were, to give Paul a > chance to complete the DB api so we could review it, and also because I > did not have the time or the energy to argue my case. > > However, the recent wave of updates and pull requests show that he's not > only doing that, but instead effectively working on "Paul's 2.0" branch, > i.e. changes to configuration, new testing tool (selenium/saucelab), new > documentation format (?), etc > > This is not to say that these efforts are bad, quite the contrary in > fact, but I'd like to stay focused on releasing and avoid digressions > causing unnecessary delays. > > Thanks in advance for your feedback. > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Roland B. <ro...@at...> - 2014-04-15 21:19:45
|
> Can we please have a response from others on this (Victor, Roland ?) I hoped to find some time to have a deeper look at Paul's dbapi2 branch and to try an installation of it to get an impression of the quality. But I had just a quite cursory look at dbapi branch until now. I will comment by the end of this week, in worst case just based on my cursory code check and my gut feeling. > Damien Regad <dr...@ma...> hat am 15. April 2014 um 15:38 geschrieben: > > > On 09.04.2014 10:25, Robert Munteanu wrote: > > On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad <dr...@ma...> wrote: > >> I am fine with what you wrote on principle, except for > >> > >> 1. the timeline > >> 2. ditching 1.3 > >> > >> And I'm not sure that just having a new DB layer is enough incentive for > >> people to upgrade - I think we would need something that adds end-user > >> value there (e.g. improved UI). > > > > +1 to the above. I hope a new 1.3 will be incentive enough for people > > to upgrade. > > So far we have > > * 2 votes (Robert and I) for immediate release of 1.3 alpha (=master) > now and 2.x (=db api + other stuff) later > * 1 vote (Paul) to forget 1.3 release and go straight for 2.x > > Can we please have a response from others on this (Victor, Roland ?) and > then take a decision on principle ? Once we have that, we can discuss > and agree on the timeline. > > I would like to add that 2 weeks ago I reluctantly (and somewhat > silently) agreed to postpone cutting 1.3.0a1 as it were, to give Paul a > chance to complete the DB api so we could review it, and also because I > did not have the time or the energy to argue my case. > > However, the recent wave of updates and pull requests show that he's not > only doing that, but instead effectively working on "Paul's 2.0" branch, > i.e. changes to configuration, new testing tool (selenium/saucelab), new > documentation format (?), etc > > This is not to say that these efforts are bad, quite the contrary in > fact, but I'd like to stay focused on releasing and avoid digressions > causing unnecessary delays. > > Thanks in advance for your feedback. > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Victor B. <vb...@ou...> - 2014-04-18 06:55:25
|
I've spent some time thinking about this and had another look at the changes in the pull request. In order for 2.0 to be released, more than just finishing the db changes will need to happen. We will need more stabilization work given the nature of the change. There will also need to be work to make sure that plugins are updated to be compatible with the new release. Hence, I suggest the following:- We kick off 1.3.x release.- Paul continues to validate / polish new db api + use it for his work instance.- We release 1.3.0 (Stable)- Paul merges the db_api into master. (note that this is db_api change and not a branch with N things in it).- We release 1.4.x or 2.0 (whatever we determine the name to be). I think we are calling it 2.0 because it breaks compatibility, as opposed to delivering big value. In reality, a subset of users (those that are still broken) will think of it as a bug fix release.- Bug fixes and features will be applied to both 1.3.x and master branches. So my vote is not to block progress and release 1.3.0a1. The timeline that Paul provided is very aggressive and according to it, we have already shipped 2.0.0a1 and will ship stable by end of month. Note that we can't do better, but here is the timeline from 1.2.0a1 to 1.2.0 (in short: about 2 years):- 1.2.0a1 (Released 2008-04-17) - 1.2.0a2 (Released 2008-08-04)- 1.2.0a3 (Released 2009-01-15)- 1.2.0rc1 (Released 2009-06-23)- 1.2.0rc2 (Released 2009-10-06)- 1.2.0 (Released 2010-02-22) If we keep focus on releasing 1.3.0 stable, I think we can get it done in 3 months. > Date: Tue, 15 Apr 2014 23:19:36 +0200 > From: ro...@at... > To: man...@li...; dr...@ma... > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > Can we please have a response from others on this (Victor, Roland ?) > I hoped to find some time to have a deeper look at Paul's dbapi2 branch and to > try an installation of it to get an impression of the quality. > But I had just a quite cursory look at dbapi branch until now. > > I will comment by the end of this week, in worst case just based on my cursory > code check and my gut feeling. > > > Damien Regad <dr...@ma...> hat am 15. April 2014 um 15:38 geschrieben: > > > > > > On 09.04.2014 10:25, Robert Munteanu wrote: > > > On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad <dr...@ma...> wrote: > > >> I am fine with what you wrote on principle, except for > > >> > > >> 1. the timeline > > >> 2. ditching 1.3 > > >> > > >> And I'm not sure that just having a new DB layer is enough incentive for > > >> people to upgrade - I think we would need something that adds end-user > > >> value there (e.g. improved UI). > > > > > > +1 to the above. I hope a new 1.3 will be incentive enough for people > > > to upgrade. > > > > So far we have > > > > * 2 votes (Robert and I) for immediate release of 1.3 alpha (=master) > > now and 2.x (=db api + other stuff) later > > * 1 vote (Paul) to forget 1.3 release and go straight for 2.x > > > > Can we please have a response from others on this (Victor, Roland ?) and > > then take a decision on principle ? Once we have that, we can discuss > > and agree on the timeline. > > > > I would like to add that 2 weeks ago I reluctantly (and somewhat > > silently) agreed to postpone cutting 1.3.0a1 as it were, to give Paul a > > chance to complete the DB api so we could review it, and also because I > > did not have the time or the energy to argue my case. > > > > However, the recent wave of updates and pull requests show that he's not > > only doing that, but instead effectively working on "Paul's 2.0" branch, > > i.e. changes to configuration, new testing tool (selenium/saucelab), new > > documentation format (?), etc > > > > This is not to say that these efforts are bad, quite the contrary in > > fact, but I'd like to stay focused on releasing and avoid digressions > > causing unnecessary delays. > > > > Thanks in advance for your feedback. > > > > > > --- > > This email is free from viruses and malware because avast! Antivirus > > protection is active. > > http://www.avast.com > > > > > > > > ------------------------------------------------------------------------------ > > Learn Graph Databases - Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > http://p.sf.net/sfu/NeoTech > > _______________________________________________ > > mantisbt-dev mailing list > > man...@li... > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: P R. <pa...@ma...> - 2014-04-18 08:10:22
|
The problem is with that is there are changes in the 1.3.x release relating to databases that are not stable and make it harder to then fix the DB Api, and I need a release version ID to run at work and other users to test the DB API and confirm functionality. So unless we pull out our changes in the 1.3.x branch that change adodb, I'm still against this. In terms of stabilization, this is why I've been spending some time adding unit tests. In terms of your '3 month timeline' for 1.3.0 that just doesn't work, and I still need a 2.0.0a1 release by the end of month. Paul From: Victor Boctor [mailto:vb...@ou...] Sent: 18 April 2014 07:55 To: Roland Becker; MantisBT Dev Mailing List; dr...@ma... Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap I've spent some time thinking about this and had another look at the changes in the pull request. In order for 2.0 to be released, more than just finishing the db changes will need to happen. We will need more stabilization work given the nature of the change. There will also need to be work to make sure that plugins are updated to be compatible with the new release. Hence, I suggest the following: - We kick off 1.3.x release. - Paul continues to validate / polish new db api + use it for his work instance. - We release 1.3.0 (Stable) - Paul merges the db_api into master. (note that this is db_api change and not a branch with N things in it). - We release 1.4.x or 2.0 (whatever we determine the name to be). I think we are calling it 2.0 because it breaks compatibility, as opposed to delivering big value. In reality, a subset of users (those that are still broken) will think of it as a bug fix release. - Bug fixes and features will be applied to both 1.3.x and master branches. So my vote is not to block progress and release 1.3.0a1. The timeline that Paul provided is very aggressive and according to it, we have already shipped 2.0.0a1 and will ship stable by end of month. Note that we can't do better, but here is the timeline from 1.2.0a1 to 1.2.0 (in short: about 2 years): - 1.2.0a1 (Released 2008-04-17) - 1.2.0a2 (Released 2008-08-04) - 1.2.0a3 (Released 2009-01-15) - 1.2.0rc1 (Released 2009-06-23) - 1.2.0rc2 (Released 2009-10-06) - 1.2.0 (Released 2010-02-22) If we keep focus on releasing 1.3.0 stable, I think we can get it done in 3 months. > Date: Tue, 15 Apr 2014 23:19:36 +0200 > From: <mailto:ro...@at...> ro...@at... > To: <mailto:man...@li...> man...@li...; <mailto:dr...@ma...> dr...@ma... > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > Can we please have a response from others on this (Victor, Roland ?) > I hoped to find some time to have a deeper look at Paul's dbapi2 branch and to > try an installation of it to get an impression of the quality. > But I had just a quite cursory look at dbapi branch until now. > > I will comment by the end of this week, in worst case just based on my cursory > code check and my gut feeling. > > > Damien Regad < <mailto:dr...@ma...> dr...@ma...> hat am 15. April 2014 um 15:38 geschrieben: > > > > > > On 09.04.2014 10:25, Robert Munteanu wrote: > > > On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad < <mailto:dr...@ma...> dr...@ma...> wrote: > > >> I am fine with what you wrote on principle, except for > > >> > > >> 1. the timeline > > >> 2. ditching 1.3 > > >> > > >> And I'm not sure that just having a new DB layer is enough incentive for > > >> people to upgrade - I think we would need something that adds end-user > > >> value there (e.g. improved UI). > > > > > > +1 to the above. I hope a new 1.3 will be incentive enough for people > > > to upgrade. > > > > So far we have > > > > * 2 votes (Robert and I) for immediate release of 1.3 alpha (=master) > > now and 2.x (=db api + other stuff) later > > * 1 vote (Paul) to forget 1.3 release and go straight for 2.x > > > > Can we please have a response from others on this (Victor, Roland ?) and > > then take a decision on principle ? Once we have that, we can discuss > > and agree on the timeline. > > > > I would like to add that 2 weeks ago I reluctantly (and somewhat > > silently) agreed to postpone cutting 1.3.0a1 as it were, to give Paul a > > chance to complete the DB api so we could review it, and also because I > > did not have the time or the energy to argue my case. > > > > However, the recent wave of updates and pull requests show that he's not > > only doing that, but instead effectively working on "Paul's 2.0" branch, > > i.e. changes to configuration, new testing tool (selenium/saucelab), new > > documentation format (?), etc > > > > This is not to say that these efforts are bad, quite the contrary in > > fact, but I'd like to stay focused on releasing and avoid digressions > > causing unnecessary delays. > > > > Thanks in advance for your feedback. > > > > > > --- > > This email is free from viruses and malware because avast! Antivirus > > protection is active. > > <http://www.avast.com> http://www.avast.com > > > > > > > > ---------------------------------------------------------------------------- -- > > Learn Graph Databases - Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > <http://p.sf.net/sfu/NeoTech> http://p.sf.net/sfu/NeoTech > > _______________________________________________ > > mantisbt-dev mailing list > > <mailto:man...@li...> man...@li... > > <https://lists.sourceforge.net/lists/listinfo/mantisbt-dev> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > ---------------------------------------------------------------------------- -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > <http://p.sf.net/sfu/NeoTech> http://p.sf.net/sfu/NeoTech > _______________________________________________ > mantisbt-dev mailing list > <mailto:man...@li...> man...@li... > <https://lists.sourceforge.net/lists/listinfo/mantisbt-dev> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Roland B. <ro...@at...> - 2014-04-20 15:21:56
|
I started to write a quite large technical email, but stopped after some more time thinking as an end user. Again the short facts for 1.3.x and 2.0.x from perspective of users running 1.2.x with MySQL (> 90% of our users?) 1.3.x + 2.0.x new functionality: - custom field type text area 1.3.x + 2.0.x dropped functionality: - FTP support for attachments - Usage of PHP < 5.3 - Extended project browser 2.0.x backward compatibility - will break nearly all custom functions - will break nearly all plugins 1.3.x + 2.0.x reasons for Mantis users to upgrade: - will be the supported latest stable version - custom field type text area 2.0.x reasons to upgrade: - None? Thus, +1 for Victor's proposal as it is a good compromise. It allows non breaking upgrade and new/enhanced functionality in short/mid term but also a new DBAL in mid/long term. Skipping 1.3.x is no option, as it will take a long time until 3rd party plugins are compatible with 2.0.x. Of course, the upgrade process for 2.0 should check for installed plugins, give a serious warning to the admin and provide a link to our Wiki where we maintain a white list of 2.0 compatible plugins. Roland > P Richards <pa...@ma...> hat am 18. April 2014 um 10:10 geschrieben: > > > The problem is with that is there are changes in the 1.3.x release relating > to databases that are not stable and make it harder to then fix the DB Api, > and I need a release version ID to run at work and other users to test the > DB API and confirm functionality. So unless we pull out our changes in the > 1.3.x branch that change adodb, I'm still against this. > > > > In terms of stabilization, this is why I've been spending some time adding > unit tests. > > > > In terms of your '3 month timeline' for 1.3.0 that just doesn't work, and I > still need a 2.0.0a1 release by the end of month. > > > > Paul > > > > From: Victor Boctor [mailto:vb...@ou...] > Sent: 18 April 2014 07:55 > To: Roland Becker; MantisBT Dev Mailing List; dr...@ma... > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > > I've spent some time thinking about this and had another look at the changes > in the pull request. In order for 2.0 to be released, more than just > finishing the db changes will need to happen. We will need more > stabilization work given the nature of the change. There will also need to > be work to make sure that plugins are updated to be compatible with the new > release. > > > > Hence, I suggest the following: > > - We kick off 1.3.x release. > > - Paul continues to validate / polish new db api + use it for his work > instance. > > - We release 1.3.0 (Stable) > > - Paul merges the db_api into master. (note that this is db_api change and > not a branch with N things in it). > > - We release 1.4.x or 2.0 (whatever we determine the name to be). I think > we are calling it 2.0 because it breaks compatibility, as opposed to > delivering big value. In reality, a subset of users (those that are still > broken) will think of it as a bug fix release. > > - Bug fixes and features will be applied to both 1.3.x and master branches. > > > > So my vote is not to block progress and release 1.3.0a1. The timeline that > Paul provided is very aggressive and according to it, we have already > shipped 2.0.0a1 and will ship stable by end of month. > > > > Note that we can't do better, but here is the timeline from 1.2.0a1 to 1.2.0 > (in short: about 2 years): > > - 1.2.0a1 (Released 2008-04-17) > > - 1.2.0a2 (Released 2008-08-04) > > - 1.2.0a3 (Released 2009-01-15) > > - 1.2.0rc1 (Released 2009-06-23) > > - 1.2.0rc2 (Released 2009-10-06) > > - 1.2.0 (Released 2010-02-22) > > > > If we keep focus on releasing 1.3.0 stable, I think we can get it done in 3 > months. > > > > > Date: Tue, 15 Apr 2014 23:19:36 +0200 > > From: <mailto:ro...@at...> ro...@at... > > To: <mailto:man...@li...> > man...@li...; <mailto:dr...@ma...> > dr...@ma... > > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > > > Can we please have a response from others on this (Victor, Roland ?) > > I hoped to find some time to have a deeper look at Paul's dbapi2 branch > and to > > try an installation of it to get an impression of the quality. > > But I had just a quite cursory look at dbapi branch until now. > > > > I will comment by the end of this week, in worst case just based on my > cursory > > code check and my gut feeling. > > > > > Damien Regad < <mailto:dr...@ma...> dr...@ma...> hat am > 15. April 2014 um 15:38 geschrieben: > > > > > > > > > On 09.04.2014 10:25, Robert Munteanu wrote: > > > > On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad < > <mailto:dr...@ma...> dr...@ma...> wrote: > > > >> I am fine with what you wrote on principle, except for > > > >> > > > >> 1. the timeline > > > >> 2. ditching 1.3 > > > >> > > > >> And I'm not sure that just having a new DB layer is enough incentive > for > > > >> people to upgrade - I think we would need something that adds > end-user > > > >> value there (e.g. improved UI). > > > > > > > > +1 to the above. I hope a new 1.3 will be incentive enough for people > > > > to upgrade. > > > > > > So far we have > > > > > > * 2 votes (Robert and I) for immediate release of 1.3 alpha (=master) > > > now and 2.x (=db api + other stuff) later > > > * 1 vote (Paul) to forget 1.3 release and go straight for 2.x > > > > > > Can we please have a response from others on this (Victor, Roland ?) and > > > then take a decision on principle ? Once we have that, we can discuss > > > and agree on the timeline. > > > > > > I would like to add that 2 weeks ago I reluctantly (and somewhat > > > silently) agreed to postpone cutting 1.3.0a1 as it were, to give Paul a > > > chance to complete the DB api so we could review it, and also because I > > > did not have the time or the energy to argue my case. > > > > > > However, the recent wave of updates and pull requests show that he's not > > > only doing that, but instead effectively working on "Paul's 2.0" branch, > > > i.e. changes to configuration, new testing tool (selenium/saucelab), new > > > documentation format (?), etc > > > > > > This is not to say that these efforts are bad, quite the contrary in > > > fact, but I'd like to stay focused on releasing and avoid digressions > > > causing unnecessary delays. > > > > > > Thanks in advance for your feedback. > > > > > > > > > --- > > > This email is free from viruses and malware because avast! Antivirus > > > protection is active. > > > <http://www.avast.com> http://www.avast.com > > > > > > > > > > > > > ---------------------------------------------------------------------------- > -- > > > Learn Graph Databases - Download FREE O'Reilly Book > > > "Graph Databases" is the definitive new guide to graph databases and > their > > > applications. Written by three acclaimed leaders in the field, > > > this first edition is now available. Download your free book today! > > > <http://p.sf.net/sfu/NeoTech> http://p.sf.net/sfu/NeoTech > > > _______________________________________________ > > > mantisbt-dev mailing list > > > <mailto:man...@li...> > man...@li... > > > <https://lists.sourceforge.net/lists/listinfo/mantisbt-dev> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > > ---------------------------------------------------------------------------- > -- > > Learn Graph Databases - Download FREE O'Reilly Book > > "Graph Databases" is the definitive new guide to graph databases and their > > applications. Written by three acclaimed leaders in the field, > > this first edition is now available. Download your free book today! > > <http://p.sf.net/sfu/NeoTech> http://p.sf.net/sfu/NeoTech > > _______________________________________________ > > mantisbt-dev mailing list > > <mailto:man...@li...> > man...@li... > > <https://lists.sourceforge.net/lists/listinfo/mantisbt-dev> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: P R. <pa...@ma...> - 2014-04-20 16:17:17
|
1.3.x + 2.0.x new functionality: - custom field type text area The functionality to add an extra column to the custom field tables is something I wanted to drop - as there's no reason to add the extra column. (The reason for adding the extra column was that the data type for the existing column does not allow large enough values. The reason for having the existing column as the existing type was that you couldn't have the larger text type in the table and do filtering on some database engines.) I actually wrote a patch before to drop that extra column and change the existing type as either a) the reason for not changing the type no longer exists or b) by adding the type to the same table, we've broken filtering so we need a separate table. In any case, we should work out whether it's A or B before users start using that field. As an aside, I believe I'm still on track to have the DBAL finished by the end of the month (10 days) from now, and would like to release a version of Mantis for users to test on ORACLE + PGSQL + MSSQL in that timeframe. Additionally, having spent the last 2 weeks working on the DBAL layer, I'm beginning to firmly believe that if we do a 1.3 release based around ADODB, we should make the release MYSQL only. Paul -----Original Message----- From: Roland Becker [mailto:ro...@at...] Sent: 20 April 2014 16:22 To: 'developer discussions'; dr...@ma...; P Richards Subject: RE: [mantisbt-dev] Mantis 2.x Roadmap I started to write a quite large technical email, but stopped after some more time thinking as an end user. Again the short facts for 1.3.x and 2.0.x from perspective of users running 1.2.x with MySQL (> 90% of our users?) 1.3.x + 2.0.x new functionality: - custom field type text area 1.3.x + 2.0.x dropped functionality: - FTP support for attachments - Usage of PHP < 5.3 - Extended project browser 2.0.x backward compatibility - will break nearly all custom functions - will break nearly all plugins 1.3.x + 2.0.x reasons for Mantis users to upgrade: - will be the supported latest stable version - custom field type text area 2.0.x reasons to upgrade: - None? Thus, +1 for Victor's proposal as it is a good compromise. It allows non breaking upgrade and new/enhanced functionality in short/mid term but also a new DBAL in mid/long term. Skipping 1.3.x is no option, as it will take a long time until 3rd party plugins are compatible with 2.0.x. Of course, the upgrade process for 2.0 should check for installed plugins, give a serious warning to the admin and provide a link to our Wiki where we maintain a white list of 2.0 compatible plugins. Roland > P Richards <pa...@ma...> hat am 18. April 2014 um 10:10 geschrieben: > > > The problem is with that is there are changes in the 1.3.x release > relating to databases that are not stable and make it harder to then > fix the DB Api, and I need a release version ID to run at work and > other users to test the DB API and confirm functionality. So unless we > pull out our changes in the 1.3.x branch that change adodb, I'm still against this. > > > > In terms of stabilization, this is why I've been spending some time > adding unit tests. > > > > In terms of your '3 month timeline' for 1.3.0 that just doesn't work, > and I still need a 2.0.0a1 release by the end of month. > > > > Paul > > > > From: Victor Boctor [mailto:vb...@ou...] > Sent: 18 April 2014 07:55 > To: Roland Becker; MantisBT Dev Mailing List; dr...@ma... > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > > I've spent some time thinking about this and had another look at the > changes in the pull request. In order for 2.0 to be released, more > than just finishing the db changes will need to happen. We will need > more stabilization work given the nature of the change. There will > also need to be work to make sure that plugins are updated to be > compatible with the new release. > > > > Hence, I suggest the following: > > - We kick off 1.3.x release. > > - Paul continues to validate / polish new db api + use it for his work > instance. > > - We release 1.3.0 (Stable) > > - Paul merges the db_api into master. (note that this is db_api > change and not a branch with N things in it). > > - We release 1.4.x or 2.0 (whatever we determine the name to be). I > think we are calling it 2.0 because it breaks compatibility, as > opposed to delivering big value. In reality, a subset of users (those > that are still > broken) will think of it as a bug fix release. > > - Bug fixes and features will be applied to both 1.3.x and master branches. > > > > So my vote is not to block progress and release 1.3.0a1. The timeline > that Paul provided is very aggressive and according to it, we have > already shipped 2.0.0a1 and will ship stable by end of month. > > > > Note that we can't do better, but here is the timeline from 1.2.0a1 to > 1.2.0 (in short: about 2 years): > > - 1.2.0a1 (Released 2008-04-17) > > - 1.2.0a2 (Released 2008-08-04) > > - 1.2.0a3 (Released 2009-01-15) > > - 1.2.0rc1 (Released 2009-06-23) > > - 1.2.0rc2 (Released 2009-10-06) > > - 1.2.0 (Released 2010-02-22) > > > > If we keep focus on releasing 1.3.0 stable, I think we can get it done > in 3 months. > > > > > Date: Tue, 15 Apr 2014 23:19:36 +0200 > > From: <mailto:ro...@at...> ro...@at... > > To: <mailto:man...@li...> > man...@li...; <mailto:dr...@ma...> > dr...@ma... > > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > > > Can we please have a response from others on this (Victor, Roland > > > ?) > > I hoped to find some time to have a deeper look at Paul's dbapi2 > > branch > and to > > try an installation of it to get an impression of the quality. > > But I had just a quite cursory look at dbapi branch until now. > > > > I will comment by the end of this week, in worst case just based on > > my > cursory > > code check and my gut feeling. > > > > > Damien Regad < <mailto:dr...@ma...> dr...@ma...> > > > hat am > 15. April 2014 um 15:38 geschrieben: > > > > > > > > > On 09.04.2014 10:25, Robert Munteanu wrote: > > > > On Sun, Apr 6, 2014 at 4:45 PM, Damien Regad < > <mailto:dr...@ma...> dr...@ma...> wrote: > > > >> I am fine with what you wrote on principle, except for > > > >> > > > >> 1. the timeline > > > >> 2. ditching 1.3 > > > >> > > > >> And I'm not sure that just having a new DB layer is enough > > > >> incentive > for > > > >> people to upgrade - I think we would need something that adds > end-user > > > >> value there (e.g. improved UI). > > > > > > > > +1 to the above. I hope a new 1.3 will be incentive enough for > > > > +people > > > > to upgrade. > > > > > > So far we have > > > > > > * 2 votes (Robert and I) for immediate release of 1.3 alpha > > > (=master) now and 2.x (=db api + other stuff) later > > > * 1 vote (Paul) to forget 1.3 release and go straight for 2.x > > > > > > Can we please have a response from others on this (Victor, Roland > > > ?) and then take a decision on principle ? Once we have that, we > > > can discuss and agree on the timeline. > > > > > > I would like to add that 2 weeks ago I reluctantly (and somewhat > > > silently) agreed to postpone cutting 1.3.0a1 as it were, to give > > > Paul a chance to complete the DB api so we could review it, and > > > also because I did not have the time or the energy to argue my case. > > > > > > However, the recent wave of updates and pull requests show that > > > he's not only doing that, but instead effectively working on > > > "Paul's 2.0" branch, i.e. changes to configuration, new testing > > > tool (selenium/saucelab), new documentation format (?), etc > > > > > > This is not to say that these efforts are bad, quite the contrary > > > in fact, but I'd like to stay focused on releasing and avoid > > > digressions causing unnecessary delays. > > > > > > Thanks in advance for your feedback. > > > > > > > > > --- > > > This email is free from viruses and malware because avast! > > >Antivirus protection is active. > > > <http://www.avast.com> http://www.avast.com > > > > > > > > > > > > > ---------------------------------------------------------------------- > ------ > -- > > > Learn Graph Databases - Download FREE O'Reilly Book "Graph > > > Databases" is the definitive new guide to graph databases and > their > > > applications. Written by three acclaimed leaders in the field, > > >this first edition is now available. Download your free book today! > > > <http://p.sf.net/sfu/NeoTech> http://p.sf.net/sfu/NeoTech > > >_______________________________________________ > > > mantisbt-dev mailing list > > > <mailto:man...@li...> > man...@li... > > > <https://lists.sourceforge.net/lists/listinfo/mantisbt-dev> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > > ---------------------------------------------------------------------- > ------ > -- > > Learn Graph Databases - Download FREE O'Reilly Book "Graph > >Databases" is the definitive new guide to graph databases and their > >applications. Written by three acclaimed leaders in the field, this > >first edition is now available. Download your free book today! > > <http://p.sf.net/sfu/NeoTech> http://p.sf.net/sfu/NeoTech > >_______________________________________________ > > mantisbt-dev mailing list > > <mailto:man...@li...> > man...@li... > > <https://lists.sourceforge.net/lists/listinfo/mantisbt-dev> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: P R. <pa...@ma...> - 2014-04-20 17:55:41
|
> 2.0.x reasons to upgrade: > - None? Actually the main reasons for upgrading would be to be able to run PGSQL, MSSQL or ORACLE as your database backend Paul |
From: Glenn H. <thr...@ma...> - 2014-04-21 04:26:55
|
On Apr 20, 2014, at 10:55 AM, P Richards <pa...@ma...> wrote: >> 2.0.x reasons to upgrade: >> - None? > > Actually the main reasons for upgrading would be to be able to run PGSQL, MSSQL or ORACLE as your database backend > > Paul > I'm not sure that this is compelling for 80% of the users. Most Linux distros come with MySQL or equivalent installed. PGSQL is an option. ... Glenn |
From: P R. <pa...@ma...> - 2014-04-21 09:50:55
|
Well, if you take that as not compelling for 80% of users - it does basically leave you with the fact that 1.3.x is not compelling if Roland's email is accurate.. He lists 3 things we 'drop' and states the reason to upgrade being it's the latest stable versin and custom field text area. The custom field text area is something that I've actually argued isn't implemented as it should be - it adds a second column to a table, we should look at merging that column into the original column (I actually wrote a patch to do this and I think move the data). There's no point adding a second column (and wasting the bytes of storage for that column ) in mysql. For either SQLSRV or PGSQL, I believe the reason the data type wasn't larger, used to be to do with the queries we construct for filtering - i.e. if a blob/clob type field was used, you then couldn't search on the table/column. Given the current implementation just says use this column or this column name, either: a) There's no point adding a second column, and we should simplify the code and change the type of the existing column or b) we've introduced a possible bug which may be either i) we can't filter on the new custom field type or ii) we might need to look at whether we need to create a separate table for the new custom field type, and move the data out of the existing second column. --- and we should work out which of A or B it is before going forward with doing a release with this functionality in (I've complained about the current implementation before) before we do a release. If only for the simple reason that it's going to be a lot quicker and safer to migrate the data to where it is sensible to live, before people add data. In terms of database engines, Damien is passionate about Oracle - He sees a potential growth area for mantis in corporate companies here I believe. My personal feeling was to be less convinced as I've always felt Oracle is $$$'s, and I'm not sure companies that spend $$$'s will then run Mantis. However, having said that, if the company standard is oracle, and we support it, I'm sure some people will run it. Similarly, I feel that there's a potential growth area for Mantis in the windows environment - Microsoft spent a lot of time trying to make PHP "work" on windows and with windows 2008, improve the performance of PHP. Whilst this is them combating the growth of linux, I see having good Windows Support as opening us up to a new market. My personal feeling with PGSQL, is that where it's a nice database engine (arguably nicer), It doesn't feel like it has the same mass-market appeal of the other databases. I would not be surprised to see usage of database in Mantis in terms of most number of users to be Mysql followed by MSSQL, then oracle and then pgsql. -----Original Message----- From: Glenn Henshaw [mailto:thr...@ma...] Sent: 21 April 2014 05:27 To: developer discussions Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap On Apr 20, 2014, at 10:55 AM, P Richards <pa...@ma...> wrote: >> 2.0.x reasons to upgrade: >> - None? > > Actually the main reasons for upgrading would be to be able to run > PGSQL, MSSQL or ORACLE as your database backend > > Paul > I'm not sure that this is compelling for 80% of the users. Most Linux distros come with MySQL or equivalent installed. PGSQL is an option. ... Glenn ---------------------------------------------------------------------------- -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Damien R. <dr...@ma...> - 2014-04-23 14:30:13
|
On 21.04.2014 11:50, P Richards wrote: > The custom field text area is something that I've actually argued isn't > implemented as it should be - it adds a second column to a table, we should > look at merging that column into the original column (I actually wrote a > patch to do this and I think move the data). There's no point adding a > second column (and wasting the bytes of storage for that column ) in mysql. That feature was implemented by Daryn in 2010 (!) see #6626 and http://github.com/mantisbt/mantisbt/commit/839f1d68b While I can accept your point that it's not done right, why wait 3.5 years to complain about it ? > For either SQLSRV or PGSQL, I believe the reason the data type wasn't > larger, used to be to do with the queries we construct for filtering - i.e. > if a blob/clob type field was used, you then couldn't search on the > table/column. Given the current implementation just says use this column or > this column name, either: > > a) There's no point adding a second column, and we should simplify the code > and change the type of the existing column > > or > > b) we've introduced a possible bug which may be either i) we can't filter on > the new custom field type or ii) we might need to look at whether we need to > create a separate table for the new custom field type, and move the data out > of the existing second column. > > --- and we should work out which of A or B it is before going forward with > doing a release with this functionality in (I've complained about the > current implementation before) before we do a release. If only for the > simple reason that it's going to be a lot quicker and safer to migrate the > data to where it is sensible to live, before people add data. >From my perspective, while I'll grant you that it may not be the best implementation, it has the benefit of being there vs not having the feature at all. Since you seem to feel strongly about it and mention having written a patch for it, then I would suggest you port it and submit a pull request for review before the end of the week so we can include the proper solution in 1.3. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Paul R. <pa...@ma...> - 2014-04-23 15:03:40
|
On Wed, Apr 23, 2014 at 3:25 PM, Damien Regad <dr...@ma...> wrote: > On 21.04.2014 11:50, P Richards wrote: > > The custom field text area is something that I've actually argued isn't > > implemented as it should be - it adds a second column to a table, we > should > > look at merging that column into the original column (I actually wrote a > > patch to do this and I think move the data). There's no point adding a > > second column (and wasting the bytes of storage for that column ) in > mysql. > > That feature was implemented by Daryn in 2010 (!) see #6626 and > http://github.com/mantisbt/mantisbt/commit/839f1d68b > > While I can accept your point that it's not done right, why wait 3.5 > years to complain about it ? > > We actually had a rather lengthy discussion about it on the day is was committed - http://www.mantisbt.org/irclogs/mantishelp/2010/mantishelp.2010-08-25.log.html Since you seem to feel strongly about it and mention having written a > patch for it, then I would suggest you port it and submit a pull request > for review before the end of the week so we can include the proper > solution in 1.3. > I will work out what works and what doesn't on Saturday, and put in a pull request if/as appropriate on Saturday. My "Patch" was on the basis that if that code works as it is, we don't need to do 2 columns - what I actually need to work out, is whether the code works as is. Paul |
From: P R. <pa...@ma...> - 2014-04-24 21:13:47
|
Right, initial impression on this (albeit, filter api issues aren't helping), is that I don't think we need 2 separate fields - at least not for SQLSRV2012 which is where I thought the problem was, so unless I can work out what issue I thought existed: I'm fairly inclined to add a schema update of: $upgrade[190] = array( 'AlterColumn', array( '{custom_field_string}', "value XL NULL DEFAULT NULL " ) ); Paul -----Original Message----- From: Damien Regad [mailto:dr...@ma...] Sent: 23 April 2014 15:25 To: Man...@li... Subject: [mantisbt-dev] Memo custom field type On 21.04.2014 11:50, P Richards wrote: > The custom field text area is something that I've actually argued > isn't implemented as it should be - it adds a second column to a > table, we should look at merging that column into the original column > (I actually wrote a patch to do this and I think move the data). > There's no point adding a second column (and wasting the bytes of storage for that column ) in mysql. That feature was implemented by Daryn in 2010 (!) see #6626 and http://github.com/mantisbt/mantisbt/commit/839f1d68b While I can accept your point that it's not done right, why wait 3.5 years to complain about it ? > For either SQLSRV or PGSQL, I believe the reason the data type wasn't > larger, used to be to do with the queries we construct for filtering - i.e. > if a blob/clob type field was used, you then couldn't search on the > table/column. Given the current implementation just says use this > column or this column name, either: > > a) There's no point adding a second column, and we should simplify the > code and change the type of the existing column > > or > > b) we've introduced a possible bug which may be either i) we can't > filter on the new custom field type or ii) we might need to look at > whether we need to create a separate table for the new custom field > type, and move the data out of the existing second column. > > --- and we should work out which of A or B it is before going forward > with doing a release with this functionality in (I've complained about > the current implementation before) before we do a release. If only for > the simple reason that it's going to be a lot quicker and safer to > migrate the data to where it is sensible to live, before people add data. >From my perspective, while I'll grant you that it may not be the best implementation, it has the benefit of being there vs not having the feature at all. Since you seem to feel strongly about it and mention having written a patch for it, then I would suggest you port it and submit a pull request for review before the end of the week so we can include the proper solution in 1.3. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ---------------------------------------------------------------------------- -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Damien R. <dr...@ma...> - 2014-04-22 17:08:34
|
On 20.04.2014 17:21, Roland Becker wrote: > Thus, +1 for Victor's proposal as it is a good compromise. > It allows non breaking upgrade and new/enhanced functionality in short/mid term > but also a new DBAL in mid/long term. > Skipping 1.3.x is no option, as it will take a long time until 3rd party plugins > are compatible with 2.0.x. Thanks all for your responses. With this last answer we have a decision: 4 votes for (Roland, Robert, Victor, Damien) 1 vote against (Paul) Therefore I'll move forward with release of 1.3.0a1 later this week as time allows, following Victor's suggested plan. On 18.04.2014 08:55, Victor Boctor wrote: > - We kick off 1.3.x release. > - Paul continues to validate / polish new db api + use it for his work > instance. > - We release 1.3.0 (Stable) > - Paul merges the db_api into master. (note that this is db_api change > and not a branch with N things in it). > - We release 1.4.x or 2.0 (whatever we determine the name to be). I > think we are calling it 2.0 because it breaks compatibility, as opposed > to delivering big value. In reality, a subset of users (those that are > still broken) will think of it as a bug fix release. > - Bug fixes and features will be applied to both 1.3.x and master branches. I propose to create a new "2.x" version on mantisbt.org, to facilitate Paul's efforts and allow easy and transparent tracking of his progress on 2.0 (for sure it should not be called 1.4) independently of the work on 1.3, even though the changes would continue to reside on his private fork until we're ready to merge after 1.3.0 release. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: P R. <pa...@ma...> - 2014-04-22 17:10:33
|
Actually, that's not a decision - as I've said on my other posts to the list, I still think we've got some issues that need further discussion before we push out a 1.3.x release. Paul -----Original Message----- From: Damien Regad [mailto:dr...@ma...] Sent: 22 April 2014 18:08 To: Man...@li... Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap On 20.04.2014 17:21, Roland Becker wrote: > Thus, +1 for Victor's proposal as it is a good compromise. > It allows non breaking upgrade and new/enhanced functionality in > short/mid term but also a new DBAL in mid/long term. > Skipping 1.3.x is no option, as it will take a long time until 3rd > party plugins are compatible with 2.0.x. Thanks all for your responses. With this last answer we have a decision: 4 votes for (Roland, Robert, Victor, Damien) 1 vote against (Paul) Therefore I'll move forward with release of 1.3.0a1 later this week as time allows, following Victor's suggested plan. On 18.04.2014 08:55, Victor Boctor wrote: > - We kick off 1.3.x release. > - Paul continues to validate / polish new db api + use it for his work > instance. > - We release 1.3.0 (Stable) > - Paul merges the db_api into master. (note that this is db_api > change and not a branch with N things in it). > - We release 1.4.x or 2.0 (whatever we determine the name to be). I > think we are calling it 2.0 because it breaks compatibility, as > opposed to delivering big value. In reality, a subset of users (those > that are still broken) will think of it as a bug fix release. > - Bug fixes and features will be applied to both 1.3.x and master branches. I propose to create a new "2.x" version on mantisbt.org, to facilitate Paul's efforts and allow easy and transparent tracking of his progress on 2.0 (for sure it should not be called 1.4) independently of the work on 1.3, even though the changes would continue to reside on his private fork until we're ready to merge after 1.3.0 release. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ---------------------------------------------------------------------------- -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Roland B. <ro...@at...> - 2014-04-22 17:17:06
|
I agree if you are talking about to add an extra column to the custom field tables for text area custom fields. > P Richards <pa...@ma...> hat am 22. April 2014 um 19:10 geschrieben: > > > Actually, that's not a decision - as I've said on my other posts to the > list, I still think we've got some issues that need further discussion > before we push out a 1.3.x release. > > Paul > > > -----Original Message----- > From: Damien Regad [mailto:dr...@ma...] > Sent: 22 April 2014 18:08 > To: Man...@li... > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > On 20.04.2014 17:21, Roland Becker wrote: > > Thus, +1 for Victor's proposal as it is a good compromise. > > It allows non breaking upgrade and new/enhanced functionality in > > short/mid term but also a new DBAL in mid/long term. > > Skipping 1.3.x is no option, as it will take a long time until 3rd > > party plugins are compatible with 2.0.x. > > Thanks all for your responses. With this last answer we have a decision: > > 4 votes for (Roland, Robert, Victor, Damien) > 1 vote against (Paul) > > Therefore I'll move forward with release of 1.3.0a1 later this week as time > allows, following Victor's suggested plan. > > On 18.04.2014 08:55, Victor Boctor wrote: > > - We kick off 1.3.x release. > > - Paul continues to validate / polish new db api + use it for his work > > instance. > > - We release 1.3.0 (Stable) > > - Paul merges the db_api into master. (note that this is db_api > > change and not a branch with N things in it). > > - We release 1.4.x or 2.0 (whatever we determine the name to be). I > > think we are calling it 2.0 because it breaks compatibility, as > > opposed to delivering big value. In reality, a subset of users (those > > that are still broken) will think of it as a bug fix release. > > - Bug fixes and features will be applied to both 1.3.x and master > branches. > > I propose to create a new "2.x" version on mantisbt.org, to facilitate > Paul's efforts and allow easy and transparent tracking of his progress on > 2.0 (for sure it should not be called 1.4) independently of the work on 1.3, > even though the changes would continue to reside on his private fork until > we're ready to merge after 1.3.0 release. > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > > ---------------------------------------------------------------------------- > -- > Start Your Social Network Today - Download eXo Platform Build your > Enterprise Intranet with eXo Platform Software Java Based Open Source > Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your > Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: P R. <pa...@ma...> - 2014-04-22 17:21:45
|
I've still got a security issue I want to discuss with people (Although I've not yet spent the time to email the team as my focus has been on finishing the DB Layer first). In addition, I did make the point that we should consider making 1.3 a MYSQL only release - that's not been discussed And I've made the point about the custom field table - that's not been discussed -----Original Message----- From: Roland Becker [mailto:ro...@at...] Sent: 22 April 2014 18:17 To: developer discussions; P Richards Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap I agree if you are talking about to add an extra column to the custom field tables for text area custom fields. > P Richards <pa...@ma...> hat am 22. April 2014 um 19:10 geschrieben: > > > Actually, that's not a decision - as I've said on my other posts to > the list, I still think we've got some issues that need further > discussion before we push out a 1.3.x release. > > Paul > > > -----Original Message----- > From: Damien Regad [mailto:dr...@ma...] > Sent: 22 April 2014 18:08 > To: Man...@li... > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > On 20.04.2014 17:21, Roland Becker wrote: > > Thus, +1 for Victor's proposal as it is a good compromise. > > It allows non breaking upgrade and new/enhanced functionality in > > short/mid term but also a new DBAL in mid/long term. > > Skipping 1.3.x is no option, as it will take a long time until 3rd > > party plugins are compatible with 2.0.x. > > Thanks all for your responses. With this last answer we have a decision: > > 4 votes for (Roland, Robert, Victor, Damien) > 1 vote against (Paul) > > Therefore I'll move forward with release of 1.3.0a1 later this week as > time allows, following Victor's suggested plan. > > On 18.04.2014 08:55, Victor Boctor wrote: > > - We kick off 1.3.x release. > > - Paul continues to validate / polish new db api + use it for his > > work instance. > > - We release 1.3.0 (Stable) > > - Paul merges the db_api into master. (note that this is db_api > > change and not a branch with N things in it). > > - We release 1.4.x or 2.0 (whatever we determine the name to be). I > > think we are calling it 2.0 because it breaks compatibility, as > > opposed to delivering big value. In reality, a subset of users > > (those that are still broken) will think of it as a bug fix release. > > - Bug fixes and features will be applied to both 1.3.x and master > branches. > > I propose to create a new "2.x" version on mantisbt.org, to facilitate > Paul's efforts and allow easy and transparent tracking of his progress > on > 2.0 (for sure it should not be called 1.4) independently of the work > on 1.3, even though the changes would continue to reside on his > private fork until we're ready to merge after 1.3.0 release. > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > > ---------------------------------------------------------------------- > ------ > -- > Start Your Social Network Today - Download eXo Platform Build your > Enterprise Intranet with eXo Platform Software Java Based Open Source > Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn > Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > ---------------------------------------------------------------------- > -------- Start Your Social Network Today - Download eXo Platform Build > your Enterprise Intranet with eXo Platform Software Java Based Open > Source Intranet - Social, Extensible, Cloud Ready Get Started Now And > Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Paul R. <gra...@bl...> - 2014-04-22 19:35:33
|
Also, need to fix: $t_email = filter_var( $p_email, FILTER_SANITIZE_EMAIL ); if( PHPMailer::ValidateAddress( $t_email ) ) { $t_domain = end( explode( '@', $t_email ) ); -----Original Message----- From: P Richards [mailto:pa...@ma...] Sent: 22 April 2014 18:22 To: 'Roland Becker'; 'developer discussions' Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap I've still got a security issue I want to discuss with people (Although I've not yet spent the time to email the team as my focus has been on finishing the DB Layer first). In addition, I did make the point that we should consider making 1.3 a MYSQL only release - that's not been discussed And I've made the point about the custom field table - that's not been discussed -----Original Message----- From: Roland Becker [mailto:ro...@at...] Sent: 22 April 2014 18:17 To: developer discussions; P Richards Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap I agree if you are talking about to add an extra column to the custom field tables for text area custom fields. > P Richards <pa...@ma...> hat am 22. April 2014 um 19:10 geschrieben: > > > Actually, that's not a decision - as I've said on my other posts to > the list, I still think we've got some issues that need further > discussion before we push out a 1.3.x release. > > Paul > > > -----Original Message----- > From: Damien Regad [mailto:dr...@ma...] > Sent: 22 April 2014 18:08 > To: Man...@li... > Subject: Re: [mantisbt-dev] Mantis 2.x Roadmap > > > On 20.04.2014 17:21, Roland Becker wrote: > > Thus, +1 for Victor's proposal as it is a good compromise. > > It allows non breaking upgrade and new/enhanced functionality in > > short/mid term but also a new DBAL in mid/long term. > > Skipping 1.3.x is no option, as it will take a long time until 3rd > > party plugins are compatible with 2.0.x. > > Thanks all for your responses. With this last answer we have a decision: > > 4 votes for (Roland, Robert, Victor, Damien) > 1 vote against (Paul) > > Therefore I'll move forward with release of 1.3.0a1 later this week as > time allows, following Victor's suggested plan. > > On 18.04.2014 08:55, Victor Boctor wrote: > > - We kick off 1.3.x release. > > - Paul continues to validate / polish new db api + use it for his > > work instance. > > - We release 1.3.0 (Stable) > > - Paul merges the db_api into master. (note that this is db_api > > change and not a branch with N things in it). > > - We release 1.4.x or 2.0 (whatever we determine the name to be). I > > think we are calling it 2.0 because it breaks compatibility, as > > opposed to delivering big value. In reality, a subset of users > > (those that are still broken) will think of it as a bug fix release. > > - Bug fixes and features will be applied to both 1.3.x and master > branches. > > I propose to create a new "2.x" version on mantisbt.org, to facilitate > Paul's efforts and allow easy and transparent tracking of his progress > on > 2.0 (for sure it should not be called 1.4) independently of the work > on 1.3, even though the changes would continue to reside on his > private fork until we're ready to merge after 1.3.0 release. > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > > ---------------------------------------------------------------------- > ------ > -- > Start Your Social Network Today - Download eXo Platform Build your > Enterprise Intranet with eXo Platform Software Java Based Open Source > Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn > Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > ---------------------------------------------------------------------- > -------- Start Your Social Network Today - Download eXo Platform Build > your Enterprise Intranet with eXo Platform Software Java Based Open > Source Intranet - Social, Extensible, Cloud Ready Get Started Now And > Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev ---------------------------------------------------------------------------- -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Damien R. <dr...@ma...> - 2014-04-23 14:20:12
|
On 22.04.2014 21:35, Paul Richards wrote: > Also, need to fix: > > $t_email = filter_var( $p_email, FILTER_SANITIZE_EMAIL ); > if( PHPMailer::ValidateAddress( $t_email ) ) { > $t_domain = end( explode( '@', $t_email ) ); Can you clarify what needs to be fixed here ? --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Paul R. <pa...@ma...> - 2014-04-23 14:22:43
|
Whilst I don't like the use of phpmailer for validation, the actual thing that needs to be fixed here is the pass-by-referend on the end() line i.e. we need to do $t_foo = explode ('@', $t_email); $t_domain = end($t_foo) On Wed, Apr 23, 2014 at 3:06 PM, Damien Regad <dr...@ma...> wrote: > On 22.04.2014 21:35, Paul Richards wrote: > > Also, need to fix: > > > > $t_email = filter_var( $p_email, FILTER_SANITIZE_EMAIL ); > > if( PHPMailer::ValidateAddress( $t_email ) ) { > > $t_domain = end( explode( '@', $t_email ) ); > > Can you clarify what needs to be fixed here ? > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Damien R. <dr...@ma...> - 2014-04-23 14:35:12
|
On 23.04.2014 16:22, Paul Richards wrote: > Whilst I don't like the use of phpmailer for validation, the actual > thing that needs to be fixed here is the pass-by-referend on the end() line > > i.e. we need to do $t_foo = explode ('@', $t_email); $t_domain = end($t_foo) I tested this successfully on PHP 5.3.2 which is our minimum supported version. According to the manual [1], this syntax is supported since 4.0.4, so am I missing something ? [1] http://www.php.net/manual/en/language.references.pass.php --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Paul R. <pa...@ma...> - 2014-04-23 14:41:41
|
I was trying to call user_create( 'user', 'pass', 'no...@ma...' ); in a unit test and getting the error under php 5.5 - and your comment about missing something - I had the same thought when looking at the code :) I initially thought it was going to be something with the line before i.e. phpmailer. On Wed, Apr 23, 2014 at 3:34 PM, Damien Regad <dr...@ma...> wrote: > On 23.04.2014 16:22, Paul Richards wrote: > > Whilst I don't like the use of phpmailer for validation, the actual > > thing that needs to be fixed here is the pass-by-referend on the end() > line > > > > i.e. we need to do $t_foo = explode ('@', $t_email); $t_domain = > end($t_foo) > > I tested this successfully on PHP 5.3.2 which is our minimum supported > version. > > According to the manual [1], this syntax is supported since 4.0.4, so am > I missing something ? > > > [1] http://www.php.net/manual/en/language.references.pass.php > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |