"Here is a brief summary of what I've done
- support for Oracle
- PostgreSQL fixes (nearly done)"
Picking up on this...
I have two points too consider:
a) Victor made a good point in chat to me - IIRC along lines of "should we focus only supporting MySQL" [it definitely wasn't quite that point exactly - but that was the implication]. Mantis used to be MySQL only. I added the ports for pgsql/mssql. Others added db2/oracle.
Looking at bug tracker - open/total issues:
db db2 -  0 14
db mssql  - 21 107
db mysql  - 1 85
db oracle - 31 38
db postgresql -  11 58

I think we need to decide what we 'support'.
We need to test schema updates on everything platform we 'support' when we implement them. [our current approach of letting users test schema updates then trying to work out what to do once you find a schema update doesnt' work on one db, could have been done in a different way, and everyone else on other db's has updated, doesn't give a good experience for end users.]
Looking at the above numbers i'd suggest that:
a) no one/ very few people are using db2
b) oracle's got 31 open bugs [I suspect a bunch of these are reported/being fixed by dregad though].
Personally, I look at our users and expect them to probably use either
a) MySQL [popular on Linux, webhosting, available via Microsoft on IIS as platform addon thing]
b) if windows shop (and not using the IIS download of MySQL) mssql
c) Oracle is used by large corporates, and might have some use by our users - although, I also wonder if large corporates would be happy running mantis (in some cases)
d) Postgresql is a lovely database engine, but I wonder what the actual usage is
Which leaves me to say:
a) where's db2 fit in
b) what do we actually want to support
 I) MySQL only
ii) combination of the above
b) Whilst I suspect the oracle support is perfect, I'm not sure adodb has got pgsql right (in terms of data types) - I'm hesitant of us going from broken pgsql to 'fixed pgsql' and then refixing it later on - and having users having to deal with the resulting mess.
In any case, rather then a debate over the virtues of adodb/db-layer-2(i'll call it), What should we SUPPORT?
Victor: I know you said something in our chats on this - so hopefully you can remember what you said/meant as I can't :)
On Tue, Oct 1, 2013 at 1:29 AM, Damien Regad <dregad@mantisbt.org> wrote:
On 2013-09-29 23:09, Victor Boctor wrote:

> Damien has been driving the work to take the master branch minus
> blocking features and use that as the foundation for 1.3, it has been a
> while since we started this effort as well.  According to Damien, he is
> making good progress and should be in a state to merge to master soonish.

I believe this approach is vastly superior to the originally-voted
option of going for a branch off 1.2.x, because it:

- ensures we retain all the good work done so far by dhx, Paul, Daryn,
giallu and others on the 1.3 branch
- doesn't throw away all the efforts (mainly mine and Robert's) of
porting over 600 1.2 commits to master
- represents a much smaller effort to release the branch compared to
identifying and then backporting the "good stuff" from master to 1.2

Moreover, in a somewhat anti-democratic way, as I am nearly the only
truly active dev at the moment (not counting grangeway who until today
seemed to only care about 2.x), I felt justified to follow my own
preference ;)

Consequently, as some of you know I started work on this option back in
June, but things slowed down quite a bit over the summer due to vacation
and other personal priorities. I picked things up again around mid-August.

I have intentionally kept this work completely separate from the main
mantisbt repository until now (i.e. I maintain several private branches
on my own github fork), to avoid "polluting" the main repo and forcing
the team's hand, until I had something to show for, while keeping things
in sync by regularly merging master into my work.

Today, I estimate my branch to be around 90% ready for alpha.

I've been working with John Lim (ADOdb author), to have all our fixes
implemented upstream (and btw I got push access to ADOdb, which is now
mirrored at Github [1] thanks to yours truly), and expect him to release
v5.19 shortly - hopefully this week. This is a prereq for fixing a good
number of known MSSQL, PosgreSQL and Oracle support issues.

My original intention was to wait for this before merging back into
master, to have an unpatched bundled library, but Victor convinced me it
would be good to do it sooner arguing that by the time we complete our
testing the library will be released.

Here is a brief summary of what I've done
- support for Oracle
- PostgreSQL fixes (nearly done)
- i18n / Translatewiki
   - reverted the encoding of strings to avoid having to code a new TW
module to read our custom format
   - yes Paul that means your code has not been touched (since it was
backwards-compatibly to begin with), just the strings definition
   - spoke with siebrand to get a feel of what it would take to "switch"
translations from 1.2 to master
- fixed XML parse errors due to XHTML-strict (now back to
- introduced git submodules for ADOdb and phpMailer

That means most (if not all) issues identified in [2] are resolved

> I've discussed with Paul, dropping master-2.x as an option for 1.3.
>   However, he is suggesting that we go for option #1, then go through a
> process to get in features into 1.3 as appropriate and after agreement
> with the team.

Given what I just explained above, I think 1.3 (and even further 1.x
releases) should just be a transition, and I believe dropping 2.x
entirely would be a mistake as there have been a lot of excellent things
done in Paul's branch, which would be a shame to lose.

Once we have broken today's deadlock with a release of 1.3, we can
define the roadmap to get to 2.x.

I would also work with Paul to port/adapt his 2.x branch on top of 1.3.

> Independent of what the new "master" means, I would like to recommend
> the following:
> - new master is always in a shipping state.
> - new master doesn't get big new features without code reviews managed
> through pull request code reviews.
> - master-2.x moves out of mantisbt github account to paul's account.  We
> should do something similar for vnext.  Setting the right expectations
> that it is not an official branch or one that developers are expected to
> port to.
> - developers need only to worry about getting their changes in shipping
> branches and master -- no backport to some developer's private or vnext
> branch.  This is the responsibility of that developer and should
> discourage them from having a long term private branch.
> - no long term private branches -- only feature branches that fixes one
> issue.

Big +1 on all the above

> - avoid reformating changes that just makes merging a night mare.  I
> would like a simple cherry-pick to generally work.

I'm fine with this, on principle, in fact I suffered from it quite a bit
over the past 2-3 years of porting commits back and forth between
master/1.2.x...  but sometimes it can't be avoided.

> Goals for 1.3:
> - No worse than 1.2.x - It is OK to ship 1.3 with broken MS SQL if 1.2.x
> was broken.  Same applies to any other issue that falls in such category
> (even preventative security issues).  I personally think most of the
> community focuses on MySQL and we need to do the same.  Paul is
> passionate about fixing that, but we are targeting this for 1.4.
> - Unblock the team - this is not a customer feature directly, but it
> enables us to be in a state where we can deliver value through 1.2.x
> (security fixes) and 1.3.x (enhancements).
> - Start focusing on customer value and not in perfect html, nice db
> abstraction, better internal api, etc.  I would rather work on UX,
> discoverability, webservices, etc.

I think Paul is passionate about MSSQL, not MySQL ;) That said, I fully
agree with the above-stated goals. And I also think my work so far fits
that bill.

therefore I invite you all to check out my '13x' branch [3], and let me
know your feedback. Based on Victor's request, I should be able to merge
it into master later this week, unless someone objects - speak now or
forever hold your peace ;)

This means we can probably have a working 1.3 alpha ready before the end
of October.


[1] https://github.com/ADOdb/ADOdb
[2] http://www.mantisbt.org/bugs/view.php?id=14088
[3] https://github.com/dregad/mantisbt/tree/13x

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
mantisbt-dev mailing list