mantisbt-dev — MantisBT development discussions

Re: [mantisbt-dev] Staging 1.3 for release

[Victor B. <vb...@gm...>]

Paul, the goal is not to pull all the changes in 2.0/next.  We avoided these branches to reduce the churn to enable 1.3 going out and to be able to review the changes.  You porting these changes fixed the latter, but not the churn problem.

@dregad’s suggestion:

- (Paul) stop submitting 5-10 pull requests per day for now,
- focus on testing and fixing issues and stabilization instead, then
- get alpha out the door ASAP, and 
- resume the new features fest after 1.3.0a1 is out. 

@vboctor’s suggestion:

- blocking bug fixes
- functional bug fixes
- security bugs

Branching to be discussed after 1.3a1 is out.

Let’s focus on stablization, upgrading our tracker and getting 1.3.0a1/b1 out.

I’ve started doing some testing on master and adding some 1.3 support to plugins that I authored or contributed to.

I’ll also start responding to pull requests based on the above criteria since at least 3 of us seem to be on board with it.

On Sep 19, 2014, at 2:04 PM, P Richards <pa...@ma...> wrote:

> Roland,
> 
> I think the initial with the 1.2 and historical fixes was that we didn't have plan post 1.2.
> 
> In terms of 1.3, I'd like to see us support this longer term, so I think it would be good to see us bug port more bug fixes.
> 
> I've not had much time so far in September to spend on Mantis Development, as I work in a school and the first few weeks are really busy. 
> 
> Now that the first few weeks are done, I should be able to dedicate more time towards mantis. At the moment, I'm going through existing patches that people offered to help get committed from next/master-2.x before we look at 1.3.
> 
> You'll probably see the pace of that development accelerate over the next month as I'll have some free time to work on Mantis, coupled with some free work time to throw in.
> 
> Hopefully we can get as much merged as possible to reduce both the work in keeping the patches sync'd up to the current master, and to avoid having what we've had before of doing a release and then having massive churn on master.
> 
> I will have pull requests for every patch against master-2 / next in github within the next 7-10 days.
> 
> This will allow us to delete the historical next/master-2.x branches.
> 
> I've then got 2-3 new features that I'd like to put forward in October, and plan to spend some time trying to stabilise master for a release at that point.
> 
> I suggested two weeks ago that we set a date of end of October for new development - when I said " to branch 1.3 for release" - I meant for an alpha release, and not for a final release.
> 
> In terms of 'when to branch' - we should branch master into 1.3 before the first alpha release. But equally, that should be done at the point everyone's had a chance to get any changes in before the branch. Whilst I know that I've not had much time to dedicate to Mantis for the last month, and I know I'm about to get a chunk of time to spend on mantis for the next month, others may have different schedules. The rational for saying we should set an "end of October" or even "end of November" date or similar timescale was to give everyone a chance to finalise any patches before we move to a period of stabilisation. 
> 
> Paul
> 
> 
> -----Original Message-----
> From: Roland Becker [mailto:ro...@at...] 
> Sent: 19 September 2014 10:51
> To: developer discussions; Victor Boctor
> Subject: Re: [mantisbt-dev] Staging 1.3 for release
> 
> Victor,
> 
> I mentioned some time before that I would like to see the branch _after_ 1.3.0 or even better 1.3.1 This is to avoid the additional work that is needed to implement fixes for two branches.
> It seems that you don't consider this approach.
> 
> Ok, at least we shouldn't branch before the fixes for let's say the second official beta version are implemented and at least the following issues [1] are fixed.
> 
> I fear that we will see quite soon some commits from Victor and Paul in master after the branch has been created that will complicate porting changes from 1.3 to 2.0.
> I fear also, that Victor and Paul will not invest that much time in fixing bugs in 1.3 and port them to 2.0.
> 
> From my 1.2.x experience:
> Some developers had certainly some pleasure to add new stuff to master / next /
> 2.0 whereas other developers had not that much pleasure to fix hundreds of bugs in 1.2.x and to port the fixes to master.
> To get a rough impression of what I mean, check "Assigned To" from [2]
> 
> dregad 264
> rombert 102
> atrol 45
> vboctor 31 (even less if you don't count the issues driven by MantisTouch) grangeway 5
> 
> I hope we will not see the same story for 1.3.
> 
> Concerning "Upgrade our bug tracker to 1.3 branch":
> 
> Did someone test that all plugins running on mantisbt.org/bugs are running fine with current master?
> Maybe some of them can/should be deactivated.
> At least "Source control integration" and "Snippets" should work.
> 
> Roland
> 
> [1]
> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0
> [2]
> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&fixed_in_version[]=1.2.x&fixed_in_version[]=1.2.17&fixed_in_version[]=1.2.16&fixed_in_version[]=1.2.15&fixed_in_version[]=1.2.14&fixed_in_version[]=1.2.13&fixed_in_version[]=1.2.12&fixed_in_version[]=1.2.11&fixed_in_version[]=1.2.10&fixed_in_version[]=1.2.9&fixed_in_version[]=1.2.8&fixed_in_version[]=1.2.7&fixed_in_version[]=1.2.6&fixed_in_version[]=1.2.5&fixed_in_version[]=1.2.4&fixed_in_version[]=1.2.3&fixed_in_version[]=1.2.2&fixed_in_version[]=1.2.1&sortby=handler_id&dir=DESC&hide_status_id=-2&match_type=0
> 
> 
>> Victor Boctor <vb...@gm...> hat am 19. September 2014 um 05:39
>> geschrieben:
>> 
>> 
>> Hi all,
>> 
>> It has become a habit to discuss this topic every couple of month.  
>> I'm seeing there is a lot of activity in terms of checkins, but I want 
>> us to make sure we are on a path to getting 1.3 out of the door.  We 
>> have always been a month or two away with desire to get some more stuff in.
>> 
>> At the moment, there is a lot of churn on master that can be 
>> classified as good change, but not really needed for 1.3 to go out.
>> 
>> I would like to suggest staging 1.3 as follows:
>> 
>> - Branch for 1.3
>> - Upgrade our bug tracker to 1.3 branch.
>> - Put this branch in bug fix only mode.
>> 
>> That would give us the following benefits:
>> 
>> - A better chance at stabilizing (based on blocking bugs) and releasing.
>> - Ability to release 1.3 beta/alpha and get more testing.
>> - Continue doing back porting of good changes, but are not critical to 
>> 1.3 release without destabilizing.
>> - Unblock 2.0 changes
>> 
>> Hope that makes sense.
>> 
>> Thanks,
>> -Victor
>> ----------------------------------------------------------------------
>> -------- Slashdot TV.  Video for Nerds.  Stuff that Matters.
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
>> clktrk_______________________________________________
>> mantisbt-dev mailing list
>> man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> 

[mantisbt-dev] PHP Unit Tests

[P R. <pa...@ma...>]

Hi all,

 

I'm planning on putting in several PR's next week that approve our php unit
testing coverage.

 

This will aid the future DB Layer move, as well as hopefully improve testing
coverage for bugs for the future 1.3 release.

 

However, before I do - I vaguely recall a few months ago that either Rombert
or Roland had a couple of new unit tests they were planning to add on a
mantis bug / PR somewhere? Is that still the case?

 

Paul

[mantisbt-dev] Build System

[P R. <pa...@ma...>]

Hi All,

 

I'd like to draw people's attention to
https://github.com/mantisbt/mantisbt/pull/332 - as it's start of work to
implement a common build system that both travis and mantis developers can
use. As we add unit tests allowing mantis developers to easily create a
build locally and also show up code style issues should hopefully lead to
less churn in the source code (and make supporting different releases of
mantis easier). 

 

I think the summary I put on the github PR hopefully covers most things so
far, so going to just paste it here rather than writing another wall of
text:

 

For a long while now, the build a developer can do,
and the build one can automate on travis-ci are too different things.

This is the start of a process to unify the build system, such that a
developer can run a local build before/without having to wait for
travis-ci or some other automation system to kick in.

The requirements for this to run at the moment is an installation of
either phing or composer.

Phing route:

Phing can be installed, if not already installed by running:

pear channel-discover pear.phing.info
pear install [--alldeps] phing/phing

going to the Mantis directory, and running phing then starts a build.

This build will download composer, download a standard version of
phpcodesniffer/phpunit, and it's own copy of phing and run a build based
on these versions. This ensures that local + travis etc versions are the
same

Composer Route:

php -r "readfile(' <https://getcomposer.org/installer');>
https://getcomposer.org/installer');" | php
composer install

A build can be run at this point by calling:

php vendor/bin/phing build

Note: at the moment, I've specified 'build' as a target here, as the
default option is to run a target called "buildsystem" at the moment,
which downloads all the dependencies

travis-ci.org build has been modified to include the process described
above so that a developers build and the build system build converge
towards being identical.

At the moment a 'build' consists of the following:

a) doing a quick lint check on PHP files for parse errors
b) Running some popular code metrics type utilities: phploc,pdepend
c) running phpcs with a custom ruleset which tries to follow mantis's rules
d) running phpunit tests
e) generating some api documentation
(atm, via phpdox, although should also generated via phpdoc2)
f) spit our a zip/tarball package of the build

