From: Damien R. <dam...@me...> - 2011-10-25 17:30:29
|
Hi all, While working on the oracle branch, I stumbled upon what I think is a bug in ADOdb [1]. I have submitted a bug report upstream on the ADOdb forums (no feedback so far). Moving forward as this is blocking for getting oracle to work, I wanted to know if it is OK on principle to commit Mantis-specific changes to the ADOdb library. Thanks in advance for your reply. Damien [1] http://www.mantisbt.org/bugs/view.php?id=13438 |
From: Victor B. <vi...@fu...> - 2011-10-25 17:41:15
|
I think for 3rd party libraries we should report upstream. If the bug is important and needs to be addressed sooner than the likelihood of getting the upstream fix, then I believe we should fix it in our codebase. However, we should make sure that we can discover these fixes and re-apply the appropriate ones when we apply a new version of the library (in this case ADODB). My suggestion is to consider doing that through git sub-modules. In such case, we will do the following: 1. Fork the ADODB git repository if available, otherwise, create one on github. 2. Apply our fixes there on a branch (e.g. mantisbt-1.2.x, mantisbt-1.1x, etc). 3. Link our ADODB repository into our mantisbt repository. This will allow us to get the flexibility we need, be able to easily enumerate our changes, have different changes per major branch, and will also allow other teams to potentially use our version of ADODB if that makes sense to them. It will also allow us to easily send pull-requests for those who support it. Just my 2c. On Tue, Oct 25, 2011 at 10:26 AM, Damien Regad <dam...@me...>wrote: > Hi all, > > While working on the oracle branch, I stumbled upon what I think is a > bug in ADOdb [1]. I have submitted a bug report upstream on the ADOdb > forums (no feedback so far). > > Moving forward as this is blocking for getting oracle to work, I wanted > to know if it is OK on principle to commit Mantis-specific changes to > the ADOdb library. > > Thanks in advance for your reply. > Damien > > > [1] http://www.mantisbt.org/bugs/view.php?id=13438 > > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: David H. <d...@hx...> - 2011-10-26 06:54:17
Attachments:
signature.asc
|
On Tue, 2011-10-25 at 19:26 +0200, Damien Regad wrote: > While working on the oracle branch, I stumbled upon what I think is a > bug in ADOdb [1]. I have submitted a bug report upstream on the ADOdb > forums (no feedback so far). The project is pretty much dead. It's been superseded by a newer form of parametrised queries used by PDO and abstracted query rewriting as per Doctrine DBAL or other OO libraries. This is what Paul has been working on in the past 6 months (I have assisted a little bit as well). Our branches are on Github if you're interested in seeing progress so far (there is a lot more work still to complete). I wouldn't expect a new release of ADOdb any time soon. It's legacy software and doesn't get used as much as it used to. > Moving forward as this is blocking for getting oracle to work, I wanted > to know if it is OK on principle to commit Mantis-specific changes to > the ADOdb library. The problem arises with distro packaging of MantisBT where bundled libraries such as ADOdb, PHPMailer, etc are removed from the MantisBT package and replaced with separate system-wide packages. This is the correct thing to do and it should be our aim to assist distros by continually trying to remove bundled libraries. In these cases (which impact a large number of MantisBT users), patches applied to the bundled libraries probably won't be seen by users. I've also been trying to avoid branching our bundled libraries from upstream because it makes it very difficult to know which patches need reapplying when it comes time to updating the bundled libraries to match new upstream releases. At one point I think I was also committing the patches as well, just to make the update process easier. David |
From: Damien R. <dam...@me...> - 2011-10-26 09:36:53
|
On 26/10/11 08:45, David Hicks wrote: > I wouldn't expect a new release of ADOdb any time soon. It's legacy > software and doesn't get used as much as it used to. I think that horse is not dead yet... According to the sourceforge download page [1] a new version 5.14 was released on Sept 8th, and that's the 4th release since the version we have bundled with Mantis (5.10, dated Nov 2009) > The problem arises with distro packaging of MantisBT where bundled > libraries such as ADOdb, PHPMailer, etc are removed from the MantisBT > package and replaced with separate system-wide packages. This is the > correct thing to do and it should be our aim to assist distros by > continually trying to remove bundled libraries. [...] > trying to avoid branching our bundled libraries from upstream > because it makes it very difficult to know which patches need reapplying > when it comes time to updating the bundled libraries to match new > upstream releases. At one point I think I was also committing the > patches as well, just to make the update process easier. I don't think we comply with this today. According to ./library/adodb/readme_mantis.txt, there have already been some changes made to the library. This is confirmed by comparing downloaded 5.10 library from sourceforge with 1.2.x HEAD: $ diff -qrwB adodb5.10 ~/dev/mantisbt/library/adodb |grep -v ^Only Files adodb5.10/adodb-datadict.inc.php and ../dev/mantisbt/library/adodb/adodb-datadict.inc.php differ Files adodb5.10/adodb.inc.php and ../dev/mantisbt/library/adodb/adodb.inc.php differ Files adodb5.10/datadict/datadict-mssql.inc.php and ../dev/mantisbt/library/adodb/datadict/datadict-mssql.inc.php differ Files adodb5.10/datadict/datadict-mssqlnative.inc.php and ../dev/mantisbt/library/adodb/datadict/datadict-mssqlnative.inc.php differ Files adodb5.10/datadict/datadict-postgres.inc.php and ../dev/mantisbt/library/adodb/datadict/datadict-postgres.inc.php differ Files adodb5.10/drivers/adodb-db2.inc.php and ../dev/mantisbt/library/adodb/drivers/adodb-db2.inc.php differ Files adodb5.10/drivers/adodb-mysqli.inc.php and ../dev/mantisbt/library/adodb/drivers/adodb-mysqli.inc.php differ Files adodb5.10/drivers/adodb-odbc.inc.php and ../dev/mantisbt/library/adodb/drivers/adodb-odbc.inc.php differ Files adodb5.10/drivers/adodb-odbc_mssql.inc.php and ../dev/mantisbt/library/adodb/drivers/adodb-odbc_mssql.inc.php differ Files adodb5.10/drivers/adodb-pdo.inc.php and ../dev/mantisbt/library/adodb/drivers/adodb-pdo.inc.php differ Files adodb5.10/drivers/adodb-postgres64.inc.php and ../dev/mantisbt/library/adodb/drivers/adodb-postgres64.inc.php differ Files adodb5.10/drivers/adodb-sapdb.inc.php and ../dev/mantisbt/library/adodb/drivers/adodb-sapdb.inc.php differ I haven't looked into full detail for all these differences, but I'm quite sure that if distros use a "vanilla" version of ADOdb Mantis will break considering the amount of changes made (added function params, lots of added code for DB-specific drivers...) So if patching a bundled lib is not possible, is there anything else other than reporting upstream (which is already done), that I can do to resolve the issue ? Victor's idea of using git submodules for traceability sounds good as it would offer traceability, but - I did not find an "official" source repository of ADOdb (the CVS on sourceforge is completely out-of-date), there is a slightly outdated one on github [2] but it seems specific to the owner's project - Is it worth the effort of building this, considering the intent of moving away from ADOdb, as mentioned by David ? If we are not likely to upgrade to a later version of ADOdb, then I would say no. Bottomline is, based on the fact that ADOdb library is already customized, I am not sure one more change would be a huge issue, keeping in mind that without this fix, it will not be possible to implement support for oracle as the generation of schema upgrade SQL script fails. Let me know your thoughts. Damien [1] http://sourceforge.net/projects/adodb/files/adodb-php5-only/ [2] https://github.com/bitweaver/adodb |
From: Paul R. <pa...@ma...> - 2011-10-26 14:40:54
|
Actually, 1. David stripped out the customised version we used to run from our git repo, so we should be the same as some upstream version. Note: adodb used to be inconsistent with their line feeds, so I wouldn't be surprised if you've just got whitespace diff's 2. There is not a public svn/cvs of adodb that i'm aware of - I'm not even sure that the author has one internally given some of the releases i've seen pushed out before. 3. Whilst it makes sense to **bugfix** the current release - our focus should be on features in the next release. I'm not sure whether to class the fact that our oracle support is broken [and always has been] as a "bug", or a new feature for the next release :) Paul On Wed, Oct 26, 2011 at 10:32 AM, Damien Regad <dam...@me...>wrote: > On 26/10/11 08:45, David Hicks wrote: > > I wouldn't expect a new release of ADOdb any time soon. It's legacy > > software and doesn't get used as much as it used to. > > I think that horse is not dead yet... > > According to the sourceforge download page [1] a new version 5.14 was > released on Sept 8th, and that's the 4th release since the version we > have bundled with Mantis (5.10, dated Nov 2009) > > > > The problem arises with distro packaging of MantisBT where bundled > > libraries such as ADOdb, PHPMailer, etc are removed from the MantisBT > > package and replaced with separate system-wide packages. This is the > > correct thing to do and it should be our aim to assist distros by > > continually trying to remove bundled libraries. > [...] > > trying to avoid branching our bundled libraries from upstream > > because it makes it very difficult to know which patches need reapplying > > when it comes time to updating the bundled libraries to match new > > upstream releases. At one point I think I was also committing the > > patches as well, just to make the update process easier. > > I don't think we comply with this today. According to > ./library/adodb/readme_mantis.txt, there have already been some changes > made to the library. This is confirmed by comparing downloaded 5.10 > library from sourceforge with 1.2.x HEAD: > > $ diff -qrwB adodb5.10 ~/dev/mantisbt/library/adodb |grep -v ^Only > Files adodb5.10/adodb-datadict.inc.php and > ../dev/mantisbt/library/adodb/adodb-datadict.inc.php differ > Files adodb5.10/adodb.inc.php and > ../dev/mantisbt/library/adodb/adodb.inc.php differ > Files adodb5.10/datadict/datadict-mssql.inc.php and > ../dev/mantisbt/library/adodb/datadict/datadict-mssql.inc.php differ > Files adodb5.10/datadict/datadict-mssqlnative.inc.php and > ../dev/mantisbt/library/adodb/datadict/datadict-mssqlnative.inc.php differ > Files adodb5.10/datadict/datadict-postgres.inc.php and > ../dev/mantisbt/library/adodb/datadict/datadict-postgres.inc.php differ > Files adodb5.10/drivers/adodb-db2.inc.php and > ../dev/mantisbt/library/adodb/drivers/adodb-db2.inc.php differ > Files adodb5.10/drivers/adodb-mysqli.inc.php and > ../dev/mantisbt/library/adodb/drivers/adodb-mysqli.inc.php differ > Files adodb5.10/drivers/adodb-odbc.inc.php and > ../dev/mantisbt/library/adodb/drivers/adodb-odbc.inc.php differ > Files adodb5.10/drivers/adodb-odbc_mssql.inc.php and > ../dev/mantisbt/library/adodb/drivers/adodb-odbc_mssql.inc.php differ > Files adodb5.10/drivers/adodb-pdo.inc.php and > ../dev/mantisbt/library/adodb/drivers/adodb-pdo.inc.php differ > Files adodb5.10/drivers/adodb-postgres64.inc.php and > ../dev/mantisbt/library/adodb/drivers/adodb-postgres64.inc.php differ > Files adodb5.10/drivers/adodb-sapdb.inc.php and > ../dev/mantisbt/library/adodb/drivers/adodb-sapdb.inc.php differ > > I haven't looked into full detail for all these differences, but I'm > quite sure that if distros use a "vanilla" version of ADOdb Mantis will > break considering the amount of changes made (added function params, > lots of added code for DB-specific drivers...) > > So if patching a bundled lib is not possible, is there anything else > other than reporting upstream (which is already done), that I can do to > resolve the issue ? > > Victor's idea of using git submodules for traceability sounds good as it > would offer traceability, but > > - I did not find an "official" source repository of ADOdb (the CVS on > sourceforge is completely out-of-date), there is a slightly outdated one > on github [2] but it seems specific to the owner's project > - Is it worth the effort of building this, considering the intent of > moving away from ADOdb, as mentioned by David ? If we are not likely to > upgrade to a later version of ADOdb, then I would say no. > > > Bottomline is, based on the fact that ADOdb library is already > customized, I am not sure one more change would be a huge issue, keeping > in mind that without this fix, it will not be possible to implement > support for oracle as the generation of schema upgrade SQL script fails. > > Let me know your thoughts. > > Damien > > > [1] http://sourceforge.net/projects/adodb/files/adodb-php5-only/ > [2] https://github.com/bitweaver/adodb > > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Damien R. <dam...@me...> - 2011-10-26 16:09:13
|
On 26/10/11 16:40, Paul Richards wrote: > 1. David stripped out the customised version we used to run from our git > repo, so we should be the same as some upstream version. Note: adodb > used to be inconsistent with their line feeds, so I wouldn't be > surprised if you've just got whitespace diff's After double-checking, the problem is that this change was only applied on master, but not backported to 1.2.x which is still on version 5.10. Considering that ADOdb is now on 5.14 (released in Sept), I think we should upgrade master to that, and then back-port to 1.2.x. David supports this, as mentioned today on ICQ: [13:59] <dhx1> dregad: therefore we should be upgrading to the latest version of ADOdb for the next 1.2.x release I can then add my fix for oci8, until a new ADOdb version is released to include it (I think this how things have been done in the past, looking at git log). If we don't update ADOdb to latest version, I believe we should in any case align 1.2.x with master on 5.11. > 2. There is not a public svn/cvs of adodb that i'm aware of - I'm not > even sure that the author has one internally given some of the releases > i've seen pushed out before. Not sure if I should laugh or cry ;-) > 3. Whilst it makes sense to **bugfix** the current release - our focus > should be on features in the next release. I'm not sure whether to class > the fact that our oracle support is broken [and always has been] as a > "bug", or a new feature for the next release :) If you ask all the people who have tried - and failed in most cases - to use Mantis with Oracle because that's what their corporate standard is (and that's including me before I gave up), I believe it definitely should be considered as a bug worth the effort to fix in the current version. Damien |
From: Damien R. <dam...@me...> - 2011-10-27 16:32:50
|
Hi, I got an update from upstream (John Lim) that he will include the fix I suggested in the next release of ADOdb (whenever that comes). As suggested by John Reese in IRC, I'll patch the ADOdb for now (in the oracle branch only), with clear mention in README.libs that the bundled ADOdb is modified vs upstream, and put details of the changes in a patch file. I have also committed the latest ADOdb 5.14 to master locally, but not yet pushed it to github (see below). Before doing the same in 1.2.x, since that branch was 1 release behind master (on 5.10), I did a 3-way compare between 5.10 upstream, 5.10 mantis and 5.14 upstream. for the files listed as customized in readme_mantis.txt This highlighted some diffs in our customized files that are actually NOT included in the 5.14 release, e.g.: - adodb.inc.php, l 2540, the (int) cast has been removed; - adodb-datadict.inc.php, l 718+723, if statements are no longer commented out; - datadict/datadict-postgres.inc.php, l 139, the regex is different - etc. This is the list of files where I noticed non-whitespace differences: adodb.inc.php adodb-datadict.inc.php datadict/datadict-mssql.inc.php datadict/datadict-mssqlnative.inc.php datadict/datadict-postgres.inc.php drivers/adodb-db2.inc.php drivers/adodb-odbc.inc.php drivers/adodb-odbc_mssql.inc.php drivers/adodb-postgres64.inc.php (changes ported to 5.14) Then I checked in the history for master, and realized that the same situation existed there, prior to rollout of ADOdb 5.11. Not wanting to break something in the stable branch, I did not make any changes to 1.2.x yet. I would appreciate if one of you (David?), could check whether these differences can be safely ignored or not, since this check must have been done at the time 5.11 was adopted in master. Thanks Damien |
From: Damien R. <dam...@me...> - 2012-01-03 10:36:35
|
Hi, New year bump... Any feedback on this, please ? Thanks Damien On 27/10/11 18:28, Damien Regad wrote: > I have also committed the latest ADOdb 5.14 to master locally, but not > yet pushed it to github (see below). > > Before doing the same in 1.2.x, since that branch was 1 release behind > master (on 5.10), I did a 3-way compare between 5.10 upstream, 5.10 > mantis and 5.14 upstream. for the files listed as customized in > readme_mantis.txt > > This highlighted some diffs in our customized files that are actually > NOT included in the 5.14 release, e.g.: > > - adodb.inc.php, l 2540, the (int) cast has been removed; > - adodb-datadict.inc.php, l 718+723, if statements are no longer > commented out; > - datadict/datadict-postgres.inc.php, l 139, the regex is different > - etc. > > This is the list of files where I noticed non-whitespace differences: > adodb.inc.php > adodb-datadict.inc.php > datadict/datadict-mssql.inc.php > datadict/datadict-mssqlnative.inc.php > datadict/datadict-postgres.inc.php > drivers/adodb-db2.inc.php > drivers/adodb-odbc.inc.php > drivers/adodb-odbc_mssql.inc.php > drivers/adodb-postgres64.inc.php (changes ported to 5.14) > > Then I checked in the history for master, and realized that the same > situation existed there, prior to rollout of ADOdb 5.11. > > Not wanting to break something in the stable branch, I did not make any > changes to 1.2.x yet. I would appreciate if one of you (David?), could > check whether these differences can be safely ignored or not, since this > check must have been done at the time 5.11 was adopted in master. |
From: Victor B. <vi...@fu...> - 2012-01-03 12:48:01
|
Did you try locating the checkins that made the modifications that you listed? Hopefully the comments for these checkins will be helpful. On Tue, Jan 3, 2012 at 2:32 AM, Damien Regad <dam...@me...>wrote: > Hi, > > New year bump... Any feedback on this, please ? > > Thanks > Damien > > On 27/10/11 18:28, Damien Regad wrote: > > I have also committed the latest ADOdb 5.14 to master locally, but not > > yet pushed it to github (see below). > > > > Before doing the same in 1.2.x, since that branch was 1 release behind > > master (on 5.10), I did a 3-way compare between 5.10 upstream, 5.10 > > mantis and 5.14 upstream. for the files listed as customized in > > readme_mantis.txt > > > > This highlighted some diffs in our customized files that are actually > > NOT included in the 5.14 release, e.g.: > > > > - adodb.inc.php, l 2540, the (int) cast has been removed; > > - adodb-datadict.inc.php, l 718+723, if statements are no longer > > commented out; > > - datadict/datadict-postgres.inc.php, l 139, the regex is different > > - etc. > > > > This is the list of files where I noticed non-whitespace differences: > > adodb.inc.php > > adodb-datadict.inc.php > > datadict/datadict-mssql.inc.php > > datadict/datadict-mssqlnative.inc.php > > datadict/datadict-postgres.inc.php > > drivers/adodb-db2.inc.php > > drivers/adodb-odbc.inc.php > > drivers/adodb-odbc_mssql.inc.php > > drivers/adodb-postgres64.inc.php (changes ported to 5.14) > > > > Then I checked in the history for master, and realized that the same > > situation existed there, prior to rollout of ADOdb 5.11. > > > > Not wanting to break something in the stable branch, I did not make any > > changes to 1.2.x yet. I would appreciate if one of you (David?), could > > check whether these differences can be safely ignored or not, since this > > check must have been done at the time 5.11 was adopted in master. > > > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Damien R. <dam...@me...> - 2012-01-03 17:28:00
|
On 03/01/12 13:47, Victor Boctor wrote: > Did you try locating the checkins that made the modifications that you > listed? Hopefully the comments for these checkins will be helpful. I did - or started to, but most of those changes were added as a single, big commit without any details (69aa96a3 "adodb 5.10", Dec '09). My concern is basically that following dhx's upgrade of adodb to a "vanilla" adodb 5.11 (commit b8b21142, May '10) with comment This new release of ADOdb fixes a number of bugs for which the bundled version of ADOdb with MantisBT had been patched. Thus this 5.11 release of ADOdb should hopefully allow us to bundle un unpatched version of ADOdb with MantisBT. the customizations that Paul had made were consequently not applied on top of it. However, I do not think that all of them have actually been implemented upstream, so this is potentially (re-)introducing issues in Mantis. There is at least one occurence that I found, where Paul's fix was not applied: http://phplens.com/lens/lensforum/msgs.php?id=17397&x=1 So I wrote the previous message, in the hope of getting some feedback from David/Paul to determine how best to proceed, especially considering that I did not want to introduce any issues in 1.2.x. I really believe that we should update adodb to the most recent version, including in 1.2.x because of several fixes improving support for oci8 and mssqlnative (which is important, since support for mssql has been dropped in PHP 5.3) Guess I should try to catch Paul and David on IRC. D |
From: David H. <d...@hx...> - 2012-01-07 03:47:46
Attachments:
signature.asc
|
On Tue, 2012-01-03 at 18:24 +0100, Damien Regad wrote: > the customizations that Paul had made were consequently not applied on > top of it. However, I do not think that all of them have actually been > implemented upstream, so this is potentially (re-)introducing issues in > Mantis. There is at least one occurence that I found, where Paul's fix > was not applied: I have performed a diff against our bundled version of 5.10 (in the 1.2.x branch) and the latest vanilla 5.14 version. The problem is that we have no official record or set of patches that explain what our changes are and why they've been made. From a quick look, these are the key changes I think Paul has made: library/adodb/datadict/datadict-mssql.inc.php and library/adodb/datadict/datadict-mssqlnative.inc.php, AlterColumnSQL: Add support for adding and dropping constraints for the ALTER statement so that DEFAULT and NOT NULL are supported on MSSQL. Given that we also use the AddColumnSQL function of ADOdb with DEFAULT and NOT NULL without any of the changes Paul has made to AlterColumnSQL, I'm not sure whether we need this patch to AlterColumnSQL? Paul reported this patch upstream at http://phplens.com/lens/lensforum/msgs.php?id=17949&x=1 although it isn't clear how the problem can be reproduced. No response has been received. library/adodb/datadict/datadict-mssql.inc.php and library/adodb/datadict/datadict-mssqlnative.inc.php, DropColumnSQL: This patch removes the constraints added by the modified AlterColumnSQL function prior to deleting a column. This patch is therefore part of the same patch that modified AlterColumnSQL. library/adodb/datadict/datadict-postgres.inc.php: Changes described at http://phplens.com/lens/lensforum/msgs.php?id=17397&x=1 and not yet merged upstream. library/adodb/drivers/adodb-db2.inc.php: Changes referring to MantisBT bugs #8385 and #8386 to use ISO formatted dates instead of DB2's proprietary date format. Bug #8384 is also referred to and there is another large change that has no clear link to MantisBT (it may or may not be one of our patches). library/adodb/adodb.inc.php: Changes described at http://phplens.com/lens/lensforum/msgs.php?id=17948&x=1 -- this patch seems safe to drop because Paul indicated in the thread it may just be a very subtle performance optimisation (1 second for 100,000 calls of the function). There are likely other small changes I've missed in this comparison. If we go ahead with any plan to update the bundled version of ADOdb 5.10 in master-1.2.x I'd prefer if we email John Lim (ADOdb developer) with our list of patches and a solid explanation as to why they're needed and push for a new ADOdb release so we don't have to maintain the patches locally. Otherwise I don't see a point in updating the version of ADOdb bundled with master-1.2.x and master (except for security fixes), especially when the 'next' branch aims to remove ADOdb entirely. The master branch appears to use a vanilla 5.11 version of ADOdb without any patches. Debian, Fedora and other distribution bundled versions of MantisBT 1.2.x use vanilla (or distribution patched) versions of ADOdb and will not see the benefit of any patches we have applied to the bundled version. I've been pushing towards removing all bundled libraries from the MantisBT repository for a long time now. I am still OK with adding libraries at the time of packaging to assist the Windows users who are deprived of package management. The opposing argument has always been that it is easier to checkout MantisBT from the repository and get it up-and-running quickly if we bundle all dependencies. I don't see the point when the master branch can already locate the 'library' directory outside the MantisBT git root such that users can setup and manage a MantisBT library directory once and use it for multiple installations/checkouts. It's even possible (and recommended) to setup the library directory such that it contains soft links to system provided libraries that are managed by a package manager. |