| ../irclogs/#mantishelp.2009-04-13.log | ||
| --- scribe started --- | 00:00 | |
| CIA-11 | Mantisbt: daryn * r4e629fc69443 / (3 files in 3 dirs): =Implement bug 4723, display issues I've added notes to in a my view box | 01:55 |
|---|---|---|
| mantisbot | Bug 4723 - kgrubbs - fixed - resolved | 01:55 |
| mantisbot | Add new capability to "My View".... "Issues I've added Notes To" - http://www.mantisbt.org/bugs/view.php?id=4723 | 01:55 |
| CIA-11 | Mantisbt: vboctor * ra6773fcd3fe5 / (7 files in 3 dirs): Fixed #9102: webservice api call causes SYSTEM NOTICEs \nAdded unit tests for SOAP API. | 01:56 |
| dhx_m | ohhh changes :) | 02:27 |
| dhx_m | AHHH sourceintegration (websvn) just got stuck in an infinite loop of importing the same changeset.... 20,000+ times! | 03:37 |
| dhx_m | this could be bad for the server | 03:38 |
| nuclear_eclipse | dhx_m: I'm going to bed now, I'll investigate that tomorrow at work, probably a side effect of a recent "feature" (issue #14)- if you revert to commit fc0c7b, you should be fine | 03:41 |
| dhx_m | ok thanks :) I'll check it out | 03:41 |
| dhx_m | crisis averted as well... by renaming the svn trunk directory while the import was in progress ;) | 03:41 |
| nuclear_eclipse | cheers | 03:42 |
| CIA-11 | Mantisbt: vboctor * rffff385dacfc / (api/soap/mc_issue_api.php tests/soap/IssueUpdateTest.php): Fixed #9102: webservice api call causes SYSTEM NOTICEs --- fixed for mc_issue_update(). | 03:48 |
| mantisbot | New bug: Bug 10322 - vboctor - open - new | 03:59 |
| mantisbot | New bug: Html markup is not handled correctly by the soap APIs - http://www.mantisbt.org/bugs/view.php?id=10322 | 03:59 |
| mantisbot | New bug: Bug 10323 - vboctor - open - new | 04:04 |
| mantisbot | New bug: mc_issue_update() will set optional fields to default values rather than leave them with current values - http://www.mantisbt.org/bugs/view.php?id=10323 | 04:04 |
| CIA-11 | Mantisbt: vboctor * r974883d711bc / (api/soap/mc_issue_api.php tests/soap/IssueUpdateTest.php): Fixed #9472: Issues updating duplicates notes. | 04:35 |
| CIA-11 | Mantisbt: vboctor * ra5f7dbcd540c / (bug_report.php core/bug_api.php tests/soap/IssueAddTest.php): Fixes #9132: mc_issue_add does not set values for all submitted fields. | 05:30 |
| vboctor | nuclear_eclipse, are you there? | 05:38 |
| vboctor | bug update advanced is broken by the following checkin: | 05:38 |
| vboctor | http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=c0d04c65c53f004f5f37364b80559a83243e54cf | 05:38 |
| vboctor | You have defined $t_show_profiles and checked for $t_show_platform. | 05:39 |
| dhx_m | vboctor: he is sleeping I think :) | 05:45 |
| dhx_m | oddly enough, I can't reproduce it... | 05:46 |
| dhx_m | the profile fields are missing, as expected | 05:46 |
| vboctor | dhx_m, it depends on your error reporting settings. | 05:58 |
| vboctor | I think he mis-named the configuration option and the variable. | 05:59 |
| dhx_m | I have PHP errors on... or is there another level of verbosity? | 06:17 |
| dhx_m | and I have profiles disabled... and those fields don't show on the advanced update | 06:17 |
| dhx_m | unless the if() turns into more of an "ifdef", and it is ignored | 06:18 |
| CIA-11 | Mantisbt: vboctor * reeb012b41654 / (3 files in 2 dirs): Better handling for attempts to add blank notes, issue notes unit tests, test for mc_issue_exists(). | 07:24 |
| mantisbot | New bug: Bug 10324 - rolfkleef - open - new | 11:16 |
| mantisbot | New bug: Add filter options "Next target version" and "Last released version" - http://www.mantisbt.org/bugs/view.php?id=10324 | 11:16 |
| mantisbot | New bug: Bug 10325 - thraxisp - open - assigned | 11:16 |
| mantisbot | New bug: Move should have the option of changing categories - http://www.mantisbt.org/bugs/view.php?id=10325 | 11:17 |
| mantisbot | New bug: Bug 10326 - prabhurangan - open - new | 11:52 |
| mantisbot | New bug: Facing issues with changelog feature in LINUX(FC10)? - http://www.mantisbt.org/bugs/view.php?id=10326 | 11:52 |
| nuclear_eclipse | morning all | 12:25 |
| dhx_m | hey | 12:34 |
| nuclear_eclipse | dhx_m: was it import or checkin that you were having issues with last night? | 12:39 |
| nuclear_eclipse | nevermind, it only loops on import :P | 12:42 |
| * nuclear_eclipse hasn't had is caffeine yet... | 12:42 | |
| nuclear_eclipse | dhx_m: hmm, I'm not replicating the infinite loop on my system | 12:47 |
| nuclear_eclipse | it completes correctly when a) there are changesets to import, and b) when there are no changesets to import... | 12:48 |
| dhx_m | nuclear_eclipse: import all (initial import) | 12:54 |
| dhx_m | hmm I was up again an old version of subversion... | 12:54 |
| dhx_m | as I see it, it keeps looping until the number of changesets returned is < 1 | 12:54 |
| nuclear_eclipse | right, and the websvn plugin should return 0 objects when it gets to the end of the revision history, unless older versions of `svn log` don't error out on unknown revs like 1.4.4? | 12:56 |
| nuclear_eclipse | in this case, "older" to me being older than the 1.4.4 binaries on my workstation =\ | 12:57 |
| dhx_m | but this wasn't specifying a revision range | 12:57 |
| nuclear_eclipse | well, I'm talking about how the WebSVN plugin actually handles imports | 12:58 |
| nuclear_eclipse | it makes a call to `svn log -v -r XXX:HEAD --limit 200` and then parses the output | 12:58 |
| dhx_m | import_full: $t_svnlog = explode( "\n", `$svn log -v $t_url` ); | 12:58 |
| dhx_m | no revision range specified for the initial import | 12:58 |
| dhx_m | import_latest seems to be ok | 12:59 |
| nuclear_eclipse | oh, I see | 12:59 |
| dhx_m | and thanks for making me look at that again | 12:59 |
| nuclear_eclipse | I missed the fact that import_full didn't spec a rev range | 12:59 |
| * nuclear_eclipse kicks himself | 12:59 | |
| dhx_m | I realise how it checks the revision range now :) | 12:59 |
| nuclear_eclipse | this is the problems found when primary development is done against Git plugins, and then ported to the SVN plugins :P | 13:00 |
| nuclear_eclipse | I forgot that I had implemented import types differently in SVN, while the Git plugins use the same logic for both full and latest imports | 13:01 |
| dhx_m | I'm not using SVN by choice :p | 13:01 |
| nuclear_eclipse | same here, and I'm also not using SCCS by choice.... | 13:01 |
| dhx_m | also, won't you hit the script execution time limit with very large repos? | 13:01 |
| nuclear_eclipse | right, that's the purpose of helper_begin_long_process(), it extends the execution time (assuming safe_mode is off) | 13:02 |
| dhx_m | nice :) | 13:03 |
| nuclear_eclipse | dhx_m: I just pushed a fix for the SVN problem | 13:05 |
| dhx_m | thanks, I'll try it out | 13:05 |
| nuclear_eclipse | this just proves to me that I was right for holding off an "official" release with all the new features I added over the past week :P | 13:06 |
| dhx_m | with ticket #17, it looks like it'd be nice to have the ability to setup regex matches per repo... rather than globally | 13:11 |
| dhx_m | so you don't get incorrect linking of change sets | 13:11 |
| dhx_m | wait that's odd | 13:12 |
| dhx_m | you must have just used the wrong bug number I guess | 13:12 |
| nuclear_eclipse | ? | 13:12 |
| nuclear_eclipse | oh, you mean the "3d games" changesets? | 13:13 |
| nuclear_eclipse | those are an artifact of having imported those repositories into a different tracker than they were originally developed against =\ | 13:14 |
| dhx_m | ah I see :) | 13:15 |
| dhx_m | easily fixed by running some manual SQL queries to remove those links I guess | 13:15 |
| nuclear_eclipse | probably, or I could just be lazy and leave them there :P | 13:16 |
| dhx_m | :) | 13:16 |
| nuclear_eclipse | they run out around #20ish IIRC | 13:16 |
| dhx_m | well it isn't really a problem then :) | 13:16 |
| dhx_m | I take it the source repository is checked for matching entries for newly reported bugs? | 13:17 |
| nuclear_eclipse | no, it just creates the links in the database without making sure the bug actually exists or not :P | 13:17 |
| nuclear_eclipse | that should probably be considered yet another "bug"; I just haven't found it enough of a problem to take time to fix it, even though it's probably a dirt easy fix | 13:18 |
| dhx_m | yep | 13:20 |
| dhx_m | well I think I prefer it the way it is now | 13:20 |
| dhx_m | so you can commit something, then file a bug 5 minutes later | 13:20 |
| mantisbot | Bug 5 - prescience - fixed - closed | 13:20 |
| mantisbot | Need show Next/Prev XYZ bugs - http://www.mantisbt.org/bugs/view.php?id=5 | 13:20 |
| nuclear_eclipse | hehe | 13:20 |
| * nuclear_eclipse kicks mantisbot | 13:20 | |
| dhx_m | that was really strange | 13:21 |
| nuclear_eclipse | exactly | 13:21 |
| nuclear_eclipse | the bug hasn't been touched in 9 years... | 13:21 |
| dhx_m | it predates Mantis tracking bug history | 13:21 |
| nuclear_eclipse | hehe | 13:21 |
| * nuclear_eclipse is working on your timecard contribution | 13:23 | |
| nuclear_eclipse | dhx_m: do you use *nix or Windows? | 13:24 |
| nuclear_eclipse | and also, do you git command line, or a gui? | 13:24 |
| dhx_m | nuclear_eclipse: Gentoo Linux | 13:26 |
| dhx_m | nuclear_eclipse: git command line | 13:27 |
| nuclear_eclipse | ok | 13:27 |
| nuclear_eclipse | one random thing I get absurdly picky about for no good reason is trailing whitespace; it bugs my inner OCD :P | 13:27 |
| dhx_m | oh, did I have some? :o | 13:28 |
| nuclear_eclipse | but if you configure git to use colors when diffing, it makes it glaringly obvious (probably another reason I OCD on it)... | 13:28 |
| nuclear_eclipse | I'll take care of it via `git commit --amend` which I'd do to signoff anyways, but I just thought I'd let you know | 13:29 |
| nuclear_eclipse | ok, I pushed your changes; thanks again :) | 13:32 |
| dhx_m | no probs, thanks | 13:32 |
| dhx_m | I think the white space problem | 13:32 |
| dhx_m | is because I haven't setup options for that repo | 13:33 |
| dhx_m | I'll see if I can make them global | 13:33 |
| nuclear_eclipse | if you do `git config --global`, you can set your color prefs there, and then it always shows up | 13:33 |
| dhx_m | yep | 13:34 |
| nuclear_eclipse | how would you see #18 being implemented? | 13:34 |
| dhx_m | that's a good question | 13:34 |
| nuclear_eclipse | :) | 13:34 |
| nuclear_eclipse | :) | 13:34 |
| dhx_m | I'm not sure if it makes sense to let all users configure it on their own | 13:35 |
| dhx_m | maybe just add a threshold level for it | 13:35 |
| nuclear_eclipse | yeah, that's one of the reasons I haven't yet done anything like that... =\ | 13:35 |
| dhx_m | so developers/admins can do that | 13:35 |
| dhx_m | but then you'd also need a configuration page where admins can override on a per-user basis | 13:35 |
| nuclear_eclipse | I wonder... | 13:36 |
| dhx_m | manage_user_edit_page.php | 13:36 |
| dhx_m | and | 13:36 |
| dhx_m | account_page.php | 13:36 |
| nuclear_eclipse | I recently added plugin events for the user's account prefs page | 13:36 |
| dhx_m | those 2 places probably | 13:36 |
| nuclear_eclipse | I wonder if I set it so that the user's commit name could be set only if a) the user exceeded a certain threshold, or b) an admin was setting someone *else's* ... | 13:38 |
| dhx_m | I just added a note to that effect :) | 13:39 |
| dhx_m | all we need is one threshold | 13:39 |
| dhx_m | and then we only show it on the user page if the user is above that threshold | 13:39 |
| nuclear_eclipse | I'd of course then also need to create space on the source-integration config page to set the user threshold... | 13:39 |
| dhx_m | yep | 13:39 |
| nuclear_eclipse | hmm... | 13:39 |
| dhx_m | also the "Update Threshold"... does that let people manually import the latest revisions? | 13:40 |
| nuclear_eclipse | the good news is that with my recent extraction of mapping commits to users, it's far more prudent to implement now than it was a couple weeks ago... | 13:40 |
| dhx_m | or just attach changesets to tickets? | 13:40 |
| nuclear_eclipse | good question :P | 13:40 |
| dhx_m | I couldn't find a button to that effect for users who have "update" permissions | 13:41 |
| * nuclear_eclipse looks into the code | 13:41 | |
| dhx_m | as the button only appears when you click "Manage" next to a repo | 13:41 |
| nuclear_eclipse | oh, update_threshold is used for a) attaching and detaching commits to issues, and b) for the optional porting status feature | 13:44 |
| dhx_m | ok :) | 13:45 |
| dhx_m | I did have some wording suggestions that I'll make later | 13:45 |
| dhx_m | for this + Timecard | 13:45 |
| dhx_m | just to make things easier to understand | 13:45 |
| nuclear_eclipse | porting status being a feature my employer uses to help keep track of fixes that have/haven't been ported to older branches, etc | 13:45 |
| nuclear_eclipse | esp considering there are times where fixes need to get ported back to three or more legacy versions that are still in active use around the globe... | 13:46 |
| dhx_m | so it tracks merges? | 13:48 |
| dhx_m | or is it more general... and just based on a commit message saying "ported" | 13:48 |
| nuclear_eclipse | well, not directly; it requires developers to explicitly update commits to say what branch they ported the fix to | 13:48 |
| dhx_m | cool, I should try that out :) | 13:49 |
| dhx_m | do you then define what branches you have? | 13:49 |
| nuclear_eclipse | we still use a set of Perl scripts on top of SCCS for our primary project... (ugh) | 13:49 |
| dhx_m | oh :o | 13:50 |
| dhx_m | I really like git now that I've started using it | 13:50 |
| nuclear_eclipse | so anyways, the porting status feature just lets you specify whether a commit a) doesn't need to be ported, or b) what branch it was ported to by selecting from a list of all branches available | 13:50 |
| dhx_m | never liked SVN, and haven't really used much else | 13:51 |
| dhx_m | cool | 13:51 |
| nuclear_eclipse | I used to use SVN for everything until I found out about Git, now I use Git for everything :) | 13:51 |
| nuclear_eclipse | and with SCCS, "branches" are only a concept manifested in our miriad of perl scripts.... | 13:52 |
| nuclear_eclipse | otherwise, SCCS barely handles revision control for a single file, let alone an entire source repository | 13:52 |
| dhx_m | sounds like someone set your system up with their CVS knowledge | 13:52 |
| dhx_m | those sort of scripts were apparently very common in the CVS days | 13:53 |
| nuclear_eclipse | but we can't switch to anything newer, because "then we can't grep through the revision history files"..... | 13:53 |
| dhx_m | or else you'd need to type 15 commands to commit a patch :p | 13:53 |
| dhx_m | or some other hideously stupid thing like that | 13:53 |
| dhx_m | commit messages are stored in separate files, not in your SVN repo? | 13:54 |
| nuclear_eclipse | no, I don't think you're understanding; we use SCCS, from the 70's, not SVN | 13:54 |
| dhx_m | oh I see | 13:55 |
| dhx_m | that makes sense now | 13:55 |
| nuclear_eclipse | eg, it was *the* first source control system ever created | 13:55 |
| dhx_m | I suppose you could port all your history to git | 13:55 |
| dhx_m | even in an ugly way... walk through the history and commit each change one by one to the git repo | 13:56 |
| dhx_m | and then update your system clock in between (if git doesn't have a timestamp override... I'm sure it does though) :) | 13:56 |
| nuclear_eclipse | well, it's a matter of our senior development staff refuses to learn anything new, because SCCS works "perfectly well" | 13:56 |
| dhx_m | must be a headache for others to use | 13:56 |
| nuclear_eclipse | indeed | 13:56 |
| dhx_m | I suppose there wouldn't be too many branches that get merged | 13:57 |
| dhx_m | because it'd be so hard to do so? | 13:57 |
| nuclear_eclipse | ha, you wish | 13:57 |
| nuclear_eclipse | for generaly bug fixes, there's generally about 3-7 "branches" that the fix has to be ported to... | 13:57 |
| dhx_m | ouch | 13:58 |
| nuclear_eclipse | other departments use SVN though, and one is looking to switch to Mercurial, which was the major reason I created the generalized source-integration framework, rather than hardcoding everything like the previous system that Mantis will be replacing | 13:59 |
| dhx_m | the new framework you've created is excellent | 13:59 |
| dhx_m | you've done a great job making it modular | 13:59 |
| dhx_m | that is exactly how good software is written :) | 13:59 |
| nuclear_eclipse | I try :) | 14:00 |
| dhx_m | will there be plans to rip out the old cruft from Mantis once this plugin 'takes off'? | 14:00 |
| dhx_m | and is this the sort of thing that may become officially "managed" by the project? | 14:00 |
| nuclear_eclipse | probably not for at least another full release cycle at the shortest | 14:00 |
| dhx_m | ie. bugs reported to the official Mantis tracker, the plugin is bundled, etc | 14:01 |
| nuclear_eclipse | eg, need to maintain some sort of legacy compatibility for the time being | 14:01 |
| dhx_m | yep | 14:02 |
| nuclear_eclipse | we have given consideration to maintaining a second set of releases containg popular/useful plugins out of the box | 14:02 |
| dhx_m | and I suppose it'd need an upgrade path | 14:02 |
| nuclear_eclipse | well, I don't think there's any real way to provide an upgrade path for any existing notes-based source integration | 14:02 |
| dhx_m | ah, probably not then | 14:03 |
| dhx_m | I haven't used it before, so didn't know it was based on notes (UGH!) | 14:03 |
| nuclear_eclipse | or at least, nothing more than "install and set up this plugin" | 14:03 |
| dhx_m | yep | 14:03 |
| nuclear_eclipse | yeah, that's the biggest reason I didn't like the old style integration | 14:03 |
| dhx_m | well I was thinking more in terms of if good plugins become managed by the project | 14:03 |
| dhx_m | it means they get to use the existing infrastructure (bug tracker, release cycle, website, etc) | 14:04 |
| nuclear_eclipse | basically, the old "integration" was nothing more than piping a post-commit text payload into checkin.php which just added a note to any linked issues | 14:04 |
| dhx_m | ... more users... more development activity (?)... and if someone gets hit by a bus, it isn't the end of the plugin | 14:04 |
| dhx_m | ugly | 14:04 |
| nuclear_eclipse | well, hopefully by using Git plugins on mantisforge, the bus situation should be "solvable" just by forking the repo, or paulr modifying the maintainer of the primary repo | 14:05 |
| nuclear_eclipse | Git repos* | 14:05 |
| nuclear_eclipse | although I hope the bus situation never happens, because 90% of the repos on mantisforge are mine :P | 14:06 |
| dhx_m | lol | 14:11 |
| dhx_m | it'd be nice to have a Mantis bugtracker for plugins/stuff on mantisforge | 14:11 |
| dhx_m | ie... 1 tracker for everything... official & non-official? | 14:11 |
| nuclear_eclipse | agreed, but paulr basically stopped before getting anything set up... | 14:11 |
| dhx_m | if it was me, I'd struggle to find the time to do that :) | 14:14 |
| nuclear_eclipse | yeah, between work, university, and world of warcraft, I struggle as well :P | 14:15 |
| slestak | i just started playing wow this weekend. i can see how it kills productivity :) | 14:21 |
| dhx_m | haha | 14:21 |
| nuclear_eclipse | I only started playing because a friend of mine runs a private server, so I don't have to pay that horrid monthly fee | 14:22 |
| slestak | my wife and kids do, so its the only way to get "family time" ;) | 14:22 |
| nuclear_eclipse | hehe | 14:22 |
| slestak | personally, id rather be outside on my bike | 14:23 |
| slestak | im usign the soap connector to integrate with deki. the bug links are pointing to the soap uri instead of linking to the mt login page to allow viewing the ticket. is that typical? | 14:24 |
| nuclear_eclipse | not to my knowledge :P | 14:24 |
| slestak | i'll ping over there and see if anyone else is using mc in this fashion. | 14:25 |
| dhx_m | well I'm off for now | 14:35 |
| dhx_m | thanks for the fixes nuclear_eclipse :) | 14:35 |
| dhx_m | cya later | 14:35 |
| nuclear_eclipse | you're welcome | 14:35 |
| nuclear_eclipse | cheers | 14:36 |
| CIA-11 | Mantisbt: s.mazeland * rfd43db318727 /lang/strings_english.txt: I've -> I Have in message | 14:56 |
| paulr_ | moo | 16:33 |
| daryn | hello paulr_ | 16:33 |
| paulr_ | lo | 16:33 |
| paulr_ | did you see mail ? | 16:33 |
| daryn | on dev? | 16:34 |
| paulr_ | to you | 16:34 |
| daryn | hm...don't think so...just a sec | 16:34 |
| paulr_ | aboutabout dates | 16:34 |
| paulr_ | i've sent 3 emails in last 48 hours | 16:34 |
| paulr_ | 2 today | 16:34 |
| daryn | oh yes | 16:34 |
| daryn | i tried to respond on the test db but my mail relay wasn't working at home | 16:35 |
| daryn | anyway. for that one show queries and count were both off | 16:35 |
| paulr_ | really? | 16:35 |
| daryn | yes | 16:35 |
| paulr_ | can you try running the latest version against your test db | 16:36 |
| daryn | sure. | 16:36 |
| daryn | will take me a bit | 16:36 |
| paulr_ | what about the comments on commits today/ | 16:36 |
| daryn | for exceptions? | 16:37 |
| paulr_ | I was more thinking for ETA/status | 16:38 |
| paulr_ | i've not tested yet, but as far as I can tell | 16:38 |
| paulr_ | we've just modified bug_Report.php so I can submit a resolved bug as a normal user | 16:38 |
| daryn | i saw the email but haven't had a chance to look into it at all | 16:38 |
| paulr_ | http://git.mantisforge.org/w/mantisbt.git?a=commitdiff;h=a5f7dbcd540c533546fc80533866d808d4c64f9d | 16:42 |
| * paulr_ doesn't get it | 16:42 | |
| paulr_ | that's a soap bug if anything | 16:43 |
| paulr_ | not a ui bug | 16:43 |
| mornet | hi | 16:45 |
| paulr_ | hi | 16:45 |
| mornet | is there anyone that perhaps have made a custom function to email a seperate person not in the user table | 16:47 |
| mornet | using a custom field that is required to filled in and then to use that email when an issue has been resolved | 16:48 |
| mornet | i have made the changes but I'm not very happy to hard code stuff | 16:48 |
| mornet | this is only required for one project though, that is why have hardcode the project id for now, but it would be nice to have this more dynamic | 16:49 |
| paulr_ | it's not something that core project does | 16:49 |
| * paulr_ is thinking a) custom functions as you've probably done | 16:49 | |
| paulr_ | b) in 1.2.x plugin | 16:49 |
| mornet | nope, not even a custom function, I just added a little piece of code to email_api.php | 16:51 |
| mornet | i thought, actually hope that there would be a plugin in the next release | 16:51 |
| mornet | for functionality like this | 16:52 |
| daryn | paulr_ installation successful | 16:54 |
| daryn | i haven't reduced the memory though so that was at 256M | 16:55 |
| paulr_ | daryn: I *think* you must be calling one of the debug stuff | 17:01 |
| paulr_ | that populates the array of database calls | 17:01 |
| paulr_ | as from what i can tell | 17:01 |
| paulr_ | without that, it's static | 17:01 |
| nuclear_eclipse | hi Victor | 17:02 |
| daryn | well...it worked this time. i'll reduce the memory back down and see if it still works for me. If it doesn't I'll look into that a bit more. If it does...no worries. | 17:02 |
| vb123 | hi nuclear_eclipse | 17:03 |
| vb123 | did you see my message relating to update advanced page broken? | 17:03 |
| nuclear_eclipse | yeah, I was just about to look into that... | 17:04 |
| nuclear_eclipse | I haven't noticed any troubles on my end... | 17:04 |
| vb123 | you defined a config / var for profiles, but attempt to hiden platform with undefined variable. | 17:04 |
| paulr_ | nuclear_eclipse: did you have a look at my note about user preferences? | 17:04 |
| paulr_ | vb123: if you've got any time atm, can you have an initial glance at dates/bugobjects branches | 17:05 |
| nuclear_eclipse | vb123: just looked at the diff you linked, and it's obvious now :P | 17:05 |
| vb123 | paulr_: sorry can't look now. | 17:05 |
| paulr_ | ok | 17:05 |
| vb123 | nuclear_eclipse: yep it is! | 17:05 |
| * paulr_ would like to get dates in sooner rather then later | 17:06 | |
| paulr_ | and both need testing/polishing by me | 17:06 |
| paulr_ | so just want initial opinions | 17:06 |
| vb123 | with the dates one, every use has his/her own timezone. And database uses a single time zone? e.g. UTC? | 17:07 |
| paulr_ | database stores unixtimestamp | 17:07 |
| paulr_ | then we localise | 17:07 |
| paulr_ | that's the plan | 17:07 |
| vb123 | great. | 17:07 |
| vb123 | the unixtimestamp is dependent on the server time zone. | 17:07 |
| vb123 | so we need to know the server timezone and user time zone, to calculate correctly, right? | 17:08 |
| paulr_ | time() states: Unix Epoch (January 1 1970 00:00:00 GMT). | 17:08 |
| nuclear_eclipse | biggest problem we have is that we'll need to convert the db schema for everything from datetime to integer, which is a hefty conversion task | 17:08 |
| paulr_ | nuclear_eclipse: well, seems to work for me ;p | 17:08 |
| paulr_ | I tried it on old mantisbt.org/bugs db | 17:09 |
| nuclear_eclipse | right, I'm just saying that's a large change to the schema, and it's certainly going to tick off aptituz_ and/or debian with their separate system of handling schema changes.... | 17:09 |
| paulr_ | heh | 17:09 |
| nuclear_eclipse | he was already frustrated enough with the category migration tasks | 17:10 |
| paulr_ | well, I don't see how you can avoid that ;/ | 17:10 |
| vb123 | have we talked lately about when 1.2.x will see the light as an rc? | 17:10 |
| nuclear_eclipse | vb123: I think it'd be nice to drop an rc as soon as dates get solidified? | 17:10 |
| paulr_ | vb123: with me off work for the next week and in a coding mood, next weekend would be a good time to see where we are ;p | 17:10 |
| nuclear_eclipse | I was tempted to release 1.1.7 this week as well | 17:11 |
| nuclear_eclipse | in fact, I think I'll make a note on the dev list asking for any final targets for 1.1.7 | 17:11 |
| vb123 | It would be great to identify the issues to focus on. The two branches are really new features. | 17:11 |
| vb123 | I'm focusing on soap, since it was totally broken. | 17:12 |
| paulr_ | they more 'attempt to tidy stuff up' | 17:12 |
| paulr_ | victor: out of interest, do you like the current soap implementation we have atm? | 17:12 |
| vb123 | I like the fact that it is the only one we have now and it needs to be working. However, I have some concerns about it. | 17:13 |
| vb123 | 1. authentication. | 17:13 |
| vb123 | 2. scalability | 17:13 |
| vb123 | 3. incompleteness. | 17:13 |
| paulr_ | i've been hesitant to work on it too much given | 17:14 |
| vb123 | 4. versioning | 17:14 |
| paulr_ | a) not having a proper test setup | 17:14 |
| paulr_ | b) not really knowing what you should/shouldn't do in soap | 17:14 |
| CIA-11 | Mantisbt: jreese * r807d7826148b /bug_update_advanced_page.php: Fix PHP notices with undefined variables due to commit c0d04c65. | 17:14 |
| paulr_ | c) backwards compatibility | 17:14 |
| paulr_ | for example | 17:14 |
| paulr_ | In mantis, you can disable display of mantis version e.g. 1.2.0 - that could be a 'security' feature | 17:15 |
| paulr_ | however, the soap api if turned on exposes it in readonly mode | 17:15 |
| paulr_ | however, we can't turn that off easily as we use that for versioning the scope api | 17:15 |
| paulr_ | ;) | 17:15 |
| vb123 | yes, I'm aware of that. | 17:16 |
| vb123 | I would also change the APIs to throw exceptions that soap APIs can catch and hence remove the duplicate validation in soap. | 17:16 |
| paulr_ | and as we know there's a bunch of similar stuff where we've added config per project/user stuff since the soap api started | 17:16 |
| vb123 | I think that per project config is a bug farm | 17:17 |
| vb123 | This needs a release on its own to fully test / fix across all scenarios. | 17:17 |
| paulr_ | we have 'per-project' config atm | 17:18 |
| paulr_ | just no nice ui | 17:18 |
| vb123 | yep, my point is whether in all the appropriate scenarios we call config_get() with the right parameters. Mainly in cases where we are executing an API for a project / user different than the current one. | 17:18 |
| paulr_ | anyway, soap api is a bit of can of worms ;/ | 17:19 |
| vb123 | the short story is that there is a lot of work in soap, but we need to take it one step at a time. | 17:19 |
| paulr_ | especially if we want to try and maintain some level of compatibility | 17:19 |
| vb123 | automation is critical for it. I used to depend on .NET unit tests that run on top of MC client, but I wanted to move to something which runs directly on top of the PHP web service. | 17:20 |
| paulr_ | anyway, both the date + bugobject branches are reworks of stuff to try to fix existing bugs | 17:20 |
| vb123 | for soap, I avoid breaking compatibility. | 17:20 |
| paulr_ | so in theory once complete, should be drop-in replacements | 17:20 |
| vb123 | however, big re-works / diffs are likely to introduce new bugs. | 17:21 |
| CIA-11 | Mantisbt: jreese * rffbfd85cfbef / (3 files in 2 dirs): Fix #10299: Fixed incorrect or missing HTML colspan attributes. | 17:23 |
| CIA-11 | Mantisbt: jreese master-1.1.x * r185c60dfef52 / (3 files in 2 dirs): Fix #10299: Fixed incorrect or missing HTML colspan attributes. | 17:23 |
| paulr_ | hmm | 17:24 |
| paulr_ | need to setup a instance of mantis as part of build to test soap | 17:24 |
| vb123 | nuclear_eclipse: did you add the new configuration option to the manual? | 17:25 |
| nuclear_eclipse | I didn't realize we were documenting config options in the manual :P | 17:25 |
| nuclear_eclipse | the code is it's own documentation! | 17:25 |
| vb123 | yep, it should be part of the same commit as adding the configuration option :) | 17:25 |
| nuclear_eclipse | ;) | 17:25 |
| paulr_ | vb123: regarding reworks+bugs, I think it depends on how likely we think they are to cause major breakage. atm, we can always do a short beta release to stabalize anything new | 17:27 |
| paulr_ | nuclear_eclipse: any thoughts on where to put the timezone stuff? ;p | 17:28 |
| paulr_ | (Setting | 17:28 |
| nuclear_eclipse | My Account -> Preferences | 17:29 |
| nuclear_eclipse | I'd suggest right under Language | 17:29 |
| paulr_ | i meant, when to hook it in ;p | 17:30 |
| nuclear_eclipse | ? | 17:30 |
| paulr_ | actually first question | 17:30 |
| paulr_ | when I click on 'user prefs reset' here | 17:30 |
| paulr_ | it errors | 17:30 |
| paulr_ | doyou get the same or does it work for you? | 17:31 |
| nuclear_eclipse | it "worked" on my test install, but it puts user prefs in a bad state, ie not any sort of "sane" reset | 17:32 |
| paulr_ | I seem to get: | 17:32 |
| paulr_ | atabase query failed. Error received from database was #1048: Column 'advanced_report' cannot be null for the query: UPDATE mantis_user_pref_table | 17:32 |
| paulr_ | SET default_profile = 0, default_project = 0, advanced_report = NULL, advanced_view = NULL | 17:32 |
| paulr_ | with mysql ;/ | 17:32 |
| nuclear_eclipse | or rather, 'reset prefs' reset them to nothing at all like what the default user prefs are | 17:32 |
| paulr_ | in fact, shouldn't reset pref's just delete the pref_table entry? | 17:33 |
| paulr_ | or is it more | 17:33 |
| nuclear_eclipse | I dunno | 17:33 |
| paulr_ | 'reset prefs for this project' | 17:33 |
| paulr_ | but from what i can tell | 17:33 |
| nuclear_eclipse | well, considering account prefs (AFAIK) is supposed to be project-agnostic, it shouldn't matter what project is selected | 17:33 |
| paulr_ | we use ->Get() to load | 17:33 |
| paulr_ | or well | 17:34 |
| paulr_ | ->Get('default_profile') means | 17:34 |
| paulr_ | load default_profile, if not lookup and return default | 17:34 |
| paulr_ | but then we tend to use ->default_profile | 17:34 |
| paulr_ | to do stuff | 17:34 |
| * paulr_ wants to do same to user_preferences as he did to bugs last thursday ;p | 17:34 | |
| * paulr_ wants feedback on what he did to bugs last thursday ;/ | 17:35 | |
| * nuclear_eclipse has not enough time for reviewing things atm =\ | 17:35 | |
| paulr_ | it's more initial feedback ;p | 17:36 |
| * paulr_ takes dusts off sledgehammer and looks at user_pref_api.php | 17:38 | |
| * daryn_away is away: Gone away for now | 17:40 | |
| vb123 | nuclear_eclipse: for 1.1.7, we should make sure there is a way to turn of validation tokens for users that have trouble with it. This should allow them to continue working while we are troubleshooting the issues. | 18:00 |
| vb123 | that is my 2c worth. | 18:00 |
| nuclear_eclipse | ah, yes, I attached a fix to bug 9999 to implement that, but skay is saying that patch causes troubles with something seemingly unrelated | 18:03 |
| mantisbot | Bug 9999 - arul_k_kumar - open - assigned | 18:03 |
| mantisbot | APPLICATION ERROR #2800 - While submit a new bug - http://www.mantisbt.org/bugs/view.php?id=9999 | 18:03 |
| nuclear_eclipse | I'll try to look into that more to see if it's a side effect of what I did change... | 18:03 |
| vb123 | ok, as long as this is the plan. | 18:03 |
| * nuclear_eclipse apparently forgot to target that for 1.1.7 | 18:05 | |
| CIA-11 | Mantisbt: paul * r047e1535e743 /print_all_bug_page_word.php: Perf: reduce number of lang_get and user_pref_get_pref calls whilst looping around in word reports. | 18:05 |
| * paulr_ pushes more changes | 18:05 | |
| CIA-11 | Mantisbt: paul * ra1e20db97fe5 /print_all_bug_page_word.php: this should be $j not $t_row_count (thanks victor) | 18:05 |
| CIA-11 | Mantisbt: paul * rf6d71ff36607 /bug_report.php: Don't allow gpc to set status in bug_report - this is only for SOAP api. | 18:05 |
| CIA-11 | Mantisbt: paul * rcf155ebc47f1 /core/classes/MantisEnum.class.php: Remove unnecessary loop in MantisEnum (thanks victor) | 18:05 |
| CIA-11 | Mantisbt: paul * r3b921fa98c0a /core/print_api.php: Html Validation: dont print empty span tags | 18:05 |
| CIA-11 | Mantisbt: paul * ra982f75fedef / (changelog_page.php roadmap_page.php): encode version in url. | 18:05 |
| paulr_ | mysql> select * from mantis_user_profile_table where platform = ''; | 18:13 |
| paulr_ | +-----+---------+----------+----+----------+-------------+ | 18:13 |
| paulr_ | | id | user_id | platform | os | os_build | description | | 18:13 |
| paulr_ | +-----+---------+----------+----+----------+-------------+ | 18:13 |
| paulr_ | | 14 | 0 | | | | | | 18:13 |
| paulr_ | | 16 | 0 | | | | | | 18:13 |
| paulr_ | | 17 | 0 | | | | | | 18:13 |
| paulr_ | can't we do an upgrade to delete blank profiles? ;/ | 18:13 |
| CIA-11 | Mantisbt: paul * r4ca787696ee6 /billing_inc.php: HTML Validation | 18:14 |
| CIA-11 | Mantisbt: paul * r8b21ab5870a8 / (6 files): fix invalid html (extra ") and suppress html validation errors for missing alt tags. | 18:14 |
| * daryn is away: Gone away for now | 18:28 | |
| * daryn is back. | 18:34 | |
| paulr_ | daryn: did you try with lower limit? | 18:35 |
| daryn | not yet | 18:35 |
| daryn | just back from lunch | 18:35 |
| CIA-11 | Mantisbt: jreese master-1.1.x * r72235214532b / (config_defaults_inc.php core/form_api.php): Fix #9999: allow form security to be disabled for sites that use 'bad' proxy servers. | 18:45 |
| paulr_ | bad proxy servers? | 18:47 |
| paulr_ | what's this? :) | 18:47 |
| CIA-11 | Mantisbt: jreese * r10040dee7386 / (config_defaults_inc.php core/form_api.php): Fix #9999: allow form security to be disabled for sites that use 'bad' proxy servers. | 18:47 |
| nuclear_eclipse | paulr_: some proxy servers ignore the caching/modified headers that we send, which breaks CSRF protection because the proxy serves stale pages, so this patch allows people to disable the protection to work around terrible proxy servers.... | 18:48 |
| paulr_ | are you sure we are sending the right headers? :) | 18:48 |
| nuclear_eclipse | yes, we've been through this all by now... | 18:49 |
| nuclear_eclipse | proxy servers like Squid obey the headrs appropriately, but some do not | 18:49 |
| * nuclear_eclipse uses a Squid proxy every day | 18:50 | |
| paulr_ | ;) | 18:50 |
| * paulr_ enjoys headers :P | 18:50 | |
| paulr_ | do we know what (broken) proxies users are hitting ? | 18:53 |
| nuclear_eclipse | vb123: do I really need to document a configuration option that shouldn't be touched? :P | 18:54 |
| paulr_ | no | 18:54 |
| nuclear_eclipse | paulr_: I don't know off hand, but everyone that has complained about #2800 errors in 1.1.6+ has said that they are behind a proxy... | 18:54 |
| paulr_ | 1.1.6 issue ? | 18:55 |
| paulr_ | only | 18:55 |
| paulr_ | not 1.2 | 18:55 |
| nuclear_eclipse | well, 1.1.6+ includes 1.2.x ;) | 18:55 |
| nuclear_eclipse | ie, ever since we fixed caching headers for 1.1.6 and 1.2.0a3, the only people still having #2800 errors are behind a proxy, everyone else has had the problem fixed | 18:56 |
| * nuclear_eclipse is off to class | 19:06 | |
| nuclear_eclipse | cheers all | 19:06 |
| * daryn_away is away: Gone away for now | 19:33 | |
| * daryn_away is away: Gone away for now | 19:33 | |
| * daryn_ is back. | 20:11 | |
| * paulr_ strokes daryn_ | 20:12 | |
| daryn_ | uhm... | 20:12 |
| paulr_ | did you get a chance retest with low memory? | 20:13 |
| * paulr_ goes back to game of dota - cya in 45 minutes :) | 20:13 | |
| daryn_ | not yet. i reloaded database and reset memory but had a meeting...now to rerun | 20:13 |
| paulr_ | right | 20:47 |
| daryn_ | paulr_ the upgrade completed successfully with 64M memory. Took awhile though. I have NOT checked that the dates are accurate. | 21:07 |
| paulr_ | cool it works :) | 21:09 |
| paulr_ | at some point could you check whether one bug's dates are | 21:09 |
| paulr_ | and try changing date | 21:10 |
| paulr_ | :) | 21:10 |
| paulr_ | hmmm | 21:41 |
| paulr_ | nuclear_eclipse: i dont get 9998 | 21:41 |
| daryn | paulr_ the dates seem to be ok. are they currently ignoring time zones? | 21:49 |
| paulr_ | yes/no | 21:50 |
| paulr_ | if you go to user preferences | 21:50 |
| paulr_ | my account -> preferneces and change timezone | 21:50 |
| daryn | my time zone was set weird...so i changed it | 21:50 |
| daryn | but it didn't change what is displayed in the bug | 21:50 |
| paulr_ | set weird? | 21:51 |
| daryn | wrong | 21:51 |
| daryn | i don't remember setting it at all | 21:51 |
| paulr_ | it's "set" to what server is | 21:51 |
| daryn | i think it just had the first item selected | 21:51 |
| daryn | no...it wsa something in africa | 21:51 |
| paulr_ | ahh | 21:51 |
| daryn | which the server is definitely not set to | 21:51 |
| paulr_ | if you change what timezone you have and save | 21:51 |
| paulr_ | for me it was updating | 21:51 |
| paulr_ | (but at the same time, not quite worked out where | 21:52 |
| paulr_ | also | 21:52 |
| paulr_ | did you update to my ltest copy of branch right? | 21:52 |
| daryn | yes | 21:52 |
| daryn | when we were discussing earlier | 21:52 |
| paulr_ | @@ -150,6 +150,7 @@ function user_pref_cache_row( $p_user_id, $p_project_id = ALL_PROJECTS, $p_trigg | 21:52 |
| paulr_ | $g_cache_user_pref[$p_user_id][$p_project_id] = $row; | 21:52 |
| paulr_ | + date_default_timezone_set( $row['timezone'] ); | 21:52 |
| paulr_ | return $row; | 21:52 |
| paulr_ | } | 21:52 |
| paulr_ | atm, i just randomnly set timezone when it laodsd userpref's | 21:53 |
| daryn | randomly? | 21:53 |
| paulr_ | in a random place | 21:53 |
| paulr_ | as opposed to a random value | 21:53 |
| daryn | what about date custom fields? | 21:53 |
| paulr_ | but when i was changing what i had under preferences | 21:53 |
| paulr_ | top of screen that shows date | 21:54 |
| paulr_ | was immediately showing different timezone | 21:54 |
| * paulr_ hadnot thought about date custom fields | 21:54 | |
| daryn | so...top of screen shows correctly now...i don't recall whether it was correct timezone or not before. The time/date was correct | 21:55 |
| daryn | actually...i can figure that out. just a sec | 21:55 |
| paulr_ | so whatever top of screen says | 21:55 |
| paulr_ | should be timezone you are now in | 21:55 |
| paulr_ | I dont like preferences api atm | 21:55 |
| * paulr_ wants to bugobjects it ;p | 21:55 | |
| paulr_ | as from what I can tell | 21:55 |
| paulr_ | its broken ;/ | 21:55 |
| nuclear_eclipse | paulr_: what don't you "get" about bug 9998? | 21:56 |
| mantisbot | Bug 9998 - jburt - open - feedback | 21:56 |
| mantisbot | Export functions generate bad URL - http://www.mantisbt.org/bugs/view.php?id=9998 | 21:56 |
| paulr_ | it only breaks with projects with spaces in? | 21:57 |
| Wepl | hi, is it possible to change the config so that reporters can close their own issues? | 21:58 |
| paulr_ | nuclear_eclipse: would you agree preferences are 'broken'? | 21:58 |
| nuclear_eclipse | paulr_: it's not the spaces that break 9998, it's the change in caching headers, and IE being retarded/braindead | 21:59 |
| paulr_ | why doesn't it happen to me then | 21:59 |
| paulr_ | or is it only ie6? | 21:59 |
| nuclear_eclipse | it's only IE6 | 22:00 |
| nuclear_eclipse | eg, IE6 is too dumb, and when you choose "Open With", it will delete the file before the app gets a chance to read it | 22:01 |
| paulr_ | right | 22:02 |
| paulr_ | anyway | 22:02 |
| paulr_ | userpreferences | 22:02 |
| paulr_ | reset is broken yes/ | 22:02 |
| paulr_ | did you get a chance to look at where I was going with bug api branch ? | 22:02 |
| paulr_ | can I do similar to user prefs :) | 22:02 |
| nuclear_eclipse | I haven't looked, no | 22:03 |
| paulr_ | could you have a quick scan of bug api? ;p | 22:03 |
| paulr_ | before I do the same to preferences | 22:03 |
| nuclear_eclipse | I'm still in the "I have part of a term paper due" mode... | 22:04 |
| paulr_ | ahh | 22:04 |
| daryn | paulr_ it takes a very long time to run this upgrade | 22:09 |
| Wepl | by | 22:09 |
| paulr_ | daryn: sure | 22:10 |
| paulr_ | that's not really that surprising | 22:10 |
| paulr_ | although could probably speed it up | 22:11 |
| paulr_ | by changing it to do >1 column at a time | 22:11 |
| daryn | so i don't have time zone set in my preferences but it is showing correctly at the top of the page | 22:11 |
| paulr_ | e..g it'll do bug_table twice | 22:11 |
| paulr_ | once for bug_submitted / row | 22:11 |
| paulr_ | + once for last_update / row | 22:11 |
| paulr_ | all of those could get merged into 1 | 22:11 |
| paulr_ | daryn: it should be pulling server timezone | 22:12 |
| paulr_ | so now if you change to say london | 22:12 |
| daryn | good. i just wasn't sure and wanted to recheck | 22:12 |
| paulr_ | do we want to try to speed up the upgrade | 22:12 |
| daryn | probably. i tend to have a much longer script run time allowed than most will. | 22:13 |
| daryn | i have to run. i may be on after a bit | 22:13 |
| paulr_ | well, install.php calls @set_time_limit( 0 ); | 22:13 |
| paulr_ | which basically means we should check if users are running safemode ;p | 22:14 |
Generated by irclog2html.py