Full build time is with codesniffer rules etc is around 2.5-3 minutes
locally

however, individual steps can be run:

For example:

phing phpcs will run codesniffer rules against code base.

phing phpunit will run php unit tests.

This is very much a first step - I suspect we will alter the tools,
add tools and commands etc, as we work out whats useful and what isn't.

For example, I've seen some phing build scripts that deal with creating
and merging between local branches/github PR's etc.

 

 

Re: [mantisbt-dev] Staging 1.3 for release

[P R. <pa...@ma...>]

Roland,

I think the initial with the 1.2 and historical fixes was that we didn't have plan post 1.2.

In terms of 1.3, I'd like to see us support this longer term, so I think it would be good to see us bug port more bug fixes.

I've not had much time so far in September to spend on Mantis Development, as I work in a school and the first few weeks are really busy. 

Now that the first few weeks are done, I should be able to dedicate more time towards mantis. At the moment, I'm going through existing patches that people offered to help get committed from next/master-2.x before we look at 1.3.

You'll probably see the pace of that development accelerate over the next month as I'll have some free time to work on Mantis, coupled with some free work time to throw in.

Hopefully we can get as much merged as possible to reduce both the work in keeping the patches sync'd up to the current master, and to avoid having what we've had before of doing a release and then having massive churn on master.

I will have pull requests for every patch against master-2 / next in github within the next 7-10 days.

This will allow us to delete the historical next/master-2.x branches.

I've then got 2-3 new features that I'd like to put forward in October, and plan to spend some time trying to stabilise master for a release at that point.

I suggested two weeks ago that we set a date of end of October for new development - when I said " to branch 1.3 for release" - I meant for an alpha release, and not for a final release.

In terms of 'when to branch' - we should branch master into 1.3 before the first alpha release. But equally, that should be done at the point everyone's had a chance to get any changes in before the branch. Whilst I know that I've not had much time to dedicate to Mantis for the last month, and I know I'm about to get a chunk of time to spend on mantis for the next month, others may have different schedules. The rational for saying we should set an "end of October" or even "end of November" date or similar timescale was to give everyone a chance to finalise any patches before we move to a period of stabilisation. 

Paul


-----Original Message-----
From: Roland Becker [mailto:ro...@at...] 
Sent: 19 September 2014 10:51
To: developer discussions; Victor Boctor
Subject: Re: [mantisbt-dev] Staging 1.3 for release

Victor,

I mentioned some time before that I would like to see the branch _after_ 1.3.0 or even better 1.3.1 This is to avoid the additional work that is needed to implement fixes for two branches.
It seems that you don't consider this approach.

