| ../irclogs/#mantishelp.2010-08-14.log | ||
| --- scribe started --- | 00:00 | |
| dhx_m | nuclear_eclipse: I was working on fixing project hierarchies :) | 01:38 |
|---|---|---|
| nuclear_eclipse | so stop working and get it done already :P | 01:39 |
| dhx_m | Paul and I were talking about databases the other day | 01:39 |
| nuclear_eclipse | uh oh | 01:39 |
| dhx_m | that is something I consider more urgent | 01:39 |
| dhx_m | seeing as people can't upgrade MantisBT on MSSQL, etc | 01:40 |
| dhx_m | so just to scare you... I was looking at NoSQL options :) | 01:40 |
| dhx_m | and solving the conflict problem while we're at it | 01:41 |
| nuclear_eclipse | omg | 01:43 |
| * nuclear_eclipse starts removing commit privileges | 01:43 | |
| dhx_m | haha | 01:43 |
| dhx_m | the problem with our current relational database backend is that it doesn't know what to do with merge conflicts | 01:45 |
| nuclear_eclipse | merge conflicts? wth are we merging? | 01:45 |
| dhx_m | ideally it should notify users if they're committing changes to a bug and the bug has changed since they opened the edit page | 01:45 |
| dhx_m | so they can verify what to do with the merge | 01:46 |
| nuclear_eclipse | oh, that's painful though, because it opens a can of self-replicating worms | 01:46 |
| nuclear_eclipse | basically, without going all Drupal with "everything is a node", there's not really any simple way to handle it in a way that works for everything that can be attached to an issue | 01:48 |
| nuclear_eclipse | eg, you'd have to be able to handle conflicts on custom fields, and some method of handling it for plugin data | 01:48 |
| dhx_m | well something like CouchDB keeps versions of each value stored and when it finds a conflict during replication, it picks the longest chain of revisions | 01:49 |
| dhx_m | if it stuffs up you have the full revision history to go back to | 01:49 |
| nuclear_eclipse | stop right there | 01:49 |
| nuclear_eclipse | the answer to the question is not "change backends" | 01:49 |
| dhx_m | reinvent the wheel in SQL? :p | 01:50 |
| nuclear_eclipse | no, the answer is to ignore it, or at the very least try to detect an update conflict and let the user open a new tab/page to manually sort it out | 01:50 |
| nuclear_eclipse | anything else you try to do will stuff something up in a way the user was not expecting/wanting, almost guaranteed | 01:51 |
| nuclear_eclipse | I spent two weeks of hard core thinking/planning on this a year ago | 01:51 |
| dhx_m | well the thing is, that is already the case | 01:51 |
| dhx_m | the user doesn't know if they're creating a conflict | 01:52 |
| dhx_m | ie. having a bug update window open for 2 days (in which time 10 edits are made) | 01:52 |
| nuclear_eclipse | my point is that if you try to do something smarter than interrupt a confilct and tell the user to fix it before submitting a second time, you will only make it worse | 01:52 |
| dhx_m | then after 2 days they save it, undoing those 10 edits | 01:52 |
| nuclear_eclipse | and relying on database specific rollbacks is not the answer | 01:52 |
| dhx_m | well we can/should interrupt on a conflict being detected | 01:53 |
| nuclear_eclipse | right, I've just never had the time to implement that sort of detection and interface | 01:53 |
| dhx_m | to use CouchDB as an example again, it detects conflicts for us... and it has an API for resolving conflicts manually (whichever way we want) | 01:53 |
| nuclear_eclipse | stop | 01:53 |
| nuclear_eclipse | youre not getting my point | 01:54 |
| dhx_m | as opposed to needing to do it ourselves in SQL | 01:54 |
| nuclear_eclipse | we cant implement a feature that only works on a single database that < 1% of the population uses | 01:54 |
| dhx_m | by "resolving conflicts manually" I meant that we show the user a page where they are notified a conflict exists and asks them to confirm a default action (or go back and fix it) | 01:54 |
| nuclear_eclipse | detecting the conflict outself is easy: compare last_updated timestamp | 01:55 |
| nuclear_eclipse | we don't need couchdb to tell us we're breaking things | 01:55 |
| dhx_m | we'd need granularity down to the per-field level | 01:55 |
| nuclear_eclipse | no no no | 01:55 |
| nuclear_eclipse | anything more than bug-level detection is wrong | 01:55 |
| dhx_m | mantis_bug_table could be updated from many different places (bug_update, a plugin page, etc) | 01:55 |
| nuclear_eclipse | fields aren't just distinct values | 01:55 |
| nuclear_eclipse | if you update one, a *lot* of people expect that to affect the values of other fields too | 01:56 |
| dhx_m | right | 01:56 |
| nuclear_eclipse | you *have* to defer the entire bug status back to the user | 01:56 |
| nuclear_eclipse | s/status/state/ | 01:56 |
| dhx_m | what I've been thinking is that we need another layer between the Bug class and the "users" of that data | 01:56 |
| nuclear_eclipse | sigh | 01:56 |
| dhx_m | the layer would perform the access checks amongst other checks (priority must be at least high for the severity to be above major, for instance) | 01:57 |
| nuclear_eclipse | you're over complicating things | 01:57 |
| dhx_m | at the moment we just duplicate code (badly) throughout MantisBT without a common interface for updating bugs in a consistent way | 01:57 |
| nuclear_eclipse | that sort of interstitial is 100% unrelated to handling conflicts | 01:58 |
| dhx_m | well it would be needed to resolve conflicts correctly (so the bug can't enter an invalid state where fields have conditions on their usage) | 01:58 |
| nuclear_eclipse | honestly, the best solution when a confilct is detected is to take the user back to the update form, and show both the current value (in the database) side-by-side with the values they tried to submit, and let them manually resolve the conflict and resubmit the form | 01:59 |
| nuclear_eclipse | anything other than that is only going to result in behavior that users don't want or aren't expecting | 02:00 |
| dhx_m | for instance, if status >= assigned then check if handler_id != NO_USER | 02:01 |
| nuclear_eclipse | dhx_m: that's still 100% unrelated to dealing with merge conflicts | 02:01 |
| dhx_m | well I was planning on showing things side-by-side :) | 02:02 |
| dhx_m | (in my hypothetical system) | 02:02 |
| nuclear_eclipse | dhx_m: my point is that we should only be detecting conflicts based on last_updated; anything else is going to miss something | 02:03 |
| dhx_m | true... I guess like MediaWiki? | 02:04 |
| nuclear_eclipse | esp in cases where plugins have touched last_updated because it has an attached field that changed | 02:04 |
| nuclear_eclipse | mediawiki has it easy because it's a single data field, so *any* change is by definition a conflict, and very simple to deal with | 02:05 |
| dhx_m | yep | 02:14 |
| CIA-103 | Mantisbt: hickseydr * r596097f32c98 / (6 files in 3 dirs): Issue #12253: Implement management page to view workflow graph | 04:10 |
| CIA-103 | Mantisbt: hickseydr * rb6a272191422 / (bug_update.php bugnote_add.php core/bugnote_api.php): Fix #11758: Improve handling of reassign on feedback feature | 04:51 |
| CIA-103 | Mantisbt: hickseydr * r203f17e69ac2 /bug_update.php: Fix #11758: Improve handling of reassign on feedback (bug_update) | 05:08 |
| CIA-103 | Mantisbt: hickseydr * r95ac1e0caaf1 / (bug_update.php bugnote_add.php): Fix #12205: Disable reassign on feedback when the handler replies | 05:15 |
| Github | mantisbt: master Paul * 6d6e255 (1 files in 1 dirs): Update list of obsolete config variables. | 06:30 |
| Github | mantisbt: master David Hicks * 596097f (3 files in 3 dirs): Issue #12253: Implement management page to view workflow graph ... | 06:30 |
| Github | mantisbt: master David Hicks * b6a2721 (3 files in 2 dirs): Fix #11758: Improve handling of reassign on feedback feature ... | 06:30 |
| Github | mantisbt: master David Hicks * 203f17e (1 files in 1 dirs): Fix #11758: Improve handling of reassign on feedback (bug_update) ... | 06:30 |
| Github | mantisbt: master David Hicks * 95ac1e0 (2 files in 1 dirs): Fix #12205: Disable reassign on feedback when the handler replies ... | 06:30 |
| Github | mantisbt: master commits bec9fe8...95ac1e0 - http://bit.ly/d3tjgu | 06:30 |
| paulr | lo | 09:02 |
| paulr | dhx_m:lo | 10:19 |
| paulr | nuclear_eclipse / dhx_m: either of you up yet? | 11:13 |
| giallu | nuclear_eclipse, dhx_m: re conflicts. I think bugzilla handles them quite nicely. can't we study how do they do it and replicate the method in PHP? | 13:12 |
| * giallu hates development discussions are not happening in the development discussion mailing list but in the "mantishelp" channel | 13:13 | |
| paulr | afternoon giallu | 13:33 |
| paulr | how old's your kid now? | 13:34 |
| giallu | paulr, hi :) I've 2 actually. older is 5 other turns 3 in Nov | 15:18 |
| istvanb_ | hi there | 17:32 |
| istvanb_ | I have asked many times where is the plugin documentation for mantis, but I always forgot to save it to the favorites. Can u point it again (last time, I promise:) | 17:33 |
| nuclear_eclipse | http://docs.mantisbt.org/en/master/ | 17:34 |
| nuclear_eclipse | http://docs.mantisbt.org/master/en/developers/ | 17:34 |
| istvanb_ | thanks man:) | 17:34 |
| istvanb_ | so I'd like to create a page with some textfields, an enum and a button. What do you guys use to do this? Because edit the whole page in a text editor looks a little bit akwaard | 17:35 |
| paulr | hey john | 17:36 |
| nuclear_eclipse | istvanb_: check http://git.mantisforge.org for examples of other plugins | 17:36 |
| nuclear_eclipse | hi paulr | 17:36 |
| paulr | i'm feeling a moment of boredom | 17:37 |
| paulr | :) | 17:37 |
| istvanb_ | I have a lots of plugins, but they are very complicated for me. I have absolutely no knowledge of php at all. So I just try to figure out the things:) But its still a question how u guys set up the html part of your page | 17:38 |
| paulr | <paulr> nuclear_eclipse / dhx_m: either of you up yet? | 17:40 |
| paulr | that reminds me | 17:40 |
| paulr | do you know where the icons in mantis atm come from | 17:40 |
| paulr | ? | 17:40 |
| paulr | and should we use png over gif? | 17:40 |
| nuclear_eclipse | png is much better than gif, but I have no clue where the icons are from | 17:43 |
| paulr | http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=bd8d1ec329ee7bbe6aff9222c7ceba738c0dc138 | 17:45 |
| paulr | I'm wondering more any more about license thing btw :P | 17:45 |
| CIA-103 | Mantisbt: paul * r629a6760104e / (config_defaults_inc.php core/graphviz_api.php): Fix: #5037 | 18:20 |
| CIA-103 | Mantisbt: paul * re7ee768d97e0 /config_defaults_inc.php: Fix $t_path on windows | 18:20 |
| istvanb_ | I'd like to display all user groups in a multiple selection box. I use <?php print_user_option_list ( 'access_levels') ?>; | 18:28 |
| istvanb_ | which displays the users, not the groups | 18:29 |
| istvanb_ | which one should I use? | 18:29 |
| istvanb_ | project_access_level_option_list | 18:46 |
| CIA-103 | Mantisbt: paul * r1289ac3562ff /core/graphviz_api.php: Update comments in graphviz API | 19:27 |
| Github | mantisbt: master Paul * e7ee768 (1 files in 1 dirs): Fix $t_path on windows | 22:30 |
| Github | mantisbt: master Paul * 629a676 (2 files in 2 dirs): Fix: #5037 ... | 22:30 |
| Github | mantisbt: master Paul * 1289ac3 (1 files in 1 dirs): Update comments in graphviz API | 22:30 |
| Github | mantisbt: master commits 95ac1e0...1289ac3 - http://bit.ly/dx9TIs | 22:30 |
Generated by irclog2html.py