From: Roland B. <ro...@at...> - 2012-10-11 15:32:29
|
Victor, maybe you want to update mantisbt.org/bugs? Is there a script for it? On Mon, Oct 8, 2012 at 10:16 PM, Victor Boctor <victor@...> wrote: > +1 for updating mantisbt.org/bugs for validation. Once we are ready with > the packages, I can upload the release. |
From: Damien R. <dam...@me...> - 2012-10-11 23:22:04
|
I have updated mantisbt.org to the latest mantisbt-1.2.x trunk (c4b12ce). While I was at it, I made the following changes in config_inc.php - removed obsolete configs - commented out $g_version_suffix (as the release tarball script sets it in a better way, including git commit, in config_defaults_inc.php) - changed $g_max_file_size to match php.ini settings To facilitate an eventual rollback of the tracker, I kept the old code under bugs.old just in case. I also updated the deployed plugins to their respective, current git HEAD. D |
From: Victor B. <vi...@fu...> - 2012-10-15 03:01:51
|
I've noticed an issue with the soap API with issues 14744 and 14721. The issues have some special characters in them that cause the PHP SOAP extension (SoapClient) to complain that the response is not valid XML. I've checked the response and it seems like a valid SOAP response. My guess is that the special characters are not encoded correctly. The issue breaks APIs that returns list of issues as well as details about a specific issue. So it doesn't seem to be an API specific issue. Robert, are you able to reproduce this? On Thu, Oct 11, 2012 at 4:21 PM, Damien Regad <dam...@me...>wrote: > I have updated mantisbt.org to the latest mantisbt-1.2.x trunk (c4b12ce). > > While I was at it, I made the following changes in config_inc.php > - removed obsolete configs > - commented out $g_version_suffix (as the release tarball script sets it > in a > better way, including git commit, in config_defaults_inc.php) > - changed $g_max_file_size to match php.ini settings > > To facilitate an eventual rollback of the tracker, I kept the old code > under > bugs.old just in case. > > I also updated the deployed plugins to their respective, current git HEAD. > > D > > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Robert M. <rob...@gm...> - 2012-10-15 12:00:36
|
On Mon, Oct 15, 2012 at 6:01 AM, Victor Boctor <vi...@fu...> wrote: > I've noticed an issue with the soap API with issues 14744 and 14721. The > issues have some special characters in them that cause the PHP SOAP > extension (SoapClient) to complain that the response is not valid XML. I've > checked the response and it seems like a valid SOAP response. My guess is > that the special characters are not encoded correctly. > > The issue breaks APIs that returns list of issues as well as details about a > specific issue. So it doesn't seem to be an API specific issue. > > Robert, are you able to reproduce this? Yes, this was reported quite some time ago at 11230: High-ascii characters in fields will cause invalidity in XML. http://www.mantisbt.org/bugs/view.php?id=11230 I never did find the time for a proper fix though. Robert > > On Thu, Oct 11, 2012 at 4:21 PM, Damien Regad <dam...@me...> > wrote: >> >> I have updated mantisbt.org to the latest mantisbt-1.2.x trunk (c4b12ce). >> >> While I was at it, I made the following changes in config_inc.php >> - removed obsolete configs >> - commented out $g_version_suffix (as the release tarball script sets it >> in a >> better way, including git commit, in config_defaults_inc.php) >> - changed $g_max_file_size to match php.ini settings >> >> To facilitate an eventual rollback of the tracker, I kept the old code >> under >> bugs.old just in case. >> >> I also updated the deployed plugins to their respective, current git HEAD. >> >> D >> >> >> >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Damien R. <dam...@me...> - 2012-10-15 08:17:39
|
Victor Boctor <victor@...> writes: > I've noticed an issue with the soap API with issues 14744 and 14721. > The issues have some special characters in them that cause the PHP > SOAP extension (SoapClient) to complain that the response is not valid > XML. I've checked the response and it seems like a valid SOAP > response. My guess is that the special characters are not encoded > correctly. This is data-related. Through copy/paste, it is possible to enter characters into the tracker's text fields, that are not valid per XML specification. 1.2 branch is fine with that, but 1.3 chokes on them due to XHTML (and logically, the same goes for SOAP API since it uses XML). Please have a look at the commits related to the 2 mentioned issues, particularly http://github.com/mantisbt/mantisbt/commit/2b5d66217bd4ecf5e7271f1a4b2b339d7681e91c, to fix the problem SOAP should use the modified string_html_specialchars() function to remove invalid chars when outputting data from text fields D |
From: Robert M. <rob...@gm...> - 2012-10-15 12:01:36
|
On Mon, Oct 15, 2012 at 11:17 AM, Damien Regad <dam...@me...> wrote: > Victor Boctor <victor@...> writes: >> I've noticed an issue with the soap API with issues 14744 and 14721. >> The issues have some special characters in them that cause the PHP >> SOAP extension (SoapClient) to complain that the response is not valid >> XML. I've checked the response and it seems like a valid SOAP >> response. My guess is that the special characters are not encoded >> correctly. > > This is data-related. Through copy/paste, it is possible to enter characters > into the tracker's text fields, that are not valid per XML specification. 1.2 > branch is fine with that, but 1.3 chokes on them due to XHTML (and logically, > the same goes for SOAP API since it uses XML). > > Please have a look at the commits related to the 2 mentioned issues, > particularly > http://github.com/mantisbt/mantisbt/commit/2b5d66217bd4ecf5e7271f1a4b2b339d7681e91c, > to fix the problem SOAP should use the modified string_html_specialchars() > function to remove invalid chars when outputting data from text fields Thanks for the reference. I'm wondering still if we shouldn't reject these characters from being submitted? Robert > > D > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Sent from my (old) computer |
From: Damien R. <dam...@me...> - 2012-10-15 14:00:34
|
Robert Munteanu <robert.munteanu@...> writes: > Thanks for the reference. I'm wondering still if we shouldn't reject > these characters from being submitted? On principle yes, and in fact I was thinking of doing the same thing initially, but then I decided to fix the output instead, because - adding an input check does not fix existing data - there are countless ways of entering data into the system including plugins, etc which may not follow the same logic - output check guarantees that we never break a page display - it's less work ;-) See also dhx's argument on input vs output validation in [1] - original issue relates to XSS on the user real name field, but I think the logic applies everywhere. "issues should be handled on the output side of MantisBT rather than on the input side. [...] input side which is poor design due to the many number of ways in which a [date] could change [...]. Furthermore different output interfaces (XML, CSS, XHTML, etc) require different sanitisation and escaping methods." That said, I'm not 100% sure what I did in #14744 is truly correct, since it can potentially lead to destruction of data (store invald xml char in mantis -> open edit page -> special chars are removed -> save data -> invalid chars are gone). I'm sure there is a better way, maybe using CDATA to output all text fields. [1] http://www.mantisbt.org/bugs/view.php?id=12368 |
From: Robert M. <rob...@gm...> - 2012-10-17 19:59:44
|
On Mon, Oct 15, 2012 at 5:00 PM, Damien Regad <dam...@me...> wrote: > Robert Munteanu <robert.munteanu@...> writes: >> Thanks for the reference. I'm wondering still if we shouldn't reject >> these characters from being submitted? > > On principle yes, and in fact I was thinking of doing the same thing initially, > but then I decided to fix the output instead, because > > - adding an input check does not fix existing data > - there are countless ways of entering data into the system including plugins, > etc which may not follow the same logic > - output check guarantees that we never break a page display > - it's less work ;-) > > See also dhx's argument on input vs output validation in [1] - original issue > relates to XSS on the user real name field, but I think the logic applies > everywhere. > > "issues should be handled on the output side of MantisBT rather than on the > input side. [...] input side which is poor design due to the many number of ways > in which a [date] could change [...]. Furthermore different output interfaces > (XML, CSS, XHTML, etc) require different sanitisation and escaping methods." > > That said, I'm not 100% sure what I did in #14744 is truly correct, since it can > potentially lead to destruction of data (store invald xml char in mantis -> open > edit page -> special chars are removed -> save data -> invalid chars are gone). > I'm sure there is a better way, maybe using CDATA to output all text fields. That was my single concern actually. So I'd rather find a way to escape it in a 'legal' manner which can be used for both MantisBT master and for the SOAP UI. Robert > > [1] http://www.mantisbt.org/bugs/view.php?id=12368 > > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Sent from my (old) computer |
From: Victor B. <vb...@gm...> - 2012-10-15 16:03:44
|
Isn't it nusoap's job to escape the output? If we escape within Mantis won't the data be double escaped? In my mind escaping should be completely transparent to client / service code. A couple of options to add here: - fix nusoap bug - use php soap instead of nusoap. Sent from my Phone On Oct 15, 2012, at 7:00 AM, Damien Regad <dam...@me...> wrote: > Robert Munteanu <robert.munteanu@...> writes: >> Thanks for the reference. I'm wondering still if we shouldn't reject >> these characters from being submitted? > > On principle yes, and in fact I was thinking of doing the same thing initially, > but then I decided to fix the output instead, because > > - adding an input check does not fix existing data > - there are countless ways of entering data into the system including plugins, > etc which may not follow the same logic > - output check guarantees that we never break a page display > - it's less work ;-) > > See also dhx's argument on input vs output validation in [1] - original issue > relates to XSS on the user real name field, but I think the logic applies > everywhere. > > "issues should be handled on the output side of MantisBT rather than on the > input side. [...] input side which is poor design due to the many number of ways > in which a [date] could change [...]. Furthermore different output interfaces > (XML, CSS, XHTML, etc) require different sanitisation and escaping methods." > > That said, I'm not 100% sure what I did in #14744 is truly correct, since it can > potentially lead to destruction of data (store invald xml char in mantis -> open > edit page -> special chars are removed -> save data -> invalid chars are gone). > I'm sure there is a better way, maybe using CDATA to output all text fields. > > [1] http://www.mantisbt.org/bugs/view.php?id=12368 > > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Robert M. <rob...@gm...> - 2012-10-17 20:02:38
|
On Mon, Oct 15, 2012 at 7:03 PM, Victor Boctor <vb...@gm...> wrote: > Isn't it nusoap's job to escape the output? If we escape within Mantis won't the data be double escaped? In my mind escaping should be completely transparent to client / service code. > > A couple of options to add here: > > - fix nusoap bug Right. Can you double-check that the repo at https://github.com/mantisbt/nusoap conforms to our discussion referring the third party tracking repositories? You were part of that discussion and it would allow me to start fixing nusoap stuff. Although the fix might not be trivial. > - use php soap instead of nusoap That's something for the long run. I'm not sure it's feasible without major rework. I would like to do have them both work in parallel ( nusoap and php5-soap ) and have a switch for the admin to do that, defaulting to nusoap on master-1.2.x and php5-nusoap on master. Robert > > Sent from my Phone > > On Oct 15, 2012, at 7:00 AM, Damien Regad <dam...@me...> wrote: > >> Robert Munteanu <robert.munteanu@...> writes: >>> Thanks for the reference. I'm wondering still if we shouldn't reject >>> these characters from being submitted? >> >> On principle yes, and in fact I was thinking of doing the same thing initially, >> but then I decided to fix the output instead, because >> >> - adding an input check does not fix existing data >> - there are countless ways of entering data into the system including plugins, >> etc which may not follow the same logic >> - output check guarantees that we never break a page display >> - it's less work ;-) >> >> See also dhx's argument on input vs output validation in [1] - original issue >> relates to XSS on the user real name field, but I think the logic applies >> everywhere. >> >> "issues should be handled on the output side of MantisBT rather than on the >> input side. [...] input side which is poor design due to the many number of ways >> in which a [date] could change [...]. Furthermore different output interfaces >> (XML, CSS, XHTML, etc) require different sanitisation and escaping methods." >> >> That said, I'm not 100% sure what I did in #14744 is truly correct, since it can >> potentially lead to destruction of data (store invald xml char in mantis -> open >> edit page -> special chars are removed -> save data -> invalid chars are gone). >> I'm sure there is a better way, maybe using CDATA to output all text fields. >> >> [1] http://www.mantisbt.org/bugs/view.php?id=12368 >> >> >> >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Sent from my (old) computer |
From: Damien R. <dam...@me...> - 2012-10-28 03:05:06
|
I have not yet had time to review Roland's feedback on the fix for http://www.mantisbt.org/bugs/view.php?id=14496, which I consider blocking for releasing 1.2.12 This is next on my todo list though ;-) D |
From: Roland B. <ro...@at...> - 2012-10-28 10:56:25
|
It's an old bug and not a regression. Why do you think it's blocking? BTW, I will not be able to invest much for MantisBT until mid December. I hope our user Goal will help if you need a tester http://www.mantisbt.org/bugs/view.php?id=14496#c33321 Damien Regad <dam...@me...> hat am 28. Oktober 2012 um 04:02 geschrieben: > I have not yet had time to review Roland's feedback on the fix for > http://www.mantisbt.org/bugs/view.php?id=14496, which I consider blocking for > releasing 1.2.12 > > This is next on my todo list though ;-) > > D > > > ------------------------------------------------------------------------------ > WINDOWS 8 is here. > Millions of people. Your app in 30 days. > Visit The Windows 8 Center at Sourceforge for all your go to resources. > http://windows8center.sourceforge.net/ > join-generation-app-and-make-money-coding-fast/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Damien R. <dam...@me...> - 2012-10-28 12:53:43
|
On 28.10.2012 11:56, Roland Becker wrote: > It's an old bug and not a regression. > Why do you think it's blocking? Because of the issue you noticed with the "Close" button after I updated the tracker at mantisbt.org a few weeks ago... D |
From: Roland B. <ro...@at...> - 2012-10-29 20:25:50
|
Damien Regad <dam...@me...> hat am 28. Oktober 2012 um 13:53 geschrieben: > On 28.10.2012 11:56, Roland Becker wrote: > > It's an old bug and not a regression. > > Why do you think it's blocking? > > Because of the issue you noticed with the "Close" button after I updated > the tracker at mantisbt.org a few weeks ago... > The issue with the "Close" button was not caused by the update. It was caused by using the configuration page and would have been occured also with version 1.2.11. So I still think that #14496 is not a blocking issue for 1.2.12. Ok, let's stop the "blocking" discussion. I try to find some time to have a look at your new fixes. |
From: Robert M. <rob...@gm...> - 2012-11-07 20:58:39
|
Since I'm waiting for the 1.2.12 release to merge back my SOAP changes, is there anything we're still missing to start the release process? On Mon, Oct 29, 2012 at 10:25 PM, Roland Becker <ro...@at...> wrote: > Damien Regad <dam...@me...> hat am 28. Oktober 2012 um 13:53 > geschrieben: >> On 28.10.2012 11:56, Roland Becker wrote: >> > It's an old bug and not a regression. >> > Why do you think it's blocking? >> >> Because of the issue you noticed with the "Close" button after I updated >> the tracker at mantisbt.org a few weeks ago... >> > > The issue with the "Close" button was not caused by the update. > It was caused by using the configuration page and would have been occured also > with version 1.2.11. > So I still think that #14496 is not a blocking issue for 1.2.12. > > Ok, let's stop the "blocking" discussion. > I try to find some time to have a look at your new fixes. > > ------------------------------------------------------------------------------ > The Windows 8 Center - In partnership with Sourceforge > Your idea - your app - 30 days. > Get started! > http://windows8center.sourceforge.net/ > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Sent from my (old) computer |
From: Paul R. <pa...@ma...> - 2012-11-07 21:31:31
|
I've just been having a look through the changes between 1.2.11 and 1.2.12. There seems to be some things that appear to be "new"/unused features as opposed to minor bug fixes. For example, there's a new 'json' api that isn't used ( https://github.com/mantisbt/mantisbt/blob/master-1.2.x/core/json_api.php ) within the core code. Ignoring the fact that my personal view would probably be that whilst we do need a json api, we need to look at it properly bla bla bla (along side webservices), surely this is something that should go into master and not be back-ported to a 1.2 release. (P.S. my logic for saying this is that, if we move to 'exceptions', json_error_handler becomes a deprecated function) However, It's more highlighting the wider issue that in the past we've used the release branch for bugfixes *only*, with new features going into our master branch. I know it does't help that we've got different views on 'master', but I'm also not sure whether adding new features into master-1.2.x helps either. P.S. there's also some new features from Rombert/Damien that whilst i'd state the same above point about releases, are probably features that would work in 1.3/next/2.0/1.2 etc without any changes. I don't have a tarball of 1.2.12 and 1.2.11 handly atm, how long is the diff between the two versions? Paul On Wed, Nov 7, 2012 at 8:58 PM, Robert Munteanu <rob...@gm...>wrote: > Since I'm waiting for the 1.2.12 release to merge back my SOAP > changes, is there anything we're still missing to start the release > process? > > On Mon, Oct 29, 2012 at 10:25 PM, Roland Becker <ro...@at...> wrote: > > Damien Regad <dam...@me...> hat am 28. Oktober 2012 um > 13:53 > > geschrieben: > >> On 28.10.2012 11:56, Roland Becker wrote: > >> > It's an old bug and not a regression. > >> > Why do you think it's blocking? > >> > >> Because of the issue you noticed with the "Close" button after I updated > >> the tracker at mantisbt.org a few weeks ago... > >> > > > > The issue with the "Close" button was not caused by the update. > > It was caused by using the configuration page and would have been > occured also > > with version 1.2.11. > > So I still think that #14496 is not a blocking issue for 1.2.12. > > > > Ok, let's stop the "blocking" discussion. > > I try to find some time to have a look at your new fixes. > > > > > ------------------------------------------------------------------------------ > > The Windows 8 Center - In partnership with Sourceforge > > Your idea - your app - 30 days. > > Get started! > > http://windows8center.sourceforge.net/ > > > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ > > _______________________________________________ > > mantisbt-dev mailing list > > man...@li... > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > -- > Sent from my (old) computer > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Damien R. <dam...@me...> - 2012-11-07 23:44:44
|
On 07.11.2012 21:58, Robert Munteanu wrote: > Since I'm waiting for the 1.2.12 release to merge back my SOAP > changes, is there anything we're still missing to start the release > process? I'm almost there. Was actually hoping to finalize things last week-end, but got sidetracked. If all goes well, everything should be ready to go by end of this week. I already prepared the release notes & stuff - https://github.com/dregad/mantisbt/commits/1.2.12 D |
From: Damien R. <dam...@me...> - 2012-11-07 23:50:02
|
On 07.11.2012 22:31, Paul Richards wrote: > I don't have a tarball of 1.2.12 and 1.2.11 handly atm, how long is the > diff between the two versions? Versus my local WIP 1.2.12 release candidate branch's head: $ git diff release-1.2.11 --shortstat 185 files changed, 4988 insertions(+), 3377 deletions(-) $ git log --oneline release-1.2.11..HEAD |wc -l 149 |
From: Paul R. <pa...@ma...> - 2012-11-08 20:33:38
|
As someone has just come on irc asking: "[08:21.30] <Vooch2> what improvements were made in mantisbt 1.2 versus 1.1? I'm trying todecide if I need to go with 1.2, or stick with apt-get install, which is 1.1 on ubuntu." i've just had a quick look at the mantis 'bug tracker' in ubuntu and there's a post where regarding stabilising 1.2.11 - https://bugs.launchpad.net/ubuntu/+source/mantis/+bug/1011823 To quote us: In Gentoo Bugzilla #420375, David Hicks (dhx) wrote on 2012-09-26: #9 >From a MantisBT developer point-of-view I don't see any reason for holding back on stabilisation. *We're fairly strict about what goes into minor version bumps (security and small bug fixes).* * * 8000 line diff = 'security and small bug fixes' ? On Wed, Nov 7, 2012 at 11:47 PM, Damien Regad <dam...@me...>wrote: > On 07.11.2012 22:31, Paul Richards wrote: > > I don't have a tarball of 1.2.12 and 1.2.11 handly atm, how long is the > > diff between the two versions? > > Versus my local WIP 1.2.12 release candidate branch's head: > > $ git diff release-1.2.11 --shortstat > 185 files changed, 4988 insertions(+), 3377 deletions(-) > > $ git log --oneline release-1.2.11..HEAD |wc -l > 149 > > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Robert M. <rob...@gm...> - 2012-11-08 20:36:05
|
On Thu, Nov 8, 2012 at 10:33 PM, Paul Richards <pa...@ma...> wrote: > As someone has just come on irc asking: > > "[08:21.30] <Vooch2> what improvements were made in mantisbt 1.2 versus 1.1? > I'm trying todecide if I need to go with 1.2, or stick with apt-get install, > which is 1.1 on ubuntu." > > i've just had a quick look at the mantis 'bug tracker' in ubuntu and there's > a post where regarding stabilising 1.2.11 - > https://bugs.launchpad.net/ubuntu/+source/mantis/+bug/1011823 > > To quote us: > > In Gentoo Bugzilla #420375, David Hicks (dhx) wrote on 2012-09-26: #9 > From a MantisBT developer point-of-view I don't see any reason for holding > back on stabilisation. We're fairly strict about what goes into minor > version bumps (security and small bug fixes). > > 8000 line diff = 'security and small bug fixes' ? Let's call it 1.3 alpha 1 and start breaking things. I mean, distros integrate Chromium and Firefox, don't they? Robert > > On Wed, Nov 7, 2012 at 11:47 PM, Damien Regad <dam...@me...> > wrote: >> >> On 07.11.2012 22:31, Paul Richards wrote: >> > I don't have a tarball of 1.2.12 and 1.2.11 handly atm, how long is the >> > diff between the two versions? >> >> Versus my local WIP 1.2.12 release candidate branch's head: >> >> $ git diff release-1.2.11 --shortstat >> 185 files changed, 4988 insertions(+), 3377 deletions(-) >> >> $ git log --oneline release-1.2.11..HEAD |wc -l >> 149 >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_nov >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Victor B. <vi...@fu...> - 2012-11-09 04:47:39
|
I think it is fair to have this discussion about a checkin bar ones we have a healthy rhythm of feature releases. We seem to have two extremes right now, the long term multi-year branches (next/2.x), and the order(weeks) branch (master-1.2.x). It may make sense to have the next feature release branch of 1.2.x until we have 2.x ready, and then we evaluate the move to that. If we do that, then we can offload some of the features to that branch (let's name it master-1.3.x) On Thu, Nov 8, 2012 at 12:33 PM, Paul Richards <pa...@ma...> wrote: > As someone has just come on irc asking: > > "[08:21.30] <Vooch2> what improvements were made in mantisbt 1.2 versus > 1.1? I'm trying todecide if I need to go with 1.2, or stick with apt-get > install, which is 1.1 on ubuntu." > > i've just had a quick look at the mantis 'bug tracker' in ubuntu and > there's a post where regarding stabilising 1.2.11 - > https://bugs.launchpad.net/ubuntu/+source/mantis/+bug/1011823 > > To quote us: > > In Gentoo Bugzilla #420375, David Hicks (dhx) wrote on 2012-09-26: #9 > From a MantisBT developer point-of-view I don't see any reason for holding > back on stabilisation. *We're fairly strict about what goes into minor > version bumps (security and small bug fixes).* > * > * > 8000 line diff = 'security and small bug fixes' ? > > On Wed, Nov 7, 2012 at 11:47 PM, Damien Regad <dam...@me... > > wrote: > >> On 07.11.2012 22:31, Paul Richards wrote: >> > I don't have a tarball of 1.2.12 and 1.2.11 handly atm, how long is the >> > diff between the two versions? >> >> Versus my local WIP 1.2.12 release candidate branch's head: >> >> $ git diff release-1.2.11 --shortstat >> 185 files changed, 4988 insertions(+), 3377 deletions(-) >> >> $ git log --oneline release-1.2.11..HEAD |wc -l >> 149 >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_nov >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: Robert M. <rob...@gm...> - 2012-11-08 20:35:25
|
On Wed, Nov 7, 2012 at 11:31 PM, Paul Richards <pa...@ma...> wrote: > I've just been having a look through the changes between 1.2.11 and 1.2.12. > > There seems to be some things that appear to be "new"/unused features as > opposed to minor bug fixes. > > For example, there's a new 'json' api that isn't used ( > https://github.com/mantisbt/mantisbt/blob/master-1.2.x/core/json_api.php ) > within the core code. Yes, I've introduced to prototype its usage in a plugin [1] to provide in-page validation . If I'm happy with how this turns out from a UI/code point of view I will consider porting it to master-1.2.x . As I've mentioned before, I'm trying to unify the APIs behind a service layer so that I can easily ( for users with Javacript enabled ) provide in-page validation without requiring Javascript to be available. > > Ignoring the fact that my personal view would probably be that whilst we do > need a json api, we need to look at it properly bla bla bla (along side > webservices), surely this is something that should go into master and not be > back-ported to a 1.2 release. > > (P.S. my logic for saying this is that, if we move to 'exceptions', > json_error_handler becomes a deprecated function) If we do that, we'll remove all occurences of trigger_error anyway. The point of the trigger_error handler for json and also for soap is that the code does not need to know whether to wrap the error in XML or HTML or JSON or whatever. It just works. > > However, It's more highlighting the wider issue that in the past we've used > the release branch for bugfixes *only*, with new features going into our > master branch. > > I know it does't help that we've got different views on 'master', but I'm > also not sure whether adding new features into master-1.2.x helps either. Right, first of all let's agree to disagree :-) , at least for now. IMO in practice this 'no new features in stable branches' has translated in no new features for two and a half years.I've tried to squeeze in minor features now and then but I'm not happy with the rate of changes. Frankly, for me as a 'new' developer this means that I haven't had the change to contribute even one major change. And the reason is that the major release never does come. I'd be happy with such feature freezes if we choose to release majors periodically, like every 6 months. It's either that, or a rolling release model. Rolling out major releases every 3 years and rewriting from scratch worked fine for Netscape :-) > > P.S. there's also some new features from Rombert/Damien that whilst i'd > state the same above point about releases, are probably features that would > work in 1.3/next/2.0/1.2 etc without any changes. > > I don't have a tarball of 1.2.12 and 1.2.11 handly atm, how long is the diff > between the two versions? > > Paul > > > [1]: https://github.com/mantisbt-plugins/customer-management > > On Wed, Nov 7, 2012 at 8:58 PM, Robert Munteanu <rob...@gm...> > wrote: >> >> Since I'm waiting for the 1.2.12 release to merge back my SOAP >> changes, is there anything we're still missing to start the release >> process? >> >> On Mon, Oct 29, 2012 at 10:25 PM, Roland Becker <ro...@at...> wrote: >> > Damien Regad <dam...@me...> hat am 28. Oktober 2012 um >> > 13:53 >> > geschrieben: >> >> On 28.10.2012 11:56, Roland Becker wrote: >> >> > It's an old bug and not a regression. >> >> > Why do you think it's blocking? >> >> >> >> Because of the issue you noticed with the "Close" button after I >> >> updated >> >> the tracker at mantisbt.org a few weeks ago... >> >> >> > >> > The issue with the "Close" button was not caused by the update. >> > It was caused by using the configuration page and would have been >> > occured also >> > with version 1.2.11. >> > So I still think that #14496 is not a blocking issue for 1.2.12. >> > >> > Ok, let's stop the "blocking" discussion. >> > I try to find some time to have a look at your new fixes. >> > >> > >> > ------------------------------------------------------------------------------ >> > The Windows 8 Center - In partnership with Sourceforge >> > Your idea - your app - 30 days. >> > Get started! >> > http://windows8center.sourceforge.net/ >> > >> > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ >> > _______________________________________________ >> > mantisbt-dev mailing list >> > man...@li... >> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> >> >> >> -- >> Sent from my (old) computer >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Central: Instant, anywhere, Remote PC access and management. >> Stay in control, update software, and manage PCs from one command center >> Diagnose problems and improve visibility into emerging IT issues >> Automate, monitor and manage. Do more in less time with Central >> http://p.sf.net/sfu/logmein12331_d2d >> >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Paul R. <pa...@ma...> - 2012-11-11 01:14:17
|
On Thu, Nov 8, 2012 at 8:35 PM, Robert Munteanu <rob...@gm...>wrote: > On Wed, Nov 7, 2012 at 11:31 PM, Paul Richards <pa...@ma...> > wrote: > > I've just been having a look through the changes between 1.2.11 and > 1.2.12. > > > > There seems to be some things that appear to be "new"/unused features as > > opposed to minor bug fixes. > > > > For example, there's a new 'json' api that isn't used ( > > https://github.com/mantisbt/mantisbt/blob/master-1.2.x/core/json_api.php) > > within the core code. > > Yes, I've introduced to prototype its usage in a plugin [1] to provide > in-page validation . If I'm happy with how this turns out from a > UI/code point of view I will consider porting it to master-1.2.x . > > As I've mentioned before, I'm trying to unify the APIs behind a > service layer so that I can easily ( for users with Javacript enabled > ) provide in-page validation without requiring Javascript to be > available. > > If we are going to 'randomnly' add a json api, can I suggest we at least make it so it's something we might be able to build on in the future. For example, the json-rpc specification uses result and error->code/message as text identifiers - the following patch would make the json api follow this standard more: Or is there another standard that specificies the naming you picked? Paul @@ -88,26 +88,27 @@ function json_error_handler( $p_type, $p_error, $p_file, $p_line, $p_context ) { $t_error_type = ''; $t_error_description = $p_error; } json_output_raw(array( - 'status' => 'ERROR', - 'type' => $t_error_type, - 'contents' => $t_error_description + 'result' => null, + 'error' => array( 'name' => $t_error_type, + 'message' => $t_error_description) )); } /** * Outputs the specified contents inside a json response with OK status * * <p>Ensures that all necessary headers are set and terminates processing.</p> * @param string $contents The contents to encode */ - function json_output_response ( $contents = '') { + function json_output_response ( $contents = '', $id = 1 ) { json_output_raw( array( - 'status' => 'OK', - 'contents' => $contents + 'error' => null, + 'result' => $contents, + 'id' => $id ) ); } |
From: Damien R. <dam...@me...> - 2012-11-09 10:24:44
|
On Thu, Nov 8, 2012 at 12:33 PM, Paul Richards <pa...@ma...> wrote: > 8000 line diff = 'security and small bug fixes' ? Paul, Just to avoid making a mountain out of an anthill, note that the actual change in MantisBT core is not that significant. If you break it down by what was changed, only 40% (3200 lines) is our code - 30% of which are related to soap. Category Lines Code mantis 993 core plugins 206 soap 2086 library 2679 (new version of phpmailer) Others translations 1567 documentation 572 |
From: Damien R. <dam...@me...> - 2012-11-09 10:30:12
|
On 9 Nov 05:47, Victor Boctor <victor@...> writes: > I think it is fair to have this discussion about a checkin bar ones we > have a healthy rhythm of feature releases. We seem to have two extremes > right now, the long term multi-year branches (next/2.x), and the > order(weeks) branch (master-1.2.x). It may make sense to have the next > feature release branch of 1.2.x until we have 2.x ready, and then we > evaluate the move to that. If we do that, then we can offload some of > the features to that branch (let's name it master-1.3.x) Victor, I'm not sure if I understand what you mean. Are you saying that 1.2.12dev should be released as 1.3 ? >From previous discussions, I thought we would do - release 1.2.12 - release candidate 2.0 based on Paul's work - release 1.3 (optional, depending on when 2.0 can be ready) |