Ok, at least we shouldn't branch before the fixes for let's say the second official beta version are implemented and at least the following issues [1] are fixed.

I fear that we will see quite soon some commits from Victor and Paul in master after the branch has been created that will complicate porting changes from 1.3 to 2.0.
I fear also, that Victor and Paul will not invest that much time in fixing bugs in 1.3 and port them to 2.0.

>From my 1.2.x experience:
Some developers had certainly some pleasure to add new stuff to master / next /
2.0 whereas other developers had not that much pleasure to fix hundreds of bugs in 1.2.x and to port the fixes to master.
To get a rough impression of what I mean, check "Assigned To" from [2]

dregad 264
rombert 102
atrol 45
vboctor 31 (even less if you don't count the issues driven by MantisTouch) grangeway 5

I hope we will not see the same story for 1.3.

Concerning "Upgrade our bug tracker to 1.3 branch":

Did someone test that all plugins running on mantisbt.org/bugs are running fine with current master?
Maybe some of them can/should be deactivated.
At least "Source control integration" and "Snippets" should work.

Roland

[1]
http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0
[2]
http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&fixed_in_version[]=1.2.x&fixed_in_version[]=1.2.17&fixed_in_version[]=1.2.16&fixed_in_version[]=1.2.15&fixed_in_version[]=1.2.14&fixed_in_version[]=1.2.13&fixed_in_version[]=1.2.12&fixed_in_version[]=1.2.11&fixed_in_version[]=1.2.10&fixed_in_version[]=1.2.9&fixed_in_version[]=1.2.8&fixed_in_version[]=1.2.7&fixed_in_version[]=1.2.6&fixed_in_version[]=1.2.5&fixed_in_version[]=1.2.4&fixed_in_version[]=1.2.3&fixed_in_version[]=1.2.2&fixed_in_version[]=1.2.1&sortby=handler_id&dir=DESC&hide_status_id=-2&match_type=0


> Victor Boctor <vb...@gm...> hat am 19. September 2014 um 05:39
> geschrieben:
>
>
> Hi all,
>
> It has become a habit to discuss this topic every couple of month.  
> I'm seeing there is a lot of activity in terms of checkins, but I want 
> us to make sure we are on a path to getting 1.3 out of the door.  We 
> have always been a month or two away with desire to get some more stuff in.
>
> At the moment, there is a lot of churn on master that can be 
> classified as good change, but not really needed for 1.3 to go out.
>
> I would like to suggest staging 1.3 as follows:
>
> - Branch for 1.3
> - Upgrade our bug tracker to 1.3 branch.
> - Put this branch in bug fix only mode.
>
> That would give us the following benefits:
>
> - A better chance at stabilizing (based on blocking bugs) and releasing.
> - Ability to release 1.3 beta/alpha and get more testing.
> - Continue doing back porting of good changes, but are not critical to 
> 1.3 release without destabilizing.
> - Unblock 2.0 changes
>
> Hope that makes sense.
>
> Thanks,
> -Victor
> ----------------------------------------------------------------------
> -------- Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
> clktrk_______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
man...@li...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Staging 1.3 for release

[Victor B. <vb...@gm...>]

@paul, I saw your message to the mailing list, but I'm thinking it is good
to discuss in a dedicated thread (this thread).  We have to weigh the
benefit of merging all existing patches in 1.3, vs. some in 1.3 and some in
2.0.

@atrol, I remember your preference. I'm mainly reacting to the fact that
just earlier this year, we had a goal of releasing 1.3 beta by end of
January (with several targets before then).  I think to get it out, we have
to have a bar of what can make it into 1.3.  We seem to be in a cycle of
adding stuff and then fixing bugs introduced by the added stuff, etc.  So
whether we branch or not, we need to have such bar (e.g. functional bug
fixes or bug fixes to blocking / security bugs, etc).

As for adding new features vs. fixing bugs.  We should start with the
person who added a feature handling its bugs.  That won't cover bugs that
requires investigation of the even the area causing the issue, but should
be a good starting point.

Given history I believe a timeline of 1.3 in October and 2.0 in January is
unrealistic (impossible).  I feel we really need to schedule some hard stop
in our timeline, otherwise, we will keep going for a very long time without
releases.

Given @atrol and @dregad's preference, I'm OK with not branching until the
first beta release is out (at least), but we need to agree on the bar.

- blocking bug fixes
- functional bug fixes
- security bugs

So for submitted pull requests, we are not going to just look into whether
the change is OK, but does it just cause churn and delay 1.3.  I would
suggest applying this policy to pull requests in flight and future ones.

Once @dregad gets the source control plugin working, then we can upgrade
our instance and move forward.


On Fri, Sep 19, 2014 at 7:48 AM, Damien Regad <dr...@ma...> wrote:

> Victor Boctor <vboctor@...> writes:
> > It has become a habit to discuss this topic every couple of month.
>
> Not sure if I should :-) or :-(...
>
> > At the moment, there is a lot of churn on master that can be classified
> > as good change, but not really needed for 1.3 to go out.
>
> Fully agreed.
>
> I'd also like to point out that we have several security issues pending a
> fix since May, but the assigned developer is currently focusing on
> seemingly
> more important activities at the moment :-P
>
> Furthermore, several of the recent changes are adding instability and even
> introduced regressions. As things stand, the current continuous stream of
> changes is only delaying a potential go-live.
>
> > I would like to suggest staging 1.3 as follows:
> >
> > - Branch for 1.3
>
> Roland's answer has pretty much covered my opinion on this already, and
> perfectly outlined the consequences of doing it.
>
> Therefore, and for the same reasons, I *strongly oppose early branching*.
>
> We MUST NOT branch before at least 1.3.0b1 is out (so we can reach some
> level of stability) and SHOULD NOT do it until 1.3.0.
>
> > - Upgrade our bug tracker to 1.3 branch.
>
> As mentioned by Roland, we need to ensure our plugins have no issues with
> that.
>
> Roland Becker <roland@...> writes:
> > Did someone test that all plugins running on mantisbt.org/bugs are
> > running fine
>
> I did actually. At the moment, the *source integration* does NOT work
> properly, effectively blocking a move to mantisbt.org for now. I have a
> local work-in-progress branch where I attempt to fix the issues but I'm not
> done yet.
>
> Furthermore, before we upgrade our tracker, I would like everyone in the
> team to actually spend some time to perform in-depth "pre-alpha" tests
> locally, including coverage of upgrade scenarios, and reporting results of
> the same.
>
> > - Put this branch in bug fix only mode.
>
> This is kind of out of the equation for now considering my position above,
> but +1 on principle.
>
> > That would give us the following benefits:
> >
> > - A better chance at stabilizing (based on blocking bugs) and releasing.
> > - Ability to release 1.3 beta/alpha and get more testing.
> > - Continue doing back porting of good changes, but are not critical to
> 1.3
> release without destabilizing.
> > - Unblock 2.0 changes
>
> +1 in theory... However as Roland pointed out, I think we unfortunately
> know
> from past experience what would likely happen in such a scenario. And quite
> frankly I'm not prepared to spend the same amount of effort as I did in the
> past to maintain 1.3.x <==> 2.0.x ports.
>
> Bottomline: I propose that we
>
> - (Paul) stop submitting 5-10 pull requests per day for now,
> - focus on testing and fixing issues and stabilization instead, then
> - get alpha out the door ASAP, and
> - resume the new features fest after 1.3.0a1 is out.
>
> Damien
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

Re: [mantisbt-dev] Staging 1.3 for release

[Damien R. <dr...@ma...>]

Victor Boctor <vboctor@...> writes:
> It has become a habit to discuss this topic every couple of month.

Not sure if I should :-) or :-(...

> At the moment, there is a lot of churn on master that can be classified 
> as good change, but not really needed for 1.3 to go out.

Fully agreed.

I'd also like to point out that we have several security issues pending a
fix since May, but the assigned developer is currently focusing on seemingly
more important activities at the moment :-P

Furthermore, several of the recent changes are adding instability and even
introduced regressions. As things stand, the current continuous stream of
changes is only delaying a potential go-live.

> I would like to suggest staging 1.3 as follows:
> 
> - Branch for 1.3

Roland's answer has pretty much covered my opinion on this already, and
perfectly outlined the consequences of doing it.

Therefore, and for the same reasons, I *strongly oppose early branching*. 

We MUST NOT branch before at least 1.3.0b1 is out (so we can reach some
level of stability) and SHOULD NOT do it until 1.3.0.

> - Upgrade our bug tracker to 1.3 branch.

As mentioned by Roland, we need to ensure our plugins have no issues with that.

Roland Becker <roland@...> writes:
> Did someone test that all plugins running on mantisbt.org/bugs are 
> running fine

I did actually. At the moment, the *source integration* does NOT work
properly, effectively blocking a move to mantisbt.org for now. I have a
local work-in-progress branch where I attempt to fix the issues but I'm not
done yet.

Furthermore, before we upgrade our tracker, I would like everyone in the
team to actually spend some time to perform in-depth "pre-alpha" tests
locally, including coverage of upgrade scenarios, and reporting results of
the same. 

> - Put this branch in bug fix only mode.

This is kind of out of the equation for now considering my position above,
but +1 on principle.

> That would give us the following benefits:
> 
> - A better chance at stabilizing (based on blocking bugs) and releasing.
> - Ability to release 1.3 beta/alpha and get more testing.
> - Continue doing back porting of good changes, but are not critical to 1.3
release without destabilizing.
> - Unblock 2.0 changes

+1 in theory... However as Roland pointed out, I think we unfortunately know
from past experience what would likely happen in such a scenario. And quite
frankly I'm not prepared to spend the same amount of effort as I did in the
past to maintain 1.3.x <==> 2.0.x ports.

Bottomline: I propose that we

- (Paul) stop submitting 5-10 pull requests per day for now,
- focus on testing and fixing issues and stabilization instead, then
- get alpha out the door ASAP, and 
- resume the new features fest after 1.3.0a1 is out. 

Damien

Re: [mantisbt-dev] Release of agileMantis plugin version 2.0

[Damien R. <dr...@ma...>]

Hi Jean,

Thanks for taking my remarks into consideration and for updating your plugin
accordingly.

I have created a team for you to manage the plugin within the
mantibt-plugins organization, I suggest you transfer ownership from the
jako87 repository to it now.

Further details and other things you might want to do can be found at 
http://www.mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins

Damien

[mantisbt-dev] Release of agileMantis plugin version 2.0

[Schmitz, J. <J.S...@ga...>]

Hello Damien,

in July we said, that we will fix issues that made our agileMantis plugin not comply with the MantisBT plugin standards.
We invested many days of refactoring into the new version.

In version 2.0 we made the following refactorings:

- All SQL statements now make use of the MantisBT/ADB DB-API
- Schema creation is now done using the schema() callback.
- MantisBT API functions will be used where possible
- Many lines of code have been reworked to comply to the MantisBT coding guidelines
- No changes to the MantisBT config_inc.php are necessary anymore.

agileMantis is a powerful tool for agile development. Since start of development in 2012, a lot of days where spend on design, programming and quality assurance.
We use agileMantis for our own agile product development, since the first stable release.
We think, that we can open up the way into agile development for interested users, without to relinquish from the MantisBT base software.

Now, we would like to ask you again to add our plugin to the MantisBT plugin directory.

The new version can be downloaded at Source Forge:
https://sourceforge.net/projects/agilemantis/files/agileMantis%202.0.0/


Best regards.

Jean Schmitz
Managing Software Engineer
________________________________
gadiv GmbH
Bövingen 148
53804 Much
Germany
Tel.:

+49 (0)2245 / 9160-34

Fax:

+49 (0)2245 / 9160-21

E-Mail:

j.s...@ga...<mailto:j.s...@ga...>

Web:

www.gadiv.de<http://www.gadiv.de/>


Vertreten durch die Geschäftsführer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
________________________________

Re: [mantisbt-dev] Staging 1.3 for release

[Roland B. <ro...@at...>]

Wrong link for [1]
Should have been
http://www.mantisbt.org/bugs/search.php?project_id=1&status_id[]=10&status_id[]=20&status_id[]=30&status_id[]=40&status_id[]=50&severity_id[]=60&severity_id[]=70&severity_id[]=80&sticky_issues=on&target_version=1.3.x&sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0

> Roland Becker <ro...@at...> hat am 19. September 2014 um 11:50
> geschrieben:
>
>
> Victor,
>
> I mentioned some time before that I would like to see the branch _after_ 1.3.0
> or even better 1.3.1
> This is to avoid the additional work that is needed to implement fixes for two
> branches.
> It seems that you don't consider this approach.
>
> Ok, at least we shouldn't branch before the fixes for let's say the second
> official beta version are implemented and at least the following issues [1]
> are
> fixed.
>
> I fear that we will see quite soon some commits from Victor and Paul in master
> after the branch has been created that will complicate porting changes from
> 1.3
> to 2.0.
> I fear also, that Victor and Paul will not invest that much time in fixing
> bugs
> in 1.3 and port them to 2.0.
>
> From my 1.2.x experience:
> Some developers had certainly some pleasure to add new stuff to master / next
> /
> 2.0 whereas other developers had not that much pleasure to fix hundreds of
> bugs
> in 1.2.x and to port the fixes to master.
> To get a rough impression of what I mean, check "Assigned To" from [2]
>
> dregad 264
> rombert 102
> atrol 45
> vboctor 31 (even less if you don't count the issues driven by MantisTouch)
> grangeway 5
>
> I hope we will not see the same story for 1.3.
>
> Concerning "Upgrade our bug tracker to 1.3 branch":
>
> Did someone test that all plugins running on mantisbt.org/bugs are running
> fine
> with current master?
> Maybe some of them can/should be deactivated.
> At least "Source control integration" and "Snippets" should work.
>
> Roland
>
> [1]
> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0
> [2]
> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&fixed_in_version[]=1.2.x&fixed_in_version[]=1.2.17&fixed_in_version[]=1.2.16&fixed_in_version[]=1.2.15&fixed_in_version[]=1.2.14&fixed_in_version[]=1.2.13&fixed_in_version[]=1.2.12&fixed_in_version[]=1.2.11&fixed_in_version[]=1.2.10&fixed_in_version[]=1.2.9&fixed_in_version[]=1.2.8&fixed_in_version[]=1.2.7&fixed_in_version[]=1.2.6&fixed_in_version[]=1.2.5&fixed_in_version[]=1.2.4&fixed_in_version[]=1.2.3&fixed_in_version[]=1.2.2&fixed_in_version[]=1.2.1&sortby=handler_id&dir=DESC&hide_status_id=-2&match_type=0
>
>
> > Victor Boctor <vb...@gm...> hat am 19. September 2014 um 05:39
> > geschrieben:
> >
> >
> > Hi all,
> >
> > It has become a habit to discuss this topic every couple of month.  I'm
> > seeing there is a lot of activity in terms of checkins, but I want us to
> > make sure we are on a path to getting 1.3 out of the door.  We have always
> > been a month or two away with desire to get some more stuff in.
> >
> > At the moment, there is a lot of churn on master that can be classified as
> > good change, but not really needed for 1.3 to go out.
> >
> > I would like to suggest staging 1.3 as follows:
> >
> > - Branch for 1.3
> > - Upgrade our bug tracker to 1.3 branch.
> > - Put this branch in bug fix only mode.
> >
> > That would give us the following benefits:
> >
> > - A better chance at stabilizing (based on blocking bugs) and releasing.
> > - Ability to release 1.3 beta/alpha and get more testing.
> > - Continue doing back porting of good changes, but are not critical to 1.3
> > release without destabilizing.
> > - Unblock 2.0 changes
> >
> > Hope that makes sense.
> >
> > Thanks,
> > -Victor
> > ------------------------------------------------------------------------------
> > Slashdot TV.  Video for Nerds.  Stuff that Matters.
> > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk_______________________________________________
> > mantisbt-dev mailing list
> > man...@li...
> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Staging 1.3 for release

[Roland B. <ro...@at...>]

Victor,

I mentioned some time before that I would like to see the branch _after_ 1.3.0
or even better 1.3.1
This is to avoid the additional work that is needed to implement fixes for two
branches.
It seems that you don't consider this approach.

Ok, at least we shouldn't branch before the fixes for let's say the second
official beta version are implemented and at least the following issues [1] are
fixed.

I fear that we will see quite soon some commits from Victor and Paul in master
after the branch has been created that will complicate porting changes from 1.3
to 2.0.
I fear also, that Victor and Paul will not invest that much time in fixing bugs
in 1.3 and port them to 2.0.

>From my 1.2.x experience:
Some developers had certainly some pleasure to add new stuff to master / next /
2.0 whereas other developers had not that much pleasure to fix hundreds of bugs
in 1.2.x and to port the fixes to master.
To get a rough impression of what I mean, check "Assigned To" from [2]

dregad 264
rombert 102
atrol 45
vboctor 31 (even less if you don't count the issues driven by MantisTouch)
grangeway 5

I hope we will not see the same story for 1.3.

Concerning "Upgrade our bug tracker to 1.3 branch":

Did someone test that all plugins running on mantisbt.org/bugs are running fine
with current master?
Maybe some of them can/should be deactivated.
At least "Source control integration" and "Snippets" should work.

Roland

[1]
http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0
[2]
http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off&fixed_in_version[]=1.2.x&fixed_in_version[]=1.2.17&fixed_in_version[]=1.2.16&fixed_in_version[]=1.2.15&fixed_in_version[]=1.2.14&fixed_in_version[]=1.2.13&fixed_in_version[]=1.2.12&fixed_in_version[]=1.2.11&fixed_in_version[]=1.2.10&fixed_in_version[]=1.2.9&fixed_in_version[]=1.2.8&fixed_in_version[]=1.2.7&fixed_in_version[]=1.2.6&fixed_in_version[]=1.2.5&fixed_in_version[]=1.2.4&fixed_in_version[]=1.2.3&fixed_in_version[]=1.2.2&fixed_in_version[]=1.2.1&sortby=handler_id&dir=DESC&hide_status_id=-2&match_type=0


> Victor Boctor <vb...@gm...> hat am 19. September 2014 um 05:39
> geschrieben:
>
>
> Hi all,
>
> It has become a habit to discuss this topic every couple of month.  I'm
> seeing there is a lot of activity in terms of checkins, but I want us to
> make sure we are on a path to getting 1.3 out of the door.  We have always
> been a month or two away with desire to get some more stuff in.
>
> At the moment, there is a lot of churn on master that can be classified as
> good change, but not really needed for 1.3 to go out.
>
> I would like to suggest staging 1.3 as follows:
>
> - Branch for 1.3
> - Upgrade our bug tracker to 1.3 branch.
> - Put this branch in bug fix only mode.
>
> That would give us the following benefits:
>
> - A better chance at stabilizing (based on blocking bugs) and releasing.
> - Ability to release 1.3 beta/alpha and get more testing.
> - Continue doing back porting of good changes, but are not critical to 1.3
> release without destabilizing.
> - Unblock 2.0 changes
>
> Hope that makes sense.
>
> Thanks,
> -Victor
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk_______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Staging 1.3 for release

[Paul R. <pa...@ma...>]

My suggestion on this 2 weeks ago that was sent to the mailing list was:

"I’d like to see us pick a date to branch 1.3 for release, say 31st October
2014 (to give a chance to get all patches that already exist for 1.3
merged), and then say 1st January 2015 for 2.0."



On Fri, Sep 19, 2014 at 4:39 AM, Victor Boctor <vb...@gm...> wrote:

> Hi all,
>
> It has become a habit to discuss this topic every couple of month.  I'm
> seeing there is a lot of activity in terms of checkins, but I want us to
> make sure we are on a path to getting 1.3 out of the door.  We have always
> been a month or two away with desire to get some more stuff in.
>
> At the moment, there is a lot of churn on master that can be classified as
> good change, but not really needed for 1.3 to go out.
>
> I would like to suggest staging 1.3 as follows:
>
> - Branch for 1.3
> - Upgrade our bug tracker to 1.3 branch.
> - Put this branch in bug fix only mode.
>
> That would give us the following benefits:
>
> - A better chance at stabilizing (based on blocking bugs) and releasing.
> - Ability to release 1.3 beta/alpha and get more testing.
> - Continue doing back porting of good changes, but are not critical to 1.3
> release without destabilizing.
> - Unblock 2.0 changes
>
> Hope that makes sense.
>
> Thanks,
> -Victor
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>

[mantisbt-dev] Staging 1.3 for release

[Victor B. <vb...@gm...>]

Hi all,

It has become a habit to discuss this topic every couple of month.  I'm
seeing there is a lot of activity in terms of checkins, but I want us to
make sure we are on a path to getting 1.3 out of the door.  We have always
been a month or two away with desire to get some more stuff in.

At the moment, there is a lot of churn on master that can be classified as
good change, but not really needed for 1.3 to go out.

I would like to suggest staging 1.3 as follows:

- Branch for 1.3
- Upgrade our bug tracker to 1.3 branch.
- Put this branch in bug fix only mode.

That would give us the following benefits:

- A better chance at stabilizing (based on blocking bugs) and releasing.
- Ability to release 1.3 beta/alpha and get more testing.
- Continue doing back porting of good changes, but are not critical to 1.3
release without destabilizing.
- Unblock 2.0 changes

Hope that makes sense.

Thanks,
-Victor

Re: [mantisbt-dev] Send Plugin

[Damien R. <dr...@ma...>]

You will also want to provide English text (in chosen.js), and add support
for translations. See Snippets plugin for an example

https://github.com/mantisbt-plugins/snippets/

Re: [mantisbt-dev] Send Plugin

[Kiver V. <kiv...@gm...>]

Hello Thank you, I have not received the notification will README soon.

As for the name change, I sought more still have not found how to change
the name of the repository, when changes are ready I will notify you.

Thanks for everything so far, and the incredible tool bugtracker.

2014-09-09 10:38 GMT-04:00 Damien Regad <dr...@ma...>:

> Kiver Vinicius <kivervinicius@...> writes:
> > The correct link is
> >
> > https://github.com/kivervinicius/MantisChosen
>
> I have created a team for you in mantisbt-plugins organization and sent you
> an invitation. Please follow instructions in
>
> http://mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins
>
> to transfer ownership of the repository to the org, and let me know when
> you're done.
>
> I invite you to *rename* it to *jQueryChosen* or something similar (it does
> not make sense to have plugins start with 'Mantis')
>
> I also recommend to add a README file (in English) and to reference your
> plugin in the above-mentioned wiki page.
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

Re: [mantisbt-dev] Send Plugin

[Damien R. <dr...@ma...>]

Kiver Vinicius <kivervinicius@...> writes:
> The correct link is 
> 
> https://github.com/kivervinicius/MantisChosen

I have created a team for you in mantisbt-plugins organization and sent you
an invitation. Please follow instructions in 

http://mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins

to transfer ownership of the repository to the org, and let me know when
you're done.

I invite you to *rename* it to *jQueryChosen* or something similar (it does
not make sense to have plugins start with 'Mantis')

I also recommend to add a README file (in English) and to reference your
plugin in the above-mentioned wiki page.

Re: [mantisbt-dev] Send Plugin

[Kiver V. <kiv...@gm...>]

Sorry again, damn ctrl + C and ctrl + v. rs.

The correct link is

https://github.com/kivervinicius/MantisChosen

2014-09-09 9:57 GMT-04:00 Damien Regad <dr...@ma...>:

> Kiver Vinicius <kivervinicius@...> writes:
>
> > Sorry, my English is very weak, and am new to mailing lists, I developed
> > a plugin for mantis and would put it on their list of plugins
>
> No problem. This is what I thought you meant, but as your original post did
> not contain any information I had to ask.
>
> > My plugin is hosted on github
> >
> > https://github.com/mantisbt-plugins
>
> Erm... this is the link to our plugins organization, i.e. where you want to
> put your plugin - what we need is the link to where your plugins' source
> code is.
>
> Please confirm that's the one:
> https://github.com/kivervinicius/MantisChosen
>
> More information on the plugin registration process can be found at
> http://mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins
>
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

Re: [mantisbt-dev] Send Plugin

[Damien R. <dr...@ma...>]

Kiver Vinicius <kivervinicius@...> writes:

> Sorry, my English is very weak, and am new to mailing lists, I developed 
> a plugin for mantis and would put it on their list of plugins

No problem. This is what I thought you meant, but as your original post did
not contain any information I had to ask.

> My plugin is hosted on github 
> 
> https://github.com/mantisbt-plugins 

Erm... this is the link to our plugins organization, i.e. where you want to
put your plugin - what we need is the link to where your plugins' source
code is.

Please confirm that's the one:
https://github.com/kivervinicius/MantisChosen

More information on the plugin registration process can be found at
http://mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins

Re: [mantisbt-dev] Send Plugin

[Kiver V. <kiv...@gm...>]

Sorry, my English is very weak, and am new to mailing lists, I developed a
plugin for mantis and would put it on their list of plugins

https://github.com/mantisbt-plugins

My plugin is hosted on github

https://github.com/mantisbt-plugins

This plugin uses a jQuery library called Chosen and I developed a plugin
for mantis this work for us.

Att. Kiver

2014-09-09 6:08 GMT-04:00 Damien Regad <dr...@ma...>:

> Kiver Vinicius <kivervinicius@...> writes:
> > https://github.com/mantisbt-plugins
>
> And your question / point is ?
>
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

Re: [mantisbt-dev] Updating code in install functions

[Damien R. <dr...@ma...>]

P Richards <paul@...> writes:
> Sourceforge mailing lists seem to be playing up again and missing emails.

Seems to be just you - I'm getting all messages without any issues.

Anyway, thanks for the detailed response and explanation. I will test the
updated code to ensure it resolves the regression issue, and properly
upgrades my test DBs.

> From version 4 of filters, we 'upgrade' filters in the background when
> requested, so it's not necessary to upgrade them in the database.

Wouldn't it be worth providing some tools to assist admins in
checking/upgrading obsolete filters in their systems in one go, i.e.

- admin check
- external script / admin tool to run manually

Or do you reckon it's sufficient to let the automatic background update do
the job ?

I am not sure that process actually saves the converted/upgraded filters
back to the source (DB / Cookie). If not, then we definitely need to provide
a conversion process.

Re: [mantisbt-dev] Send Plugin

[Damien R. <dr...@ma...>]

Kiver Vinicius <kivervinicius@...> writes:
> https://github.com/mantisbt-plugins

And your question / point is ?

Re: [mantisbt-dev] Updating code in install functions

[P R. <pa...@ma...>]

Sourceforge mailing lists seem to be playing up again and missing emails.

I've not yet had the mail avetis or the mail I sent regarding filters - but
I've had your reply to avetis' mail ;/

Anyway, PR293 is fix for schema update process to ensure that we don't rely
on filter api. We still need to do some tidy up in Mantis to deal with the
fact that the previous filter upgrade was incorrect - but the filter code
upgrades the filters, so that's actually dealt with anyway.

In short, we have 2 filter changes - a) orginal filter thing that renamed
fields and set filters to latest version b) json "container" changes

I attempted to change/fix with the json container changes what's actually a
bug in the original filter changes:

The original filter changes "upgraded" the filters from v4 to v5 and renamed
the fields required between those two steps, and once it had done, set the
filter to the value of the filter version. The second part of this behaviour
is incorrect - we are now on version 8 (or 9). Therefore, filters that were
version 4/5, and were upgraded straight to the previous version 8, will not
receive the 'upgrade steps' to filters for version 6 or 7 until we next make
a filter change. This is incorrect behaviour.

Separately to that, the code for upgrading the filters was placed in the DB
upgrade step - as we use filter_ensure_valid to do filter version update
(e.g. from 6 to 7), upgrade filters stored in tokens, cookies, URL etc.
filter_ensure_valid needs to contain the filter upgrade steps in the db
layer to ensure that filters stored in cookies etc are also correctly
upgraded (as I believe query_store.php stores the value of a cookie filter
back to the db when saving current filter into the database).

>From version 4 of filters, we 'upgrade' filters in the background when
requested, so it's not necessary to upgrade them in the database.

When implementing the json container changes, I attempted to fix the above
by calling filter_ensure_valid - this was obviously a mistake as it leaves
you in a state where you are relying on the latest code and a partially
upgraded database. Hence my first thought, of making the filter changes a
single upgrade step (and the previous patch/commits). Whilst that's OK, and
fixes the issue for now, it leaves the same problem - as soon as we do a
database upgrade step, we need to evaluate whether it might break
filter_ensure_valid.

It also leaves a second possible issue that when filter_ensure_valid relies
on user configuration settings for example config_get( 'show_sticky_issues'
) - so filter_ensure_valid should be called by the end user to ensure their
personal/project settings are included correctly.

Having concluded the above, the best thing to do in schema/install.php is
not to try and upgrade the filter in some way - but to let our existing
mechanisms handle the version upgrade. That leaves the remaining question of
whether it would be feasible to store an upgrade filter back into the
database - at the moment the filter api doesn't lend itself easily to doing
that. Something that also isn't helped by the fact we don't always use our
own API within the code for viewing filters.

Paul


-----Original Message-----
From: Damien Regad [mailto:dr...@ma...] 
Sent: 08 September 2014 09:33
To: Man...@li...
Subject: Re: [mantisbt-dev] Updating code in install functions

P Richards <paul@...> writes:
>
> Give me 2 hours to pop to work and go for a swim and I'll send a PR 
> with a different approach - as even my 'new' approach is incorrect, 
> and this email hadn't arrived last night.

I assume that https://github.com/mantisbt/mantisbt/pull/293 is your response
to this discussion ?




----------------------------------------------------------------------------
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce Perforce version control.
Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
man...@li...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

[mantisbt-dev] Send Plugin

[Kiver V. <kiv...@gm...>]

https://github.com/mantisbt-plugins

Re: [mantisbt-dev] Updating code in install functions

[Damien R. <dr...@ma...>]

P Richards <paul@...> writes:
>
> Give me 2 hours to pop to work and go for a swim and I'll send a PR with a
> different approach - as even my 'new' approach is incorrect, and this 
> email hadn't arrived last night.

I assume that https://github.com/mantisbt/mantisbt/pull/293 is your response
to this discussion ?

Re: [mantisbt-dev] Mysql Engine(s)

[Damien R. <dr...@ma...>]

Avetis Avagyan <avetis.avagyan@...> writes:

> I still think that going with 'local' defaults is a good option. [...]
> I don't see much benefits in forcing storage engine 
> in attempt to 'override' defaults of 'local'.

+1

Re: [mantisbt-dev] Mysql Engine(s)

[Avetis A. <ave...@ya...>]

Hi Paul,

Back to your question - I think that there is good number of people using MyISAM, but I don't have market share stats to support this statement. I quickly googled on the subject, but in vain.

I still think that going with 'local' defaults is a good option. It will be either defaults coming from MySQL (different depending on version) or defaults set by DBA. I don't see much benefits in forcing storage engine in attempt to 'override' defaults of 'local'.

Best,
Avetis




>________________________________
> From: P Richards <pa...@ma...>
>To: 'developer discussions' <man...@li...> 
>Sent: Thursday, September 4, 2014 11:35 PM
>Subject: Re: [mantisbt-dev] Mysql Engine(s)
> 
>
>
> 
>“Is it a requirement to force for any particular storage engine? Can't we simply leave this to the defaults of server where DB will run? One likes more InnoDB, another one MyISAM, and someone else something else - for number of good reasons. Thanks, Avetis“
> 
>Currently we force myisam (this is probably incorrect behaviour). Especially given mysql 5.5 changes the default engines from myisam to innodb
> 
>Mariadb/percona etc implement different storage engines, which we may want to allow.
> 
>However, given myisam doesn’t support transactions and similar things – maybe a better question is “should we move away from myisam” as opposed to “should we use innodb”.
> 
>Avetis: from your point of view, do you think there’s people that would definitely want myisam? My understanding is that mysql themselves have stepped away from myisam a bit, and that it’s easier to get into a mess with corrupt tables on that engine.
> 
>From:Paul Richards [mailto:gra...@bl...] 
>Sent: 03 September 2014 22:54
>To: 'developer discussions'
>Subject: [mantisbt-dev] Mysql Engine(s)
> 
>This is following up from a previous mailing list discussion [see below (A)] regarding changing to innodb.
> 
>I've submitted a PR to convert tables to innodb as a DB step. Note: I've *not* included any change at the moment to not install with innodb in the first place (although that would be obvious step)
> 
>Rationale for looking at this is:
>a) I believe innodb is deemed to be more reliable for error recovery
>b) gap between myisam/innodb for performance has closed
>c) mysql seem to have moved to innodb by default rather than myisam
> 
>Test database for this has ~12,000 bugs, ~150,000 bug history records and ~20,000 users
> 
>Accessing Summary Page [5 concurrent users]
> 
>MYISAM INNODB 
> 
>~18.9 requests / min
> 
>46.7KB/sec throughput  
>~51.5 requests/min
> 
>132KB/s throughput 
> 
>Obviously, need to do some more performance benchmarking then just one page, and test against different load types – I don’t think I was expecting innodb to appear on the surface to respond twice as fast, so I’ve put an early version of innodb conversion script up in the hope someone else might do some performance testing…
> 
>Link to github PR so we can have a discussion on conversion process is at https://github.com/mantisbt/mantisbt/pull/290. I’ll close this pull request 6th September @ 9am UTC and create a final patch that deals with db installation etc for review, depending on results of performance testing.
> 
>Paul
> 
> 
> 
> 
>Previous Discussion A:
> 
>>> One thing I've come to realise this week whilst looking at DB bits - 
>>> we currently force myisam as table format.  Mysql changed default from 
>>> myisam to innodb  in 5.5
>>>  
>>> In fact, I just browsed the release notes for the development 5.7 
>>> mysql version, and myisam is barely mentioned. (one of only references 
>>> I could find was "The MySQL test suite mysql-test-run.sh program now 
>>> starts the server with InnoDB rather than MyISAM as the default 
>>> storage engine.")
>>>  
>>> At the moment, we force the table format to myisam, should we be dropping this, and letting mysql pick [which probably makes the default innodb], or changing to innodb ?
>> 
>> I would say that InnoDB is definitely preferable, so let's make it the default.
>> 
>> The danger with leaving this empty is that we get inconsistent results on different installations, depending on what the user's defaults are
>> -> support nightmare.
>------------------------------------------------------------------------------
>Slashdot TV.  
>Video for Nerds.  Stuff that matters.
>http://tv.slashdot.org/
>_______________________________________________
>mantisbt-dev mailing list
>man...@li...
>https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
>