| ../irclogs/#mantishelp.2010-01-26.log | ||
| --- scribe started --- | 00:00 | |
| dhx_m | vb123: hi :) | 04:16 |
|---|---|---|
| vb123 | hi dhx_m | 04:23 |
| dawitaya | on helper_api.php on line 188 on mantis-1.2.x that have the pt | 07:11 |
| alemayo | hi | 07:23 |
| alemayo | dhx_m: what do you think about this feature? http://git.mantisforge.org/w/mantisbt/gtz-et.git?a=shortlog;h=refs/heads/sub-categories (gives you sub-category functionality, you just have to create categories with names of the form "master > sub") | 07:24 |
| dhx_m | alemayo: hi | 07:27 |
| dhx_m | alemayo: am I right in saying that your patch tries to allow the grouping of categories together? | 07:28 |
| dhx_m | alemayo: why the need for json_enable()? Are you using AJAX to retrieve the category list? | 07:29 |
| dhx_m | sorry, json_encode() | 07:29 |
| dhx_m | and I don't like: window.alert("not yet loaded"); | 07:30 |
| dhx_m | is there another way of doing that? | 07:30 |
| dhx_m | essentially Mantis needs to operate fine without Javascript | 07:30 |
| dhx_m | so every time you want to use Javascript, you've got to check if the use_javascript option is one | 07:30 |
| dhx_m | *ON | 07:30 |
| alemayo | yes, it tries to group categories | 07:38 |
| alemayo | I will fix that alert :) | 07:39 |
| alemayo | it's just debug code | 07:39 |
| alemayo | that patch does rely on javascript -- so maybe I should check the use_javascript flag and trigger an error that this option is not working without javascript ? | 07:40 |
| dhx_m | why is Javascript needed? | 07:41 |
| dhx_m | do we have it in place already? | 07:41 |
| dhx_m | or are you adding it for performance reasons (don't load a huge category list unless really needed)? | 07:41 |
| alemayo | it is just a matter of usability | 07:42 |
| alemayo | we have a lot of categories, so we provide two comboboxes, first the master category is choosen, then -- via javascript --- the category box is filtered to just display that subcategories | 07:42 |
| dhx_m | ah | 07:45 |
| dhx_m | in that case, are you familiar with the xhtml AJAX stuff already built into Mantis? | 07:46 |
| dhx_m | it's best to use the same technique throughout the code instead of introducing different techniques at different points in the codebase | 07:46 |
| dhx_m | if that means we need to fix the existing AJAX implementation, then I'd be happy to do that :) | 07:46 |
| dhx_m | but AFAIK the current AJAX implementation has to be concerned with things like security (ensuring a valid user is requesting information, etc) | 07:47 |
| dhx_m | so it can get complex | 07:47 |
| CIA-22 | Mantisbt: alexander.menk master-1.2.x * rd1a69cd21e62 /core/html_api.php: Fix #11417: Allow EVENT_MENU_MAIN plugin events to return null | 08:02 |
| CIA-22 | Mantisbt: alexander.menk * r321ac71de73e /core/html_api.php: Fix #11417: Allow EVENT_MENU_MAIN plugin events to return null | 08:02 |
| dhx_m | alemayo: I've just had a look at issue-make-description-hideable and those changes will break quite a few areas of Mantis that will expect each issue to have a summary | 08:20 |
| dhx_m | (at least I imagine that'll be the case) | 08:20 |
| alemayo | brb ... have some presentation | 08:20 |
| dhx_m | ok | 08:22 |
| alemayo | re | 11:11 |
| alemayo | dhx_m: concerning the AJAX stuff: I do not use ajax :) it just looks like that. josn_encode is used for the on-time transmission of the full category information that would otherwise appear in the category_id selectbox . there should not be any security implications | 11:13 |
| dhx_m | nuclear_eclipse: I'm working on a new HgWeb plugin for SourceIntegration... even though I'll never use it :p | 11:13 |
| dhx_m | nuclear_eclipse: HgWeb is for Mercurial BTW | 11:13 |
| alemayo | dhx_m: concerning issue-make-description-hideable: most of the stuff looks ugly because there is no summary anymore --- but we did not notice anything really breaking (i.e. crashing ..) so far | 11:14 |
| dhx_m | alemayo: yep I was concerned with things like email titles, CSV/print/Excel/etc exporting, relationship graphs, etc | 11:15 |
| dhx_m | there are so many places we use the summary field | 11:15 |
| alemayo | dhx_m: maybe we should just rename the summary field for our purpose :) | 11:15 |
| alemayo | dhx_m: actually we start to use mantis to track everything in here ... all but not bugs :-) | 11:16 |
| dhx_m | I can't see why you wouldn't have a summary field :p | 11:16 |
| alemayo | it's none of my business :-) | 11:16 |
| dhx_m | unless maybe everything you're tracking is done via IDs | 11:16 |
| dhx_m | ie. you're using Mantis to track orders? | 11:16 |
| dhx_m | so all you care about is the order ID, customer, value, order date, shipment date, etc | 11:17 |
| dhx_m | nuclear_eclipse: there are a few differences to gitweb, such as no list of files added/removed/modified (you have to work it out from the diff itself (kind of ugly) | 11:20 |
| alemayo | dhx_m: yes, one of our units that will use mantis is logistics, they will basically track orders | 11:29 |
| dhx_m | yep, I see where you're coming from | 11:32 |
| dhx_m | ideally we'd have a function (customisable?) to return a summary line on an issue | 11:32 |
| dhx_m | and that'd be used in emails, issue list page, twitter output, etc | 11:32 |
| alemayo | yes ... | 11:39 |
| alemayo | good idea so far :) | 11:40 |
| alemayo | with customizable function you mean function that calls an event :) ? | 11:40 |
| dhx_m | maybe not for what I suggested | 11:43 |
| dhx_m | it'd be a little tricky | 11:43 |
| dhx_m | plugins overwriting each other, etc | 11:43 |
| alemayo | next question is, how to hide the bug_id :-) | 11:48 |
| dhx_m | now that sounds like a fun task :p | 11:51 |
| dhx_m | it won't be possible to completely hide it | 11:51 |
| dhx_m | ie. it has to be used in URLs | 11:51 |
| dhx_m | there needs to be some way to uniquely identify each issue | 11:52 |
| alemayo | yes of course... the URLs are okay | 11:53 |
| alemayo | anyway ... there is already EVENT_DISPLAY_BUG_ID :) | 11:53 |
| alemayo | I can just make this one to return "" ... or a custom field or whatever | 11:54 |
| alemayo | should work .. let's see | 11:54 |
| * alemayo see's the next plugin comming .. "ReplaceBugIDByWhateverYouLike" | 11:55 | |
| alemayo | soon we'll be dominating mantisforge :-) | 11:55 |
| dhx_m | haha | 11:56 |
| alemayo | hm | 11:59 |
| alemayo | anyway ... I told my boss half a year ago, that we should use mantis instead of excel sheets .. that's my gain now :) | 11:59 |
| alemayo | now mantis has to be as flexible as excel sheets *gg* | 12:00 |
| alemayo | http://en.wikipedia.org/wiki/Eierlegende_Wollmilchsau :-) | 12:01 |
| dhx_m | lol | 12:06 |
| dhx_m | Excel | 12:06 |
| dhx_m | Eierlegende Wollmilchsau: interesting term/link, particularly because of the complicated name :) | 12:07 |
| dhx_m | I'd say the ratio of valid uses of Excel to invalid uses is somewhere above 10,000,000:1 | 12:08 |
| dhx_m | oops, 1:10,000,000 ;) | 12:08 |
| alemayo | wow .. done :) | 12:13 |
| alemayo | concerning excel: right ... | 12:14 |
| alemayo | dhx_m: what is the best way to retrieve the project id of a bug? bug_get_field ? | 12:18 |
| dhx_m | do you have a bug object at hand? | 12:19 |
| dhx_m | or just the ID? | 12:19 |
| dhx_m | I'd say use bug_get_field if you only need a single project ID | 12:19 |
| dhx_m | and only if you don't have a bug object already pulled from the database | 12:20 |
| dhx_m | actually | 12:20 |
| dhx_m | bug_get_field pulls the entire bug from the database | 12:20 |
| dhx_m | not just the field you're interested in | 12:20 |
| dhx_m | so the overhead of creating a new bug object shouldn't be much more... | 12:21 |
| alemayo | I have just the ID :) | 12:21 |
| dhx_m | so use bug_get() | 12:21 |
| dhx_m | and you'll receive a bug object | 12:22 |
| dhx_m | to which you can just pull values out of using this sort of technique: | 12:22 |
| dhx_m | $t_the_bug->project_id | 12:22 |
| alemayo | okay .. bug_get .. thanks | 12:22 |
| alemayo | by the way .. I call that in the EVENT_DISPLAY_BUG_ID ... not the best thing concerning performance, but computers are cheaper than programmers :-) | 12:29 |
| dhx_m | lol | 12:30 |
| dhx_m | bugs are cached btw | 12:30 |
| dhx_m | so if you get a bug once, it'll be fast next time | 12:30 |
| alemayo | yes I saw that caching stuff ... | 12:35 |
| alemayo | actually that whole mantis code reminded me of a project I did some years ago | 12:35 |
| alemayo | first everything function based, then we introduced objects, and the project grew, then we introduced DB caching, very similar to that in mantis | 12:36 |
| alemayo | but somehow it would make sense to rewrite mantis completely using some modern ORM mapper or s.th. ? | 12:37 |
| alemayo | anyway, it's mature and proven to work .. so never touch a running system ? | 12:37 |
| dhx_m | well we're slowly trying to move everything to OO | 12:43 |
| dhx_m | away from the old procedural programming style | 12:43 |
| alemayo | yes.. saw that | 13:00 |
| dhx_m | nuclear_eclipse: importing works, woohoo :) | 13:19 |
| alemayo | just another new plugin ... http://git.mantisforge.org/w/CustomID.git | 13:30 |
| dhx_m | it's good that you're making quite a few plugins, they're good examples for other people to look at | 13:39 |
| dhx_m | when they want to write their own Mantis plugin | 13:39 |
| dawitaya | how can I find out if a project is a child of another project? | 13:45 |
| dhx_m | programatically? | 13:46 |
| dawitaya | yes | 13:46 |
| dhx_m | project_hierarchy_inheritance | 13:48 |
| dhx_m | * Generate an array of project's the given project inherits from, | 13:48 |
| dhx_m | * including the original project in the result. | 13:48 |
| dhx_m | * @param int $p_project_id Project ID | 13:48 |
| dhx_m | * @param bool $p_show_disabled Whether or not to consider projects which are disabled | 13:48 |
| dhx_m | * @return array | 13:48 |
| dawitaya | thanks a lot | 14:04 |
| dawitaya | is there any reason that int(0) is included in that list returned ? | 14:04 |
| dhx_m | not sure | 14:08 |
| dhx_m | check project_hierarchy_api.php to find out more :) | 14:09 |
| dhx_m | alemayo: I read your comment http://www.mantisbt.org/bugs/view.php?id=10211#c24250 suggesting someone helps with ServiceLevel | 14:14 |
| dhx_m | yet it isn't uploaded to MantisForge :) | 14:14 |
| dhx_m | I'd be interested in helping out because the plugin sounds quite useful :) | 14:15 |
| alemayo | so I would just add dhx to mantisforge ? | 14:19 |
| dhx_m | that's up to you (I can otherwise just make a fork) | 14:20 |
| alemayo | is the mantisbot keeping chatlogs ? | 14:20 |
| dhx_m | what I was trying to say though | 14:20 |
| dhx_m | is the ServiceLevel repo on there only has a few strings in a language file | 14:20 |
| dhx_m | yes | 14:20 |
| dhx_m | I wasn't sure if that was intentional | 14:20 |
| alemayo | oh no wait | 14:21 |
| alemayo | actually it is a bit dependend on our subcategory hacks :) | 14:22 |
| dhx_m | ah ok | 14:22 |
| dhx_m | it might be best to try and decouple them if possible | 14:22 |
| dhx_m | before pushing it to mantisforge | 14:22 |
| alemayo | argh, my dual screen config is messed up ... | 14:23 |
| alemayo | brb | 14:23 |
| alemayo | re | 14:25 |
| alemayo | maybe that was the reason why I did not push it yet I guess | 14:25 |
| dhx_m | :) | 14:25 |
| alemayo | I will push it ... | 14:29 |
| alemayo | it is also working without the subcategories | 14:29 |
| alemayo | it's just not very beautiful :) | 14:29 |
| dhx_m | nice :) | 14:29 |
| dhx_m | I'll check it out | 14:29 |
| alemayo | so it's up | 14:31 |
| alemayo | have fun :) | 14:31 |
| alemayo | currently it is just a pimped summary page | 14:31 |
| dhx_m | btw I noticed you let the "mob" user write to that repo | 14:32 |
| alemayo | yes | 14:32 |
| dhx_m | the "mob" user is for public use, just in case you weren't aware | 14:32 |
| alemayo | can mob writer everywhere or only to a branch called mob ? | 14:32 |
| dhx_m | so anyone can commit | 14:32 |
| dhx_m | anywhere I think | 14:32 |
| alemayo | hm | 14:32 |
| dhx_m | personally I don't like the idea much | 14:33 |
| alemayo | I liked the idea :) | 14:33 |
| dhx_m | people should make their own fork instead, and request you to merge their branches/changes | 14:33 |
| alemayo | anyway .. your username is "dhx", isn't it > | 14:33 |
| dhx_m | the thing is, someone can screw up your repository (by accident, or otherwise) | 14:33 |
| dhx_m | and there may not be any way of knowing | 14:34 |
| dhx_m | yes, I'm dhx | 14:34 |
| alemayo | I was beliving git is smart enough to not allow screwing things up ... hm... | 14:34 |
| alemayo | is that paul__ in that IRC the same paul that is hosting the mantisforge git ? | 14:34 |
| dhx_m | well they could delete your branches and replace them with their own | 14:35 |
| dhx_m | yep | 14:35 |
| dhx_m | at least I think the "mob" user can do that | 14:35 |
| dhx_m | it'd be fine if "mob" could only commit, and not delete branches | 14:35 |
| dhx_m | or actually | 14:35 |
| dhx_m | I don't really like that either, because people could make malicious commits | 14:36 |
| dhx_m | that other people don't notice when they download a plugin | 14:36 |
| alemayo | I have read somewhere that mob only can access the mob branch... | 14:36 |
| dhx_m | ah maybe that's right then | 14:36 |
| alemayo | http://git.mantisforge.org/mob.html | 14:37 |
| alemayo | so added you | 14:37 |
| dhx_m | ah, "mob" seems quite useful then :) | 14:38 |
| dhx_m | although git format-patch does much the same thing | 14:38 |
| dhx_m | it might work with a larger/more active developer community | 14:39 |
| alemayo | yes .. so at least I see when somebody made a patch | 14:40 |
| alemayo | but anyway, I still like it | 14:41 |
| * alemayo just adds the mob branch for all of his plugins | 14:41 | |
| dhx_m | yep | 14:42 |
| alemayo | should we document the servicelevel plugin in some wiki ? | 14:43 |
| dhx_m | some comments: | 14:43 |
| dhx_m | if ($_GET["list"]) { | 14:43 |
| dhx_m | should use the gpc_get_string_array() function call instead from gpc_api.php | 14:43 |
| dhx_m | Undefined index: submitted | 14:44 |
| dhx_m | Full path: /var/www/localhost/htdocs/mantis-git/plugins/ServiceLevel/pages/evaluation_api.php | 14:45 |
| dhx_m | Line: 387 | 14:45 |
| alemayo | just fix it :-) | 14:45 |
| alemayo | this list stuff is anyways very very hacky ... | 14:45 |
| dhx_m | also same line: | 14:45 |
| dhx_m | Undefined index: closed | 14:45 |
| dhx_m | yep, I guess a lot of bugs are found when different people use it | 14:45 |
| dhx_m | as everyone has different Mantis settings, etc | 14:45 |
| alemayo | were there any major changes in summary_page ? | 14:46 |
| dhx_m | Undefined variable: hide | 14:46 |
| alemayo | because I just copied summary_page ... but from RC1 | 14:46 |
| dhx_m | Full path: /var/www/localhost/htdocs/mantis-git/plugins/ServiceLevel/pages/evaluation_api.php | 14:46 |
| dhx_m | Line: 41 | 14:46 |
| alemayo | ah you have warnings on? just switch them off *ggg* | 14:46 |
| alemayo | more interesting are the mysql views the plugin is creating | 14:46 |
| dhx_m | I always develop with the strictest warnings :p | 14:47 |
| dhx_m | see http://git.mantisbt.org/?p=mantisbt.git;a=history;f=summary_page.php;h=c7f1d9c9d9e5ffd5c7f2485e7bb7f4760826ac5a;hb=HEAD | 14:47 |
| dhx_m | only the commits from 2009 are relevant to the 1.2.x branch | 14:47 |
| dhx_m | the 2010 commits are 1.3.x only | 14:47 |
| dhx_m | nothing too major | 14:48 |
| dhx_m | actually check here instead: | 14:48 |
| dhx_m | http://git.mantisbt.org/?p=mantisbt.git;a=history;f=summary_page.php;h=0ad8ca7488d75f93f6af262d80f62921004ecffa;hb=master-1.2.x | 14:48 |
| dhx_m | for the 1.2.x branch | 14:48 |
| nuclear_eclipse | hi dhx_m | 14:49 |
| dhx_m | nuclear_eclipse: hi :) | 14:49 |
| nuclear_eclipse | it'll be nice to finally have hg integration to match git :P | 14:50 |
| nuclear_eclipse | now you just need to make a plugin for bitbucket too :P | 14:50 |
| dhx_m | nuclear_eclipse: perhaps, if it's easy :) | 14:51 |
| dhx_m | nuclear_eclipse: I was actually surprised with how relatively simple it is to write a SourceIntegration plugin | 14:51 |
| dhx_m | you've done well! :) | 14:51 |
| nuclear_eclipse | yep | 14:51 |
| nuclear_eclipse | thank you | 14:51 |
| nuclear_eclipse | tbh, after looking at how I did the plugin columns and filters system, I wish I had done something like that for source integration instead | 14:52 |
| nuclear_eclipse | would have saved a *lot* of if statements in functions... | 14:52 |
| dhx_m | my current view on Mercurial/Bazaar is that it is a half-assed git :p | 14:52 |
| dhx_m | yep | 14:53 |
| nuclear_eclipse | I'm tempted to rewrite the core of source integration framework to make it nicer, and call *that* 1.0... | 14:53 |
| dhx_m | although to be fair, SCMs don't change that frequently and none really support custom fields (I wish they did) | 14:53 |
| nuclear_eclipse | I just meant the way the plugins integrate with the framework | 14:54 |
| dhx_m | ah ok | 14:54 |
| nuclear_eclipse | eg, rather than the core firing events, the core fires a single event to register source integration classes, and then the core directly calls only the appropriate integration instance, rather than calling them all via events | 14:55 |
| dhx_m | bitbucket would be quite simple to write a plugin for, now I look at it ;) | 14:55 |
| nuclear_eclipse | would be both more efficient and make writing a little more straightforward | 14:56 |
| dhx_m | good point :) | 14:56 |
| nuclear_eclipse | just requires me to stop being lazy and actually get some work done... | 14:56 |
| daryn | you have that problem too nuclear_eclipse? | 14:57 |
| nuclear_eclipse | I think all diehard programmers do :P | 14:57 |
| dhx_m | haha yep | 14:58 |
| daryn | that's what makes us programmers, right? | 14:58 |
| daryn | figuring out ways to do less work | 14:58 |
| nuclear_eclipse | exactly | 14:58 |
| dhx_m | alemayo: another bug (missing mantis_db_table() call or whatever function it is): | 14:58 |
| dhx_m | Undefined variable: t_mantis_bug_table | 14:58 |
| dhx_m | Full path: /var/www/localhost/htdocs/mantis-git/plugins/ServiceLevel/pages/evaluation_page.php | 14:58 |
| dhx_m | Line: 178 | 14:58 |
| dhx_m | (line numbers may be off, I've made a few edits to fix the bugs I mentioned before) | 14:58 |
| dhx_m | Undefined index: 1 | 15:00 |
| dhx_m | Full path: /var/www/localhost/htdocs/mantis-git/plugins/ServiceLevel/pages/evaluation_api.php | 15:00 |
| dhx_m | Line: 275 | 15:00 |
| dhx_m | if (!$statistics[$row["project_id"]]) $statistics[$row["project_id"]] = array("name" => $row["category_name"]); | 15:00 |
| dhx_m | the pattern I'm seeing is that you're using if($array['key']) instead of if(isset($array['key'])) | 15:02 |
| nuclear_eclipse | dhx_m: I think I'll work on source integration shortly, just gotta get out of windows and back to linux... | 15:13 |
| nuclear_eclipse | been starting to get into working on a mod team for a game, and Visual Studio really only works in windows... | 15:14 |
| dhx_m | I doubt there are many bug trackers out there that can let you write a quick plugin (2-3hrs tops) to integrate your bug tracker with whatever web based VCS you're using :) | 15:14 |
| dhx_m | yep | 15:14 |
| dhx_m | so in that sense, SourceIntegration is quite solid | 15:14 |
| nuclear_eclipse | yeah, I've been using it on multiple projects quite successfully | 15:15 |
| nuclear_eclipse | and the integrations you see aren't even all of the ones I wrote :P | 15:15 |
| nuclear_eclipse | had to write a couple proprietary integration plugins for my former employer | 15:15 |
| dhx_m | I quite like it how the diffs/etc are done with other web based repository viewing tools | 15:15 |
| nuclear_eclipse | yeah, that's more laziness/reuse :P | 15:16 |
| dhx_m | no wonder it's designed to be easy to extend then :) | 15:16 |
| dhx_m | well it's better :p | 15:16 |
| dhx_m | no need to reinvent everything when it's not necessary to do so | 15:17 |
| nuclear_eclipse | exactly | 15:17 |
| nuclear_eclipse | I did have to write from-scratch viewers for one of the proprietary vcs plugins, but only because there is no existing web viewer for it | 15:17 |
| dhx_m | yep | 15:18 |
| dhx_m | I guess Trac tries to go down the rewrite path | 15:18 |
| nuclear_eclipse | yep | 15:18 |
| nuclear_eclipse | my biggest gripe with Trac is the repo-per-install paradigm | 15:19 |
| dhx_m | yep | 15:19 |
| nuclear_eclipse | I have multiple repos on my own project tracker, and my old employer has even more, and they aren't all the same VCS type | 15:19 |
| nuclear_eclipse | and it's quite often that, esp with separate integrated products, you have commits from separate VCS repos for the same bug number | 15:20 |
| dhx_m | yep | 15:20 |
| dhx_m | and another reason why using web interfaces is handy | 15:21 |
| nuclear_eclipse | yep | 15:21 |
| dhx_m | you can add repos for upstream projects | 15:21 |
| dhx_m | and link commits in those repos to bugs in your own (where upstream is blocking) | 15:21 |
| dhx_m | the only real catch at the moment is the slooowness at which commits are imported | 15:22 |
| dhx_m | it wouldn't be so bad if it did 50 commits per page refresh | 15:22 |
| dhx_m | with resume support | 15:22 |
| nuclear_eclipse | dhx_m: you could make it do that... | 15:25 |
| dhx_m | it'd be nice if it was built into the core though | 15:25 |
| dhx_m | as opposed to needing to be implemented in each plugin | 15:25 |
| dhx_m | I'm not sure if that's possible though | 15:25 |
| nuclear_eclipse | well, it would just be a matter of "don't find all the commits this round" :P | 15:25 |
| dhx_m | I guess a page like Source/checkin.php | 15:26 |
| nuclear_eclipse | there's already support for returning a subset at a time for memory reasons | 15:26 |
| dhx_m | could generically call a plugin event for the relevant repository with a start and end index | 15:26 |
| dhx_m | thus it becomes integrated into the core :) | 15:27 |
| nuclear_eclipse | ie, with large SVN repos, getting an 'svn log' of the ntire history blows out the PHP memory limit almost every time, so the core supports returning commits in batches | 15:27 |
| dhx_m | yep | 15:27 |
| dhx_m | I should look into it a little further | 15:27 |
| nuclear_eclipse | however, the import still takes forever that way, it just no longer uses up all the memory :P | 15:28 |
| nuclear_eclipse | back in linux now | 15:28 |
| nuclear_eclipse | I should probably get around to all the other source integration bugs on my tracker, too... | 15:30 |
| dhx_m | did you see my modtimestamp patch for Timecard (from last year)? | 15:30 |
| dhx_m | it probably needs some more work, but it may be of interest | 15:31 |
| nuclear_eclipse | yeah, I saw it :P | 15:31 |
| dhx_m | it allows (optionally) minute resolution | 15:31 |
| nuclear_eclipse | employer didn't like the idea, so it never got inlined on their time, so it never got committed at all :P | 15:31 |
| dhx_m | and allows you to change the time tracked as well as the timestamp of it | 15:32 |
| dhx_m | yep | 15:32 |
| nuclear_eclipse | maybe because I never felt like working on mantis stuff that I had just spent 8 hours dealing with... | 15:32 |
| nuclear_eclipse | s/maybe/mainly/ | 15:32 |
| dhx_m | haha understandable | 15:32 |
| dhx_m | I guess Timecard (with my changes) would make make it identical to the built in system in terms of features | 15:33 |
| dhx_m | thus leading to a possible removal of the built-in system | 15:33 |
| nuclear_eclipse | yeah, probably, not that it would be a bad thing... | 15:33 |
| dhx_m | pending a conversion script | 15:33 |
| nuclear_eclipse | lol, I started working on this, and now I have to look at my docbook to figure out what some of the events in mantis are :P | 15:40 |
| nuclear_eclipse | apparently I wrote good documentation too :) | 15:42 |
| dhx_m | lol yep | 15:44 |
| rolfkleef | anyone "in charge" of the issue tracker at mantisbt around? | 16:27 |
| rolfkleef | like to see if I can be of help in sorting out issues :-) | 16:28 |
| nuclear_eclipse | rolfkleef: something like a "triage" type of role you mean? | 16:35 |
| rolfkleef | yes | 16:45 |
| rolfkleef | I've modestly tagged two issues with "close_me" so far, | 16:46 |
| nuclear_eclipse | I'm all for it | 16:46 |
| nuclear_eclipse | our tracker really needs some lovin :P | 16:46 |
| rolfkleef | and find myself browsing for info through issues quite a bit lately, often thinking "this could go to feedback" and then be closed if that doesn't come | 16:46 |
| rolfkleef | I know :-) 2200+ issues or so is a bit overwhelming :-) | 16:47 |
| nuclear_eclipse | if you're willing to put in the effort, I'll gladly give you developer access | 16:47 |
| nuclear_eclipse | just need to know your username on our tracker | 16:47 |
| rolfkleef | I'm happy to try it out for a while, see if it works for everyone | 16:47 |
| rolfkleef | take a guess :-) | 16:47 |
| nuclear_eclipse | hehe | 16:48 |
| rolfkleef | not sure if there are sort of meetings sometimes to discuss tickets? | 16:48 |
| nuclear_eclipse | not really | 16:48 |
| nuclear_eclipse | we're a very adhoc development team, for better or worse | 16:49 |
| rolfkleef | I could use tags to flag stuff for review by someone with more indepth knowledge | 16:49 |
| nuclear_eclipse | most we have is periodic design discussions on IRC or mantisbt-dev mailing list | 16:49 |
| rolfkleef | ok - well, if there's no real policy yet, I'll try to introduce a few rules | 16:50 |
| nuclear_eclipse | are you subscribed to the dev list? it's low traffic, but would be a good place to post any ideas/plans for how you'd like to handle any sort of triage system | 16:50 |
| nuclear_eclipse | ... *very* low traffic... =\ | 16:50 |
| rolfkleef | yeah, I'm reading it via news.gmane.org | 16:51 |
| nuclear_eclipse | ok | 16:51 |
| nuclear_eclipse | I've given you developer access to the main project | 16:51 |
| rolfkleef | ok, cool | 16:52 |
| nuclear_eclipse | I'll drop a note on the dev list about it | 16:52 |
| rolfkleef | I'll send an intro myself as well then | 16:52 |
| nuclear_eclipse | I assume your first name is Rolf? | 16:52 |
| rolfkleef | it is | 16:53 |
| rolfkleef | been working with mantis for 4 years or so now, a few years ago tried to build a work flow system for a funding organisation out of it | 16:54 |
| rolfkleef | (have to log off here... back later. thanks!) | 16:56 |
| nuclear_eclipse | cheers | 16:57 |
| nuclear_eclipse | lunchtime for me too | 16:58 |
| * paul__ looks around | 21:20 | |
| paul__ | nuclear_eclipse: dhx_m | 21:20 |
| nuclear_eclipse | hi paul__ | 21:36 |
Generated by irclog2html.py