Re: [mantisbt-dev] Mantis 1.3 release follow up

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

>> Here is a brief summary of what I've done
>> - support for Oracle
>> - PostgreSQL fixes (nearly done)
>> (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.

On a seperate note, I'm concerned about advertising/"fixing"
 oracle/postgres in 1.3, and then potentially rewriting them. I'd rather
commit to getting the db layer changes backported to the 1.2.x branch by
sunday evening, then risk doing a release and then a release in 2 months
time that screws over users using non-mysql as we change something.

I'm very keen (in fact, my primary focus if I stop working on 2.x will get
getting rid of ADODB, and getting a public release out without adodb before
Christmas). I can probably guarantee a pull request for replacing adodb
within 24-48 hours of the 1.3 release - or of the 1.3/1.4 branch point -
whichever is earlier.

And whilst it might seem like a lot of work to rebase 1.3 off of 1.2 at
first glance (i.e. the suggestion ), my rationale for this is simple:

* It gives us a proper chance to go through stuff, and leave out things and
discuss things again. For example - the language api changes in master. If
we are not going to consider gettext, these need to stay, and we need to
convert language files to the format for them for performance benefit it
gives us [ obviously some work here for siebrand/a conversion script to
convert files]. If we plan to go down the gettext route [easily for
translators, faster then both the lang api formats (iirc)], then there's no
point adding the language api changes into a release.

* There's a few cases where there are improvements in 2.x and improvements
on 1.3 taking different approaches to improving the same area of code. It
will actually be quicker to go through all the changes - re-apply the
obvious ones, and for the ones where we have options, look at both options
and decide what path to go down. I see this option as probably less work,
and likely to give us less bugs long term then working out what we put into
then pulled out of 1.3, and whether the fixes in 2.x are already in 1.3 but
in a different way. (and yes, I know this is gonna be a few hours of work,
but probably less work then trying to compare the state where it is now)




On Tue, Oct 1, 2013 at 10:24 AM, Robert Munteanu
<rob...@gm...>wrote:

> On Tue, Oct 1, 2013 at 11:16 AM, Paul Richards <pa...@ma...>
> wrote:
> > "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
>
>
> I think the question is how 'expensive' is supporting these database
> engines, and that's based on
>
> 1. Developers actively using them
> 2. Their inclusion in our Travis-CI jobs
>
> Based on the fact that Travis CI does not support Oracle [1][2] , SQL
> server [3] , and DB2 ( no issue, no one seems to care ):
>
> I think that we should definitely support:
>
> - MySQL and Postgres, as they are widely used DB engines that we can
> easily test automatically (Tier 1)
> - Oracle and MS SQL server, as they are used by our community and can
> ease adoption into other kinds of platforms - windows-only shops and
> enterprisey shops ( Tier 2 )
>
> In the future it'd be good to add an 'upgrade' test so we can
> guarantee that for MySQL and Postgres the schema changes are the right
> one so I can see these databases getting more automated coverage. On
> the other hand, SQL Server and Oracle will be "relegated" to manual
> testing.
>
> I am not sure about DB2, I'd say that we can't say that this is
> supported as well as the others, so it's still Tier 3 - experimental.
> There doesn't seem to be much code related to it anyway, 20-30 lines
> at best.
>
> Robert
>
> [1]: https://github.com/travis-ci/travis-cookbooks/issues/87
> [2]: https://github.com/travis-ci/travis-ci/issues/689
> [3]: https://github.com/travis-ci/travis-ci/issues/216
>
> -
>
> >
> >
> > 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 <dr...@ma...>
> 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
> >> XHTML-transitional)
> >> - 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.
> >>
> >> Damien
> >>
> >>
> >>
> >> [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 >
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> mantisbt-dev mailing list
> >> man...@li...
> >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________
> > mantisbt-dev mailing list
> > man...@li...
> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> >
>
>
>
> --
> http://robert.muntea.nu/
>
>
> ------------------------------------------------------------------------------
> 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 >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>