| ../irclogs/#mantishelp.2009-06-01.log | ||
| --- scribe started --- | 00:00 | |
| GuillermoRamirez | hello | 06:15 |
|---|---|---|
| MaximB | hi people | 06:15 |
| MaximB | I REALLY need your help please3 | 06:16 |
| GuillermoRamirez | I am a new user | 06:16 |
| MaximB | I've installed latest stable mantis , when I go to the /mantis/admin/install.php page it goes fast , but when I go to the login page it's really slow and unworkable , I even disabled SSL but it's still slow - where can be the problem ? | 06:17 |
| GuillermoRamirez | I need help | 06:20 |
| GuillermoRamirez | how can I create a roadmap | 06:20 |
| MaximB | do you ever help in this channel ? | 07:07 |
| GuillermoRamirez | hello | 07:44 |
| nuclear_eclipse | morning all | 12:30 |
| [KK]Kirill | nuclear_eclipse: lo | 12:35 |
| portej05 | hi | 12:54 |
| [KK]Kirill | portej05: lo | 12:57 |
| portej05 | hi, I've got a question about mantis, but I'm not an administrator nor do I have access to the configuration of the current setup | 12:59 |
| portej05 | We're running mantis 1.0.5 (fairly old) | 12:59 |
| portej05 | Thing is, it's sending out emails for everything, except account activation | 12:59 |
| [KK]Kirill | sorry, I forgot this version | 12:59 |
| nuclear_eclipse | portej05: my only recommendation is to upgrade to 1.1.7 (latest stable), which should not only fix that, but also fixes many security issues that were present in 1.0 and early 1.1 | 13:04 |
| portej05 | Cheers nuclear, I'll pass that on | 13:05 |
| portej05 | Is the upgrade process relatively painless? | 13:06 |
| nuclear_eclipse | assuming you don't have any modifications to the code (only changes to custom_* and config_inc), then it should be as simple as extracting the new code over top the old, and visiting /admin/install.php to run the upgrade procedure | 13:07 |
| portej05 | Thanks! | 13:09 |
| * daryn_away is away: Gone away for now | 14:39 | |
| * daryn_away is away: Gone away for now | 14:39 | |
| * daryn_away is away: Gone away for now | 14:39 | |
| * daryn_away is away: Gone away for now | 14:48 | |
| * daryn_away is away: Gone away for now | 14:57 | |
| nuclear_eclipse | paul_: you about? | 15:29 |
| paul_ | nuclear_eclipse: lo | 17:48 |
| paul_ | nuclear_eclipse: what have i broken? ;/ | 17:48 |
| nuclear_eclipse | nothing, wanted you to review some stuff for 1.2 so we can get a release out by the weekend | 17:53 |
| mantisbot | New bug: Bug 10548 - irwansun - open - new | 17:54 |
| mantisbot | New bug: reporter only able to choose 2 severity and 1 reproducibility when reporting an issue - http://www.mantisbt.org/bugs/view.php?id=10548 | 17:54 |
| paul_ | nuclear_eclipse: sure | 17:54 |
| paul_ | you dont want to know what i'm working on | 17:54 |
| nuclear_eclipse | as usual | 17:54 |
| paul_ | anyway what you wanted me to look at? | 17:55 |
| nuclear_eclipse | just a sec | 17:56 |
| paul_ | also seepm | 18:04 |
| * daryn_away is away: Gone away for now | 18:08 | |
| nuclear_eclipse | paul_: http://git.mantisforge.org/w/mantisbt/jreese.git?a=shortlog;h=refs/heads/http abstracts http caching headers into a separate API for use by plugins -- just verify that caching still works correctly on your end after the change | 18:15 |
| nuclear_eclipse | http://git.mantisforge.org/w/mantisbt/jreese.git?a=shortlog;h=refs/heads/project-names changes the way project/category names are displayed in a bug and on the my view page -- hopefully to fix the complaints by users and my employer that you can't tell what project a bug is from anymore, now that categories don't always share the same project as they bug they're attached to | 18:16 |
| nuclear_eclipse | http://git.mantisforge.org/w/mantisbt/jreese.git?a=shortlog;h=refs/heads/plugin-uses may not be testable by you, but it adds the ability to specify "soft" dependencies between plugins, which won't prevent install/usage if the soft dependency is missing, but handles correct init order if it is there | 18:18 |
| paul_ | how would plugins use it? | 18:28 |
| nuclear_eclipse | by setting a ->uses property in the same method as it for ->requires | 18:28 |
| paul_ | but your calling http_all_headers from core.php? | 18:29 |
| nuclear_eclipse | oh, soryr | 18:29 |
| nuclear_eclipse | was thinking of the last branch | 18:29 |
| nuclear_eclipse | for headers | 18:30 |
| paul_ | I half dislike the concept of adding an api called http for sending headers though ;/ | 18:30 |
| nuclear_eclipse | core.php calls http_all_headers by default, and then a plugin page can optionally call http_caching_headers() to replace/override the default header data | 18:30 |
| nuclear_eclipse | and I used http_api because headers are part of the HTTP spec, and didn't really seem to fit elsewhere, and I felt that a header_api was too specific/limiting | 18:31 |
| paul_ | i'm just thinking what we'd call a http client api | 18:31 |
| paul_ | I think i probably agree to changing custom_headers to _global | 18:34 |
| paul_ | although, we should update config api to reflect that change | 18:34 |
| nuclear_eclipse | hmm? | 18:34 |
| paul_ | well, if we can only set it globally, we should flag you can't set it in db | 18:35 |
| nuclear_eclipse | we already do.. | 18:35 |
| paul_ | oh ;/ | 18:35 |
| nuclear_eclipse | :P | 18:35 |
| paul_ | but this should be a null change | 18:37 |
| paul_ | my only thought would be | 18:37 |
| paul_ | do we need 4 functions for this | 18:37 |
| nuclear_eclipse | I think so | 18:37 |
| nuclear_eclipse | eg, if I just want my plugin page to override the caching headers, it shouldn't need to call something that will also reload and reset content-type and other custom headers.... | 18:38 |
| paul_ | ok the caching one fine | 18:39 |
| paul_ | i'm more thinking about: | 18:39 |
| paul_ | +function http_content_headers() { | 18:39 |
| paul_ | + if ( !headers_sent() ) { | 18:39 |
| paul_ | + header( 'Content-type: text/html;charset=utf-8' ); | 18:39 |
| paul_ | + } | 18:39 |
| paul_ | where that's *always* going to get called (by core.php) | 18:39 |
| paul_ | i.e. users/plugins/whatever can't call http_content_headers or it's pointless to call it as it's already called by core.php | 18:40 |
| nuclear_eclipse | well, yes, it seems superfluous atm, but I did that with the thinking that we could eventually use them as a unified way to manually set those types of headers, eg, like for file_download.php or plugin_file.php.... | 18:40 |
| paul_ | personally, I find header() a lot easier to understand (I dont need to grep the source to work out what that does) | 18:41 |
| paul_ | that would be my only thought -> I'd like to get to the point where we've got a documented interface on functions for plugin developers to use | 18:41 |
| nuclear_eclipse | well, I would generally agree; my point was simply that an API for certain things could be useful, eg, always append 'charset=utf-8' to any text/* content-type | 18:42 |
| paul_ | adding effectively null/private functions that just call header() seems a bit silly | 18:42 |
| nuclear_eclipse | paul_: the documented interface is the entire API :P | 18:42 |
| paul_ | other then the fact i'd probably be inclined to set a @private tag against 3 of those functions ( aka custom/content/all) and just leave caching as @public | 18:43 |
| nuclear_eclipse | and I had the idea that http_content_headers() could eventually take a parameter for the type, and do some other processing, like the charset= type of thing | 18:43 |
| paul_ | anyway, it looks fine | 18:43 |
| nuclear_eclipse | but it's just an idea; I'm fine rolling it into the other functions if you prefer | 18:43 |
| paul_ | but personally, i'd feel http_content_headers( 'Content-type: text/html;charset=utf-8'); as more confusing | 18:43 |
| nuclear_eclipse | well, I wasn't meaning *that*.... | 18:44 |
| paul_ | as i'd need to waste 5 minutes working out what http_content_headers does to find it just calls header(); :) | 18:44 |
| nuclear_eclipse | I was meaning http_content_headers( 'text/plain' ) | 18:44 |
| paul_ | anyway, commit it / do whatever as it's a null change | 18:44 |
| paul_ | that's effectively the same :P | 18:44 |
| nuclear_eclipse | and then the API would handle anything appropriate based on the actual content-type, such as adding other appropriate headers, etc | 18:45 |
| paul_ | you'd need to take in content-type as one param, charset as a 2nd param | 18:45 |
| paul_ | as for things like file_upload, its not necessarily going to be utf8 | 18:45 |
| nuclear_eclipse | well, assuming that any text/* type is natuarally going to be utf8, and anything binary is not,.... | 18:45 |
| paul_ | and the point is one's still effectively just calling headers | 18:45 |
| paul_ | the one thnig that patch does | 18:46 |
| paul_ | anyway, it's a null change from what I can tell | 18:47 |
| nuclear_eclipse | ok | 18:47 |
| paul_ | and we've spent way too long discussing it :P | 18:48 |
| nuclear_eclipse | lol | 18:48 |
| paul_ | incidently feel free to add @return null to each function :P | 18:49 |
| * nuclear_eclipse stabs paulr in the eye | 18:49 | |
| paul_ | so we're putting projectname in [ ] before bug id? | 18:51 |
| nuclear_eclipse | I couldn't think of a better place to put it that was obvious when glancing at the bug.... =\ | 18:51 |
| paul_ | but your not normally going to ever see it right? | 18:52 |
| nuclear_eclipse | putting it front of the category name is now ambiguous | 18:52 |
| nuclear_eclipse | right | 18:52 |
| paul_ | as normally current_project will be project bug is in | 18:52 |
| paul_ | (in fact, is that always true?) | 18:52 |
| nuclear_eclipse | you'll only see it if the bug is from a project other than the one you have selected | 18:52 |
| paul_ | the project names thing I think looks ifne too | 18:56 |
| nuclear_eclipse | ok | 18:56 |
| paul_ | be interesting with a long project name + summary name | 18:56 |
| * paul_ is just reading diff's | 18:56 | |
| paul_ | ahh yes | 18:57 |
| paul_ | autoloads | 18:57 |
| paul_ | it's not possible to do late loading of plugin's is it? | 18:58 |
| nuclear_eclipse | no, not if we have eventual plans for pluggable authentication | 18:58 |
| paul_ | well, it would obviously have to be clever :P | 18:58 |
| nuclear_eclipse | what are you thinking about that you would need late loading of plugins? | 18:59 |
| paul_ | if you had 20 plugins regesitered for example | 18:59 |
| paul_ | and a plugin that say... sent an msn message when a bug was added | 18:59 |
| paul_ | you'd only need to load that plugin when trgierring the event | 18:59 |
| paul_ | (I guess i'm thinking alsmost bootstrapping ? | 19:00 |
| nuclear_eclipse | well, the problem is how do you know that a plugin only needs that one event if you don't load it? :P | 19:00 |
| nuclear_eclipse | honestly, I think the biggest problem with loading plugins (the loading part) is completely negated by using a php opcode caching system, like what we use on mantisbt.org | 19:01 |
| paul_ | nod | 19:01 |
| nuclear_eclipse | but seriously, it's not possible to do "late loading" without somehow loading a plugin to figure out what events it hooks into; at which point it's much simpler to just load them all at once | 19:02 |
| nuclear_eclipse | really, the way I've implemented them is probably as close as possible to that optimal solution, in that once a plugin is loaded, it's only ever touched if a hooked event is triggered, or if a page/file for that plugin is requested | 19:03 |
| nuclear_eclipse | the overhead for an individual plugin is sizeof(PluginClass) + ~5-10 string/int pointers in the init system + 2/3 plugin/function names for each event hooked | 19:04 |
| * daryn_ is back. | 19:05 | |
| nuclear_eclipse | I can't remember the specifics on overhead atm, but it's generally pretty slim | 19:05 |
| * nuclear_eclipse asks daryn to set his IRC client to *not* announce his here/away status.... | 19:05 | |
| nuclear_eclipse | that's what /away and /back are for.... | 19:06 |
| nuclear_eclipse | daryn: in some channels, that would get you kicked :P | 19:07 |
| nuclear_eclipse | paul_: so am I go on those three branches? | 19:09 |
| mantisbot | New bug: Bug 10549 - shobana - open - new | 19:09 |
| mantisbot | New bug: not able to set the client Validation. - http://www.mantisbt.org/bugs/view.php?id=10549 | 19:09 |
| paul_ | nuclear_eclipse: can you look at my graph changes later in week? | 19:09 |
| paul_ | review | 19:10 |
| nuclear_eclipse | arg, I really wish people would stop reporting bugs against old versions, esp when it's bugs that have already been reported and fixed.... | 19:10 |
| nuclear_eclipse | and yes, I'll review if possible; I've never used the graphs though | 19:10 |
| paul_ | and i'm fine with the plugin change - i'm sure it makes sense | 19:11 |
| paul_ | *HOWEVER* | 19:11 |
| paul_ | i've got some things i'd like to think about with plugins | 19:11 |
| paul_ | 1) do we let you specify order for plugins to load in atm? | 19:11 |
| paul_ | (i assume we do?) | 19:11 |
| nuclear_eclipse | 1) yes, priority setting on the plugin management screen | 19:12 |
| paul_ | secondly | 19:12 |
| nuclear_eclipse | 1a) yes, combination of requires and uses flags | 19:12 |
| paul_ | i'd like to add some validation rules to plugins or types or something | 19:12 |
| paul_ | such that you *must* have at least 1 formatting plugin registered | 19:12 |
| paul_ | i.e. you can't remove mantiscoreformatting without replacing it with something else | 19:13 |
| nuclear_eclipse | I think that starts to put too much proprietary validation into the plugin system -- not to mention that just because MantisCoreFormatting is enabled doesn't mean it has to actually be working; case in point being that you can optionally disable any or all of the coreformatting components, specifically to be compatible with other formatting plugins, but can also be done manually as well.... | 19:15 |
| nuclear_eclipse | paul_: so am I go on those three branches? | 19:16 |
| paul_ | My logic is if you turn it off/disable something, you've got a security risk unless you replace with something else | 19:16 |
| paul_ | I guess | 19:16 |
| paul_ | i'm trying to decide whether to make graphs a plugin | 19:16 |
| daryn | nuclear_eclipse: :P | 19:17 |
| daryn | done i think | 19:17 |
| nuclear_eclipse | thank you :) | 19:17 |
| paul_ | daryn's back :P | 19:17 |
| nuclear_eclipse | no offense, but I'd rather not see channel chatter every time you go away or come back; none of us are really that important to know exactly where they are :P | 19:18 |
| daryn | none taken. not sure when/how that got set. don't really remember doing so. | 19:18 |
| nuclear_eclipse | lol | 19:18 |
| paul_ | either of you use spl_autoload stuff in php? | 19:18 |
| nuclear_eclipse | nope | 19:19 |
| daryn | nope | 19:19 |
| nuclear_eclipse | I've never really used any of the SPL | 19:19 |
| CIA-61 | Mantisbt: jreese * r2206801e200a / (3 files in 2 dirs): Improve performance by using string_display_line. | 19:19 |
| CIA-61 | Mantisbt: jreese * rfcccd8275930 /core/ (classes/MantisPlugin.class.php plugin_api.php): Implemented initial support for soft dependencies with the new ->uses property. | 19:19 |
| CIA-61 | Mantisbt: jreese * rf9396639fb11 / (4 files in 2 dirs): Reimplemented the ability to view an issue's project name alongside the category's project name. | 19:19 |
| CIA-61 | Mantisbt: jreese * r6ab1b6defcbb / (core.php core/http_api.php): Extracted HTTP header routines into new API, allowing plugins to set caching headers for their own pages and content. | 19:19 |
| CIA-61 | Mantisbt: jreese * rb128f30f666e /core/category_api.php: Only display category's project name if different from current. | 19:19 |
| CIA-61 | Mantisbt: jreese * r61096547d19a / (7 files in 3 dirs): Merge branches 'http', 'plugin-uses' and 'project-names' | 19:19 |
| paul_ | anyway back to graphs | 19:20 |
| paul_ | grr | 19:20 |
| paul_ | some git has changed trunk | 19:20 |
| nuclear_eclipse | :P | 19:20 |
| daryn | rebase | 19:20 |
| nuclear_eclipse | `git pull --rebase` | 19:21 |
| paul_ | fetch does pull+rebase right? | 19:21 |
| nuclear_eclipse | I just used my ~/.gitconfig to map `git pullr` to `git pull --rebase | 19:21 |
| nuclear_eclipse | no, fetch just does fetch | 19:21 |
| nuclear_eclipse | pull = fetch + merge | 19:21 |
| nuclear_eclipse | pull --rebase = fetch + rebase | 19:21 |
| paul_ | fetch + rebase = pull? | 19:21 |
| paul_ | from wht i can tell | 19:22 |
| paul_ | the /graphs directory is dead | 19:22 |
| paul_ | think i might make some db schema updates too | 19:23 |
| paul_ | erm wtf | 19:25 |
| paul_ | SELECT c.name AS name, COUNT(name) as count FROM mantis_bug_table JOIN mantis_category_table AS c WHERE c.project_id=? GROUP BY name ORDER BY name | 19:29 |
| paul_ | what should that query be with new category api ? | 19:29 |
| nuclear_eclipse | what did that even do under the old category api..../ | 19:36 |
| * paul_ shrugs | 19:38 | |
| paul_ | count of categorys? | 19:38 |
| paul_ | oh I just remembered | 19:49 |
| paul_ | we need to fix soap api before release | 19:49 |
| paul_ | also can you make the url tests pass :P | 19:49 |
| nuclear_eclipse | what url tests? | 19:51 |
| * paul_ STARES | 19:51 | |
| paul_ | the ones i've been asking you to fix for 2 weeks! | 19:51 |
| paul_ | in tests dir | 19:52 |
| nuclear_eclipse | the ones I've been asking you for two weeks to clarify..... | 19:52 |
| * nuclear_eclipse is not sure what has/hasn't changed recently with all the stuff you/giallu did to tests... | 19:52 | |
| nuclear_eclipse | not to mention that *all* the test pages end up outputting a blank page for me.... | 19:53 |
| paul_ | http://www.mantisforge.org:8080/cruisecontrol/buildresults/mantisbt?tab=testResults | 19:54 |
| paul_ | just fix the failures :P | 19:54 |
| nuclear_eclipse | ie, could use some documentation on how all the tests work, so I can actually run the tests... | 19:54 |
| nuclear_eclipse | paul_: that page doesn't even tell me what is wrong, other than a failure is found... | 19:55 |
| paul_ | Failure: | 19:56 |
| paul_ | testStringSanitize(Mantis_StringTest) with data set #0 ('') | 19:56 |
| paul_ | Failed asserting that two strings are equal. | 19:56 |
| paul_ | expected string <> | 19:56 |
| paul_ | difference <?????????> | 19:56 |
| paul_ | got string <index.php> | 19:56 |
| paul_ | /home/cc/cruisecontrol-bin-2.8.2/projects/mantisbt/source/tests/Mantis/StringTest.php:39 | 19:56 |
| paul_ | sure it does | 19:56 |
| nuclear_eclipse | right, that doesn't really help me at all.... | 19:56 |
| paul_ | apparently test expect '' and got 'index.php' | 19:56 |
| nuclear_eclipse | and I can't fix it if I can't run the tests on my own system... | 19:57 |
| nuclear_eclipse | and how do I even know that the tests are correct? | 19:57 |
| paul_ | you use phpunit right? | 19:57 |
| paul_ | or can do | 19:57 |
| paul_ | get phpunit from pear | 19:57 |
| nuclear_eclipse | arg | 19:57 |
| paul_ | pear channel-discover pear.phpunit.de | 19:57 |
| paul_ | pear install phpunit/PHPUnit | 19:58 |
| * nuclear_eclipse can't use pear on his locked-down workstation.... | 19:58 | |
| paul_ | http://www.phpunit.de/manual/current/en/installation.html | 19:58 |
| paul_ | do it manually then :P | 19:58 |
| nuclear_eclipse | and why am I the one tasked with fixing those failures? | 19:59 |
| paul_ | :) | 19:59 |
| paul_ | just fix em | 20:00 |
| paul_ | :P | 20:00 |
| nuclear_eclipse | right.... | 20:00 |
| paul_ | giallu couldn't work out what url tests are supposed to do | 20:00 |
| nuclear_eclipse | where the hell do we even define what's expected? | 20:01 |
| paul_ | but yes | 20:01 |
| paul_ | that should be a array | 20:02 |
| paul_ | in->out i'd say | 20:02 |
| nuclear_eclipse | paul_: thoughts on issue #10217? | 20:12 |
| nuclear_eclipse | bug 10217 | 20:12 |
| mantisbot | Bug 10217 - kec161 - open - new | 20:12 |
| mantisbot | Added ability to have the html buttons bar at the top, bottom or both of the bug view page. - http://www.mantisbt.org/bugs/view.php?id=10217 | 20:12 |
| nuclear_eclipse | my employer has requested this as well, and I think it would be quite useful | 20:12 |
| * paul_ shrugs | 21:13 | |
| paul_ | i'm not sure you'd want both | 21:13 |
| paul_ | how do i move files in git | 21:13 |
| paul_ | in fact, i know this | 21:14 |
Generated by irclog2html.py