On 2013-09-29 23:09, Victor Boctor wrote:I believe this approach is vastly superior to the originally-voted
> 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.
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
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  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  are resolved
Given what I just explained above, I think 1.3 (and even further 1.x
> 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.
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.
Big +1 on all the above
> 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
I'm fine with this, on principle, in fact I suffered from it quite a bit
> - avoid reformating changes that just makes merging a night mare. I
> would like a simple cherry-pick to generally work.
over the past 2-3 years of porting commits back and forth between
master/1.2.x... but sometimes it can't be avoided.
I think Paul is passionate about MSSQL, not MySQL ;) That said, I fully
> 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.
agree with the above-stated goals. And I also think my work so far fits
therefore I invite you all to check out my '13x' branch , 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
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 >