From: Paul R. <pa...@ma...> - 2013-10-01 08:27:01
|
a) Reasons: filtering in pgsql/mssql - some of the WHERE things don't like blob aka long text fields. IF this is a problem [I've not tested on all dbs], we've generated a problem by this commit with our db support anyway. b) In terms of nightly builds - whilst I somewhat agree, we also say they development not for production, so a note to users about upgrading nightly with manual db query to run would work. At least, if we start looking at master-2.x db changes and 1.3.x changes, I suspect we are going to end up with a lot of changes anyway. "I am not aware of "the reasons we've not used XL before", but anyway I do agree with you on this one. However considering that this change has been out there for 3 years in an "official" branch for which we've offered nightly builds this whole time, IMO the only clean way to go revert to your better solution is to add the necessary schema changes to update the value column, to migrate contents from the textarea column and then drop it. " On Tue, Oct 1, 2013 at 9: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 > > > 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 >> > > |