From: Victor B. <vb...@gm...> - 2013-09-29 21:09:20
|
Hi all, In the last couple of days I had multiple long conversations with Damien and Paul over chat. It seems that we have been doing a lot of work on the master and master-2.x branches, though I'm unclear about how close we are to shipping 1.3. We've also seen some disconnect between Paul (with his master-2.x branch) and the direction that the rest of the team was heading. Paul's first priority is really to replace adodb and provide a better support story for MS SQL and Pgsql. He has done a lot of good work in 2.x in addition to that, which may be useful to look at in the future. 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. The rest of the team really can identify themselves only with 1.2.x branch, being the only real branch that ships customer value. I know that this is the case for me, Robert, Roland, etc. We have few options to go from here: 1. Use 1.2.x as the basis for 1.3 2. Use master minus few features as the basis. 3. Use master-2.x as the basis. Based on the voting we have done in the past, we landed on 1 (from memory or some hybrid based on it), but Damien then negotiated an option closer to 2. Maybe it is a good idea to see where we are at and make a decision. 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. 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. - avoid reformating changes that just makes merging a night mare. I would like a simple cherry-pick to generally work. 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 intentionally didn't add specific features. I think we can have discussions there, but my point is that there is no feature that should stop us from shipping 1.3.0 even if it is exactly what we have today in master-1.2.x. Once we have the right shipping vehicles, the right features will land, whether they are based on porting smaller changes from branches that we abandoned or new features/fixes that were developed new. I personally favor the master becomes == 1.2.x, since it allows us to be shippable and clean right away. We have put enough time before the other big branches with risk of amount of churn and ability to support such churn. This also levels the field so that all such big branches are put aside which doesn't favor specific set of changes over another. However, I'm willing to change my vote based on data provided by the team. Although we have been push off this hard decision for a while based on future promises. My main priority is to get us out of this deadlock and set us into a path for being productive. I don't want the team to go through all checkins in master-2.x or master, or port to these branches. I want us to consider such branches as private branches to the devs that are working on them and it is their tax to get the goodness gradually into our new master. It is unfortunate to leave some of this work behind, but it may be our only way to really move forward. It should be a learning experience for us to chunk our work into smaller work items that can add value and ship on their own. This enables us to deliver value to users sooner, makes code reviews feasible, and avoids long living branches. Thanks, -Victor |
From: Paul R. <pa...@ma...> - 2013-09-29 21:30:29
|
> I personally favor the master becomes == 1.2.x, since it allows us to be > shippable and clean right away. We have put enough time before the other > big branches with risk of amount of churn and ability to support such > churn. This also levels the field so that all such big branches are put > aside which doesn't favor specific set of changes over another. However, > I'm willing to change my vote based on data provided by the team. Although > we have been push off this hard decision for a while based on future > promises. > > My main priority is to get us out of this deadlock and set us into a path > for being productive. I don't want the team to go through all checkins in > master-2.x or master, or port to these branches. I want us to consider such > branches as private branches to the devs that are working on them and it is > their tax to get the goodness gradually into our new master. > > Whilst in the past I've been against using 1.2.x as a new master, as there's some stuff in 1.3 - I'm basically at the point I'd rather use 1.2.x and spend time porting stuff from 1.3/elsewhere. There are a couple of commits that went into a 1.2 release that I think should not have gone in - but I'd rather work on implementing those in a more acceptable way. I'd personally like to take 1.2.15 as a branch point Paul |
From: Paul R. <pa...@ma...> - 2013-09-29 21:41:05
|
"I don't want the team to go through all checkins in master-2.x or master, or port to these branches" I also meant, to add, if we do use 1.2.15 as a stable branch point, i'm willing to do the leg work to pull some of the fixes across from 1.3/2.x and 1.2.x. On Sun, Sep 29, 2013 at 10:30 PM, Paul Richards <pa...@ma...>wrote: > > I personally favor the master becomes == 1.2.x, since it allows us to be >> shippable and clean right away. We have put enough time before the other >> big branches with risk of amount of churn and ability to support such >> churn. This also levels the field so that all such big branches are put >> aside which doesn't favor specific set of changes over another. However, >> I'm willing to change my vote based on data provided by the team. Although >> we have been push off this hard decision for a while based on future >> promises. >> >> My main priority is to get us out of this deadlock and set us into a path >> for being productive. I don't want the team to go through all checkins in >> master-2.x or master, or port to these branches. I want us to consider such >> branches as private branches to the devs that are working on them and it is >> their tax to get the goodness gradually into our new master. >> >> > Whilst in the past I've been against using 1.2.x as a new master, as > there's some stuff in 1.3 - I'm basically at the point I'd rather use 1.2.x > and spend time porting stuff from 1.3/elsewhere. > > There are a couple of commits that went into a 1.2 release that I think > should not have gone in - but I'd rather work on implementing those in a > more acceptable way. I'd personally like to take 1.2.15 as a branch point > > Paul > > |
From: Robert M. <rob...@gm...> - 2013-09-30 11:45:24
|
On Mon, Sep 30, 2013 at 12:09 AM, Victor Boctor <vb...@gm...> wrote: > I personally favor the master becomes == 1.2.x, since it allows us to be > shippable and clean right away. +1 > My main priority is to get us out of this deadlock and set us into a path > for being productive. Big +1 and thanks for picking this up. Robert -- http://robert.muntea.nu/ |
From: Damien R. <dr...@ma...> - 2013-10-01 00:29:33
|
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 |
From: Victor B. <vb...@gm...> - 2013-10-01 03:48:09
|
Damien, Do we have a high level list of changes in master? You have listed the changes you made to address the blocking issue, but it would be useful to understand what master minus 1.2.x means all up. Is the list xhtml and db related fixes for Oracle/PgSql? or is there more to it? The same would be useful for 2.x minus master or 2.x minus 1.2.x. I've downloaded 13x branch and playing with it. Will also attempt to go through the checkins in the master branch. On Mon, Sep 30, 2013 at 5:29 PM, 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 > |
From: Victor B. <vb...@gm...> - 2013-10-01 03:55:32
|
Also it would be useful to understand the list of schema changes (if any). On Mon, Sep 30, 2013 at 8:48 PM, Victor Boctor <vb...@gm...> wrote: > Damien, > > Do we have a high level list of changes in master? You have listed the > changes you made to address the blocking issue, but it would be useful to > understand what master minus 1.2.x means all up. Is the list xhtml and db > related fixes for Oracle/PgSql? or is there more to it? > > The same would be useful for 2.x minus master or 2.x minus 1.2.x. > > I've downloaded 13x branch and playing with it. Will also attempt to go > through the checkins in the master branch. > > > > On Mon, Sep 30, 2013 at 5:29 PM, 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 >> > > |
From: Damien R. <dr...@ma...> - 2013-10-01 07:16:31
|
On 2013-10-01 05:55, Victor Boctor wrote: > Also it would be useful to understand the list of schema changes (if any). List of schema changes vs 12x (status for my 13x branch as of today): 184. updates to stored filters (Daryn/2010) 185. new column: textarea (memo) custom field type (Daryn/2010) 186. fix truncated custom fields name in history (me/2012) 187. new index for bug monitor table (me/2013) 188. alter column from I (int) to L (bool) to fix pgsql issue (me/2012) 189. idem |
From: Paul R. <pa...@ma...> - 2013-10-01 07:52:07
|
My main issue with 1.3 is there is some stuff that even I committed that i'm not sure i'm now happy with - hence the rational for going off of 1.2.x. Having said that, my expectation would be we'd cherry pick stuff back in order from 1.3, so that it's not too much work (tedious but not too taxing). For example 185. new column: textarea (memo) custom field type (Daryn/2010) In the 2.x branch, I change the field to XL for custom_field_String, which negates the need for the schema update in 185. If you consider the reasons we've not used XL before, and the implementation ( https://github.com/mantisbt/mantisbt/commit/839f1d68bc771e579a9f48324624973e0c996ebc), you'll probably agree that just changing the type of the existing field is the more sensible solution. Schema changes in 2.x are as follows: /* 185 */ $upgrade[] = array( 'AlterColumnSQL', array( '{custom_field_string}', "value XL NULL DEFAULT NULL " ) ); /* 186 */ $upgrade[] = array( 'UpdateFunction', "update_export_columns", array() ); /* 187 */ $upgrade[] = array( 'AlterColumnSQL', array( '{user}', "username C(255) NOTNULL DEFAULT ''" ) ); /* 188 */ $upgrade[] = array( 'AddColumnSQL', array( '{bug}', "description XL NOTNULL DEFAULT ''" ) ); /* 189 */ $upgrade[] = array( 'AddColumnSQL', array( '{bug}', "steps_to_reproduce XL NOTNULL DEFAULT ''" ) ); /* 190 */ $upgrade[] = array( 'AddColumnSQL', array( '{bug}', "additional_information XL NOTNULL DEFAULT ''" ) ); /* 191 */ $upgrade[] = array( 'UpdateFunction', "migrate_bug_text", array() ); /* 192 */ $upgrade[] = array( 'DropTableSQL', array( '{bug_text}' ) ); /* 193 */ $upgrade[] = array( 'DropColumnSQL', array( '{bug}', "bug_text_id" ) ); /* 194 */ $upgrade[] = array( 'AddColumnSQL', array( '{bugnote}', "note XL NOTNULL DEFAULT ''" ) ); /* 195 */ $upgrade[] = array( 'UpdateFunction', "migrate_bugnote_text", array() ); /* 196 */ $upgrade[] = array( 'DropTableSQL', array( '{bugnote_text}' ) ); /* 197 */ $upgrade[] = array( 'DropColumnSQL', array( '{bugnote}', "bugnote_text_id" ) ); /* 198 */ $upgrade[] = array( 'UpdateFunction', "check_project_hierarchy", array() ); /* 199 */ $upgrade[] = array( 'CreateIndexSQL', array( 'idx_project_hierarchy','{project_hierarchy}','child_id,parent_id',array( 'UNIQUE'))); /* 200 */ $upgrade[] = array( 'AlterColumnSQL', array('{tokens}','owner I UNSIGNED NOTNULL') ); /* 201 */ $upgrade[] = array( 'AddColumnSQL', array( '{bug_file}', "downloaded I UNSIGNED NOTNULL DEFAULT '0'" ) ); /* 202 */ $upgrade[] = array( 'AddColumnSQL', array( '{project_file}', "downloaded I UNSIGNED NOTNULL DEFAULT '0'" ) ); /* 203 */ $upgrade[] = array( 'AddColumnSQL', array( '{user_pref}', "theme C(32) NOTNULL DEFAULT '' " ) ); On Tue, Oct 1, 2013 at 8:16 AM, Damien Regad <dr...@ma...> wrote: > On 2013-10-01 05:55, Victor Boctor wrote: > > Also it would be useful to understand the list of schema changes (if > any). > > List of schema changes vs 12x (status for my 13x branch as of today): > > 184. updates to stored filters (Daryn/2010) > 185. new column: textarea (memo) custom field type (Daryn/2010) > 186. fix truncated custom fields name in history (me/2012) > 187. new index for bug monitor table (me/2013) > 188. alter column from I (int) to L (bool) to fix pgsql issue (me/2012) > 189. idem > > > > > ------------------------------------------------------------------------------ > 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 > |
From: Damien R. <dr...@ma...> - 2013-10-01 08:10:06
|
On 2013-10-01 09:52, Paul Richards wrote: > 185. new column: textarea (memo) custom field type (Daryn/2010) > In the 2.x branch, I change the field to XL for custom_field_String, > which negates the need for the schema update in 185. If you consider the > reasons we've not used XL before, and the implementation ( > https://github.com/mantisbt/mantisbt/commit/839f1d68bc771e579a9f48324624973e0c996ebc > ), you'll probably agree that just changing the type of the existing > field is the more sensible solution. 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. D |
From: Damien R. <dr...@ma...> - 2013-10-01 07:46:26
|
On 2013-10-01 05:48, Victor Boctor wrote: > Do we have a high level list of changes in master? I didn't maintain one, but we have a fairly big changelog as reference (100+ issues), which will get even bigger as I merge my 13x branch and all the corresponding issues get resolved. http://www.mantisbt.org/bugs/changelog_page.php?version_id=101 > You have listed the > changes you made to address the blocking issue, but it would be useful > to understand what master minus 1.2.x means all up. Is the list xhtml > and db related fixes for Oracle/PgSql? or is there more to it? Off the top of my head, and by no means a comprehensive list. - HTML fixes and switch to CSS; - improvements on the javascripts/ajax (e.g. jQuery); - improvements/fixes to the filter api; - lots of security improvements XSS, etc - better documentation platform (publican) - many code cleanup and api improvements (back-end changes, generally not visible to users) Difficult to do better on short notice, i.e. without a time-consuming, side-by-side comparison of the commits in each version > The same would be useful for 2.x minus master or 2.x minus 1.2.x. Grangeway is probably better positioned to answer this one than I am, but I don't think there would be a huge diff between these 2 options, because 2.0.x was branched off master around the time when dhx stopped actively working on it, which means that most commits after this date would have been pushed to both 1.2.x and master. > I've downloaded 13x branch and playing with it. Will also attempt to go > through the checkins in the master branch. Great. Note, don't go and try to fix still-open issues currently targeted to 1.3.x in the tracker, as they may have already been fixed in my branch. D |
From: Roland B. <ro...@at...> - 2013-10-09 08:59:36
|
Sorry for giving no feedback, I have not much time for MantisBT at the moment. I am fine seeing your changes merged in master. Also no time to get a bit more familiar with Git and Git submodules at the moment. Just one question: Do I have to change anything if I make changes in any other directory than adodb or phpmailer? Roland > Damien Regad <dr...@ma...> hat am 9. Oktober 2013 um 00:21 geschrieben: > > > Hi all, > > Except for a few comments from Victor, I have not received any feedback > on my '13x' branch, so I assume everybody's fine with it (or doesn't > care ?). > > I will therefore proceed with merging the changes into master soon, i.e. > after making sure that the build scripts can cope with the git submodules. > > If you're not happy with this, speak now or forever hold your peace... > > To minimize headaches and problems with porting changes to/from 1.2.x > branch, I will also add the submodules for ADOdb and phpMailer there. I > invite you to familiarize yourself with their use, and read the wiki > page I wrote: > > http://www.mantisbt.org/wiki/doku.php/mantisbt:git_submodules > > At the same time, I will also make 'master' the default branch at Github. > > Damien > > > > ------------------------------------------------------------------------------ > 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=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Damien R. <dr...@ma...> - 2013-10-09 11:55:53
|
On 2013-10-09 10:59, Roland Becker wrote: > Just one question: Do I have to change anything if I make changes in any other > directory than adodb or phpmailer? All code outside of submodules dirs is handled exactly as before. If you need to make changes to one of the submodules, e.g. to fix a bug or update to newer version of library, then you can either - do it from within the MantisBT submodule (but you must make sure to commit and push your local changes to origin then otherwise it will be a mess), or - make changes directly in origin and then fetch/update the submodule afterwards. But even without making changes, you could be facing issues as I described on the wiki page, when switching branches, cherry-picking, merging, etc. D PS: If we realize later on that it is too much of overhead/pain/mess to manage these submodules, we can always revert back to copying the whole library. |
From: Paul R. <pa...@ma...> - 2013-10-01 08:17:04
|
"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 > |
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 >> > > |
From: Paul R. <pa...@ma...> - 2013-10-01 08:32:34
|
On a different note, and your about to hate me : https://github.com/mantisbt/mantisbt/commit/ce3450aaabbd9d9feceb03d77d4358f195e7d966 Surely, we want to store custom field ID as opposed to field name in the history table, such that if a custom field gets renamed, or two custom fields have the same name, the history table gets linked to the correct custom field. On Tue, Oct 1, 2013 at 9:26 AM, Paul Richards <pa...@ma...> wrote: > 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 >>> >> >> > |
From: Damien R. <dr...@ma...> - 2013-10-01 09:16:28
|
On 2013-10-01 10:32, Paul Richards wrote: > On a different note, and your about to hate me : > https://github.com/mantisbt/mantisbt/commit/ce3450aaabbd9d9feceb03d77d4358f195e7d966 > Surely, we want to store custom field ID as opposed to field name in the > history table, such that if a custom field gets renamed, or two custom > fields have the same name, the history table gets linked to the correct > custom field. No hate, really. This is a good point that I did not consider, since it was a fix I just built on existing practice without thinking further. Replacing the CF name by CF id would require either modifying the update_history_long_custom_fields() helper function, or create another UpdateFunction schema change step. I'll file an issue to track this. D |
From: Paul R. <pa...@ma...> - 2013-10-01 09:21:04
|
>From working on the 'radical' 2.x idea, I've concluded 3 things: a) I like mantis b) I dislike the mantis 1.2.x codebase c) I'm not happy with the 2.x codebase -> trying to convert X to an object, and looking at code paths, you find in some cases that if you do change Y by route Z, it'll not email, update whatever, and check permission A but if you do the same change by route ZZ, it'll check permission B, but email And that's with me ignoring the soap api :) It's quite a good game to play! On Tue, Oct 1, 2013 at 10:16 AM, Damien Regad <dr...@ma...> wrote: > > On 2013-10-01 10:32, Paul Richards wrote: > > On a different note, and your about to hate me : > > > https://github.com/mantisbt/mantisbt/commit/ce3450aaabbd9d9feceb03d77d4358f195e7d966 > > Surely, we want to store custom field ID as opposed to field name in the > > history table, such that if a custom field gets renamed, or two custom > > fields have the same name, the history table gets linked to the correct > > custom field. > > No hate, really. This is a good point that I did not consider, since it > was a fix I just built on existing practice without thinking further. > > Replacing the CF name by CF id would require either modifying the > update_history_long_custom_fields() helper function, or create another > UpdateFunction schema change step. > > I'll file an issue to track this. > > D > > > ------------------------------------------------------------------------------ > 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 > |
From: Robert M. <rob...@gm...> - 2013-10-01 09:24:53
|
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/ |
From: Paul R. <pa...@ma...> - 2013-10-01 20:58:39
|
>> 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 > |
From: Paul R. <pa...@ma...> - 2013-10-02 22:34:19
|
I've just spent the last few hours going through identifying the unique patches between the 3 branches (1.2-m, 1.3, 2.x) that haven't been ported in all various directions - it appears at first glance there might still be patches in 1.2.x that have not been ported to 1.3.x. I'll try and finish that up tomorrow and construct a 1.2.x based master [and a list of patches not merged in so we can go through them] On Tue, Oct 1, 2013 at 9:58 PM, Paul Richards <pa...@ma...> wrote: > >> 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 >> > > |
From: Damien R. <dr...@ma...> - 2013-10-03 09:37:05
|
On 03.10.2013 00:34, Paul Richards wrote: > I'll try and finish that up tomorrow and construct a 1.2.x based master Please don't construct anything on top of 1.2.x and use master instead as your basis. As I told you several times, it will be much easier and less effort to *remove* the things included in master that shouldn't be released rather than doing the reverse. master has always been the official "next" version, and I don't agree with throwing it all away without a clear rationale (i.e. just because you say so). If it really has to come down to that (I doubt it), this should be a formal decision that a everyone in the team (or at least a majority) adheres to. > [and a list of patches not merged in so we can go through them] That would be very useful. Thanks. |
From: Victor B. <vb...@gm...> - 2013-10-03 16:41:54
|
I agree that it would be easier identify issues in master that we want to revert or improve. +1 for finding out list of fixes in 1.2.x that is not in master. For the DB fixes, I think it is OK to have tactical fixes based on adodb with vision to change to an alternative approach that gives us better story in the future. An important part of the cross-RDMS support story is to have a continuous integration that provides such checks after every checkin. If not, then we will always end up risking breaking database types that we care about. My preference is to not change the DB layer as part of 1.3, otherwise, we will end up with something that is less likely to ship even compared to master and master-1.3.x, since this will be even more churn. On Thu, Oct 3, 2013 at 2:36 AM, Damien Regad <dr...@ma...> wrote: > On 03.10.2013 00:34, Paul Richards wrote: > > I'll try and finish that up tomorrow and construct a 1.2.x based master > > Please don't construct anything on top of 1.2.x and use master instead > as your basis. > > As I told you several times, it will be much easier and less effort to > *remove* the things included in master that shouldn't be released rather > than doing the reverse. master has always been the official "next" > version, and I don't agree with throwing it all away without a clear > rationale (i.e. just because you say so). > > If it really has to come down to that (I doubt it), this should be a > formal decision that a everyone in the team (or at least a majority) > adheres to. > > > > [and a list of patches not merged in so we can go through them] > > That would be very useful. Thanks. > > > > > ------------------------------------------------------------------------------ > 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 > |
From: Paul R. <pa...@ma...> - 2013-10-03 18:11:53
|
Bear with me... I'm not planning on throwing anything away so don't worry. I'm planning on applying in order every commit in 1.3 (and making a list of the commits Left out). The leftout category are the ones I'd then like to revert. At same time making a list of things to merge from 2.x and master.12 that we've missed. Once that's done we can debate whether to generate the final branch by reverting the commits or by not including them in first place. In any case, I have no preference as a diff of the code should be identical at this point. So you can decide if you want history or not On Thursday, October 3, 2013, Damien Regad <dr...@ma...> wrote: > On 03.10.2013 00:34, Paul Richards wrote: >> I'll try and finish that up tomorrow and construct a 1.2.x based master > > Please don't construct anything on top of 1.2.x and use master instead > as your basis. > > As I told you several times, it will be much easier and less effort to > *remove* the things included in master that shouldn't be released rather > than doing the reverse. master has always been the official "next" > version, and I don't agree with throwing it all away without a clear > rationale (i.e. just because you say so). > > If it really has to come down to that (I doubt it), this should be a > formal decision that a everyone in the team (or at least a majority) > adheres to. > > >> [and a list of patches not merged in so we can go through them] > > That would be very useful. Thanks. > > > > ------------------------------------------------------------------------------ > 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 > |
From: Damien R. <dr...@ma...> - 2013-10-08 22:21:16
|
Hi all, Except for a few comments from Victor, I have not received any feedback on my '13x' branch, so I assume everybody's fine with it (or doesn't care ?). I will therefore proceed with merging the changes into master soon, i.e. after making sure that the build scripts can cope with the git submodules. If you're not happy with this, speak now or forever hold your peace... To minimize headaches and problems with porting changes to/from 1.2.x branch, I will also add the submodules for ADOdb and phpMailer there. I invite you to familiarize yourself with their use, and read the wiki page I wrote: http://www.mantisbt.org/wiki/doku.php/mantisbt:git_submodules At the same time, I will also make 'master' the default branch at Github. Damien |