| CIA-21 | Mantisbt: hickseydr * r101d87befda9 / (core/print_api.php manage_user_edit_page.php): Fix #11862: Preselect user's current access level in dropdown | 00:06 |
|---|---|---|
| CIA-21 | Mantisbt: hickseydr master-1.2.x * r2f0fd38df55b / (core/print_api.php manage_user_edit_page.php): Fix #11862: Preselect user's current access level in dropdown | 00:06 |
| *** Joins: kirillka (~Miranda@global01.vester.ru) | 00:38 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 268 seconds) | 00:41 | |
| *** Joins: user_loser (~akp@c-98-229-26-105.hsd1.ma.comcast.net) | 00:41 | |
| user_loser | hi, i change the IP address of my mantis server, now i can't connect to my DB... any one have any idea?s | 00:42 |
| user_loser | i get this for an error | 00:48 |
| user_loser | Warning: Invalid argument supplied for foreach() in /opt/mantisbt-1.1.6/core/database_api.php on line 282 | 00:48 |
| user_loser | Fatal error: 401 in /opt/mantisbt-1.1.6/core/database_api.php on line 187 | 00:48 |
| *** Quits: daryn (~INTERACT\@h68.10.96.216.dynamic.ip.windstream.net) (Quit: daryn) | 00:48 | |
| dhx_m | can you provide me with 3 lines either side of line 282 in database_api.php | 01:16 |
| kirillka | dhx_m: mo | 01:17 |
| dhx_m | kirillka: hi | 01:17 |
| kirillka | dhx_m: my mail with patch to mantis-dev send normal or you don't get it? | 01:19 |
| kirillka | google bad worked with maillist :( | 01:19 |
| dhx_m | kirillka: I remember now, thanks for the reminder :) | 01:19 |
| dhx_m | I did see it... I'll get onto it in a moment | 01:20 |
| dhx_m | actually | 01:20 |
| kirillka | dhx_m: ok.. I don't receive own mail sending to maillist and can check sending correct or not | 01:20 |
| dhx_m | is it ok to wrap emails at anything other than 80 characters? | 01:20 |
| kirillka | dhx_m: I test in my company - this work correct, I can send copy of mails.. | 01:21 |
| kirillka | dhx_m: I can send before this changes and after | 01:21 |
| kirillka | dhx_m: may be need update phpmailer? | 01:22 |
| dhx_m | kirillka: see http://www.ietf.org/rfc/rfc2646.txt | 01:22 |
| dhx_m | as the emails from MantisBT aren't quoting anything and don't get replied to, setting word wrap to 80 is fine | 01:23 |
| kirillka | dhx_m: yes, but in cyrillic not mail wrap less 80 chars | 01:24 |
| dhx_m | for the record I hate the idea of inserting manual line breaks to wrap words :) | 01:25 |
| dhx_m | I think the client should do that | 01:25 |
| kirillka | dhx_m: may be.. But in mail body I see such as in client | 01:26 |
| kirillka | Дата изменения Пользователь Поле | 01:26 |
| kirillka | Изменить | 01:26 |
| kirillka | this must be in one line | 01:26 |
| kirillka | "Дата изменения Пользователь Поле | 01:26 |
| kirillka | Изменить " | 01:26 |
| kirillka | one sec.. I send screen, where look better what I mean | 01:27 |
| dhx_m | ok | 01:27 |
| *** Quits: wolog (~wolog@AOrleans-152-1-85-26.w90-21.abo.wanadoo.fr) (Remote host closed the connection) | 01:31 | |
| kirillka | dhx_m: http://yfrog.com/6c20100429082857p | 01:31 |
| kirillka | dhx_m: this screen from mantisbt.org | 01:31 |
| kirillka | dhx_m: this screen in my installation with patch http://yfrog.com/0q20100429083224p | 01:34 |
| kirillka | dhx_m: I think need check with newest version of phpmailer | 01:35 |
| dhx_m | kirillka: I think the problem is that the word wrap algorithm which phpmailer uses is CRAP | 01:37 |
| dhx_m | and it doesn't understand the difference between Unicode and ASCII | 01:37 |
| dhx_m | ie. a Cyrillic character may be represented in 3 bytes | 01:38 |
| dhx_m | but it should only count one character towards the line length | 01:38 |
| kirillka | dhx_m: 2 byte | 01:41 |
| dhx_m | yep I'll try upgrading MantisBT to PHPMailer 5.1 (from 5.02) | 01:42 |
| kirillka | dhx_m: If you give me online repository - I can check on working mantis | 01:43 |
| CIA-21 | Mantisbt: hickseydr master-1.2.x * r3b1a5b87e2b2 /core/filter_api.php: Fix #11764: Avoid collision of column names when ordering fields | 01:46 |
| CIA-21 | Mantisbt: hickseydr * r8be869afafd7 /core/filter_api.php: Fix #11764: Avoid collision of column names when ordering fields | 01:46 |
| dhx_m | I'll push it to master if it works out ok | 01:47 |
| kirillka | dhx_m: may be in fork? | 01:51 |
| kirillka | dhx_m: may be better in fork? | 01:51 |
| dhx_m | ok pushed | 02:00 |
| CIA-21 | Mantisbt: hickseydr master-1.2.x * ree1a231fbb68 /library/ (10 files in 3 dirs): Upgrade PHPMailer from 5.02 to 5.1 | 02:01 |
| CIA-21 | Mantisbt: hickseydr * rb3882f83370c /library/ (10 files in 3 dirs): Upgrade PHPMailer from 5.02 to 5.1 | 02:01 |
| *** Quits: siebrand (~beis@sm.xs4all.nl) () | 02:02 | |
| *** Joins: Cupertino (~Cupez@unaffiliated/cupertino) | 02:31 | |
| kirillka | dhx_m: http://yfrog.com/2o20100429093533p not help.. set $g_email_wrapping_length = 80; | 02:37 |
| kirillka | X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) | 02:37 |
| *** Joins: giallu (~giallu@fedora/giallu) | 02:43 | |
| *** Quits: user_loser (~akp@c-98-229-26-105.hsd1.ma.comcast.net) (Ping timeout: 265 seconds) | 02:47 | |
| *** Joins: wolog (~wolog@195.6.104.193) | 02:55 | |
| *** Joins: bodie (~bodie@fcnoos-nd-fw01.freecode.no) | 04:25 | |
| bodie | Hi all, someone here? | 04:25 |
| bodie | I want to ask about something. I upgraded to latest stable and now when I login as administrator I can see in Manage configuration - Action just for delete | 04:26 |
| bodie | Can't see other actions. What can be wrong? | 04:26 |
| bodie | no one know? | 04:30 |
| *** Joins: rolfkleef (~rolf@urtica.xs4all.nl) | 04:31 | |
| *** Quits: rolfkleef (~rolf@urtica.xs4all.nl) (Remote host closed the connection) | 04:33 | |
| bodie | hmmm, is it really help channel? :D | 04:44 |
| paul_ | dhx_m: awake yet? | 05:08 |
| paul_ | er | 05:09 |
| paul_ | didn't I already push phpmailer 5.1 to trunk?? | 05:09 |
| bodie | Is there a new version of print_all_bug_page_excel.php for 1.2.0 or 1.2.1 ? Because it's not in default install | 05:15 |
| paul_ | iirc, it got renamed | 05:16 |
| bodie | ? | 05:18 |
| bodie | to which one? | 05:19 |
| bodie | Because after upgrade I can see only Word and IE icons for export on Summary page | 05:19 |
| bodie | this one? http://bugtracker.morinie.fr/mantis/dokuwiki/doku.php?id=mantis:13:start | 05:20 |
| bodie | I installed it Import/Export issues 1.0 | 05:20 |
| bodie | even after install of this plugin still just Word and IE export option for Summary | 05:22 |
| kirillka | paul_: lo. not | 05:31 |
| kirillka | bodie: all plugins from this site only for 1.x.x version | 05:32 |
| bodie | kirillka: done, it's running | 05:43 |
| *** Joins: rolfkleef (~rolf@urtica.xs4all.nl) | 06:40 | |
| *** Joins: fanno (~b3g@193.3.95.240) | 07:14 | |
| *** Joins: Watergad (~Watergad@62.140.250.221) | 07:22 | |
| *** Quits: rolfkleef (~rolf@urtica.xs4all.nl) (Ping timeout: 240 seconds) | 07:41 | |
| Watergad | Thanks for the help (: | 08:03 |
| Watergad | While preparing to expound my problem here, I've found the solution ) | 08:03 |
| *** Joins: rolfkleef (~rolf@82-204-82-162.fttx.bbeyond.nl) | 08:07 | |
| *** Quits: bodie (~bodie@fcnoos-nd-fw01.freecode.no) (Quit: Leaving.) | 09:02 | |
| *** Quits: Watergad (~Watergad@62.140.250.221) (Quit: Just left.) | 09:05 | |
| *** Quits: wolog (~wolog@195.6.104.193) (Remote host closed the connection) | 09:16 | |
| *** Joins: daryn (~INTERACT\@rrcs-76-79-4-2.west.biz.rr.com) | 09:17 | |
| *** Quits: daryn (~INTERACT\@rrcs-76-79-4-2.west.biz.rr.com) (Client Quit) | 09:17 | |
| *** Joins: daryn (~INTERACT\@rrcs-76-79-4-2.west.biz.rr.com) | 09:18 | |
| *** Joins: wolog (~wolog@195.6.104.193) | 09:19 | |
| dhx_m | paul_: hi | 09:20 |
| paul_ | dhx_m: . | 09:25 |
| dhx_m | paul_: no way! it's impossible.... we meet! :D | 09:25 |
| paul_ | I swear i'd already updated to that phpmailer ;/ | 09:26 |
| paul_ | anyway | 09:27 |
| paul_ | re that db change | 09:27 |
| paul_ | i'm not sure if you've just broken something or not :P | 09:28 |
| paul_ | I *think* sometimes it might have passed in db.field | 09:28 |
| paul_ | however | 09:28 |
| paul_ | assuming you are right | 09:28 |
| paul_ | on the 2nd set of those diff's | 09:28 |
| paul_ | you can delete the 2 lines above the code you changed in the diff right? | 09:28 |
| paul_ | you've gone :( | 09:30 |
| dhx_m | that is what I thought too | 09:31 |
| dhx_m | and it tells me we're currently using ADOdb 5.09a when I'm sure we updated to 5.10? | 09:31 |
| dhx_m | is the repository broken? | 09:31 |
| paul_ | ? | 09:33 |
| dhx_m | ah | 09:33 |
| dhx_m | it's just README.txt that's incorrect | 09:33 |
| dhx_m | there is a new ezC too which I'll update | 09:34 |
| paul_ | i'll do ezc | 09:34 |
| paul_ | as we didn't do all of it | 09:34 |
| paul_ | (fwiw | 09:34 |
| paul_ | only reason we've not updated ezc is they've not changed the graphing module | 09:35 |
| paul_ | and iirc, the things we needed, i'd already included from their svn) | 09:35 |
| dhx_m | oops too late | 09:36 |
| CIA-21 | Mantisbt: hickseydr * r2b04a3a38d23 /library/README.libs: List correct version of ADOdb as 5.10 | 09:36 |
| CIA-21 | Mantisbt: hickseydr master-1.2.x * r838b3b3ae7ed /library/ (151 files in 25 dirs): Upgrade ezComponents from 2009.1.2 to 2009.2.1 | 09:36 |
| dhx_m | I did realise we only took part of ezC :) | 09:36 |
| CIA-21 | Mantisbt: hickseydr * rb05d56b7f4cd /library/ (151 files in 25 dirs): Upgrade ezComponents from 2009.1.2 to 2009.2.1 | 09:36 |
| CIA-21 | Mantisbt: hickseydr master-1.2.x * re24a2bc828de /library/README.libs: List correct version of ADOdb as 5.10 | 09:36 |
| paul_ | also | 09:36 |
| paul_ | you've changed linefeeds in the phpmailer stuff | 09:36 |
| dhx_m | that's the same as upstream | 09:36 |
| dhx_m | which IMO is better than us modifying it | 09:36 |
| paul_ | not if i'd already done php5.1 ;p | 09:37 |
| paul_ | what it probably means is | 09:37 |
| paul_ | you've taken a different tarball then my scripts | 09:37 |
| paul_ | so when I next sync it | 09:37 |
| paul_ | it'll go back ;/ | 09:37 |
| dhx_m | ? | 09:37 |
| dhx_m | so ezC was patched? | 09:37 |
| paul_ | nah | 09:38 |
| dhx_m | README.libs didn't indicate that :p | 09:38 |
| paul_ | it was 'patched' at one point in that I'd taken svn code that was about to be released | 09:38 |
| paul_ | as opposed to a released version | 09:38 |
| dhx_m | ah ok well 2009.2.1 is still newer :p | 09:38 |
| paul_ | what I do however normally do | 09:38 |
| dhx_m | so it should include all the fixes you needed | 09:38 |
| paul_ | is | 09:39 |
| paul_ | I have library did on pc | 09:39 |
| paul_ | for original version | 09:39 |
| paul_ | for new version | 09:39 |
| paul_ | and for mantis version | 09:39 |
| paul_ | then 3-way merge any differences | 09:39 |
| dhx_m | we really need to create a separate directory of patches | 09:39 |
| paul_ | joh doesn't like nested repo's | 09:39 |
| dhx_m | to make it easier to upgrade between versions (just apply the patches) | 09:39 |
| paul_ | so now that you've applied the same version of phpmailer with different line feeds | 09:40 |
| dhx_m | it's a different version (5.1 vs 5.02) | 09:40 |
| paul_ | it's likely it'll make my 3-way merge more difficult | 09:40 |
| paul_ | mm | 09:40 |
| paul_ | I thought it was 5.1? | 09:40 |
| paul_ | 7 hours ago David Hicks Upgrade PHPMailer from 5.02 to 5.1 blob | commitdiff | 09:41 |
| paul_ | 2009-12-18 Paul Update phpmailer to 5.1 blob | commitdiff | diff to current | 09:41 |
| paul_ | in fact now i remember | 09:41 |
| paul_ | you updated phpmailer/adodb | 09:42 |
| paul_ | but didn't include our mssql addob patches | 09:42 |
| paul_ | so I reverted both, then updated | 09:42 |
| dhx_m | oh yeah the diff is just whitespace changes ;/ | 09:42 |
| dhx_m | I went off README.libs which hadn't been updated | 09:42 |
| dhx_m | but still, I think it's best to keep upstream's original files where possible | 09:42 |
| paul_ | I suspect those got lost in the reverting reverts | 09:42 |
| paul_ | upstream iirc, do a .tar.gz and a .zip | 09:43 |
| dhx_m | especially when we say in README.libs that it's unpatched | 09:43 |
| paul_ | and a .bx2 or whatever | 09:43 |
| dhx_m | I used the .tar.gz | 09:43 |
| paul_ | with different linefeeds | 09:43 |
| paul_ | I've always done the updates as a 3-way merge as: | 09:44 |
| paul_ | a) we tend to sneak changes/fixes in | 09:44 |
| paul_ | b) 'adodb' can't do a release | 09:44 |
| paul_ | or more, adodb is a bit random with what gets changed | 09:44 |
| paul_ | so it's nice to keep an eye on | 09:45 |
| dhx_m | both the .zip and .tar.gz use Windows line spacing for the 5.1 release | 09:46 |
| dhx_m | yep | 09:46 |
| dhx_m | I just don't like 3 way merges because from the perspective of users... they don't know how we've modified it differently to a standard version of the library | 09:47 |
| dhx_m | it's black magic | 09:47 |
| paul_ | sorry | 09:47 |
| paul_ | i tend to then move comlpete files | 09:47 |
| paul_ | and hopefully make a note in the library.readme file (which iirc you deleted :P) of how we modify them :P | 09:47 |
| dhx_m | it's still not as good as providing patches with the library | 09:48 |
| dhx_m | so people can see what patches we've applied | 09:48 |
| dhx_m | that way it is easier for distro maintainers to package mantisbt with system shipped versions of these libraries | 09:48 |
| paul_ | I prefer my solution | 09:48 |
| paul_ | stop using adodb | 09:48 |
| paul_ | :) | 09:48 |
| dhx_m | yes that is #1 :) | 09:48 |
| paul_ | I want to use moodle's setup | 09:49 |
| dhx_m | I was so surprised to see a new NuSOAP release btw! | 09:49 |
| paul_ | it's not really new | 09:49 |
| dhx_m | how many years has it been? | 09:49 |
| paul_ | look at what's changed ;p | 09:49 |
| dhx_m | I thought the project was dead | 09:49 |
| paul_ | well | 09:50 |
| paul_ | one thing that's changed is the linefeeds ;/ | 09:50 |
| paul_ | +- nusoap_xmlschema: replace regex function calls (ereg, eregi, split) with PCRE calls (preg_match, preg_split) (thanks Pier-Luc Duchaine)\r+- wsdl: replace regex function calls (ereg, eregi, split) with PCRE calls (preg_match, preg_split) (thanks Pier-Luc Duchaine)\r | 09:51 |
| paul_ | so change 1: linefeeds | 09:51 |
| paul_ | change 2: pcre replaces we'd already done | 09:51 |
| paul_ | change 3: soap_transport_http: remove call to deprecated function set_magic_quotes_runtime | 09:51 |
| paul_ | (we hadn't done) | 09:51 |
| paul_ | - | 09:52 |
| paul_ | nusoap_server: check that value is an object before calling get_class (thanks Pier-Luc Duchaine | 09:52 |
| paul_ | nusoap_client: do not assign the return value of new by reference (it is deprecated) (thanks Pier-Luc Duchaine | 09:52 |
| paul_ | ^ we'd done some of that i believe | 09:52 |
| *** Quits: fanno (~b3g@193.3.95.240) (Quit: Leaving.) | 09:53 | |
| paul_ | although, I am tempted to check later whether the linefeed change comes up | 09:53 |
| paul_ | as an issue for when I next update | 09:53 |
| paul_ | by re-downloading | 09:53 |
| dhx_m | they've fixed linefeeds... or broken them? | 09:57 |
| *** Quits: kirillka (~Miranda@global01.vester.ru) (Quit: kirillka) | 10:03 | |
| nuclear_eclipse | dhx_m: mdile | 10:03 |
| nuclear_eclipse | oops | 10:04 |
| dhx_m | :) | 10:04 |
| nuclear_eclipse | while you're here... | 10:04 |
| dhx_m | ishakq asod? | 10:04 |
| nuclear_eclipse | I have a point to make about db_get_table() | 10:04 |
| nuclear_eclipse | it's a step farward, but it literally breaks every plugin written for 1.2... | 10:05 |
| nuclear_eclipse | I'd like to see a compromise in place | 10:05 |
| dhx_m | well the real issue is that plugins need to be branched for 1.2.x and 1.3.x | 10:05 |
| dhx_m | IMO | 10:06 |
| dhx_m | other things could change in the core (bug fixes, improvements, etc) that would cause the same problem | 10:06 |
| nuclear_eclipse | eg. what if we made the new implementation a separate function, and update the references in mantis to use the new function name, and then create a compat version of db_get_table that will act as a backward-compatible layer on top of the new method? | 10:06 |
| dhx_m | potentially... but then we start introducing code smell (aka #ifdef hell in other programming languages) | 10:08 |
| nuclear_eclipse | well, not really | 10:08 |
| nuclear_eclipse | I'm thinking something like: | 10:08 |
| dhx_m | at some point in the future we'd drop the old db_get_table() function... so all we're doing is delaying the inevitable | 10:08 |
| dhx_m | when plugin authors should really be forking their plugins to match the MantisBT branches | 10:09 |
| dhx_m | IMO we only need to maintain backwards compatibility in minor versions (1.x.?) but things can change in 1.?.x versions | 10:09 |
| dhx_m | and in many ways I'd prefer that plugin authors keep up to date with the latest core developments | 10:10 |
| dhx_m | for instance, if we were to see daryn's proposed filter changes in 1.3.x, that'd also break plugin compatibility | 10:10 |
| nuclear_eclipse | why would it? | 10:11 |
| dhx_m | well I assume it would as some filter IDs are modified | 10:11 |
| nuclear_eclipse | his filter changes sholudn't break the existing filter/columns events, afaik | 10:11 |
| daryn | the filter id's shouldn't matter. i am using the plugin model as an example but it is still possible i could break it | 10:13 |
| dhx_m | my point really is that if we wanted to redesign part of MantisBT... are we going to be held back by the need to maintain backwards compatibility for plugins? | 10:14 |
| dhx_m | IMO the plugins need to be branched to match each version of MantisBT (stable and development) | 10:14 |
| dhx_m | and then we guarantee to plugin authors that minor 1.x.x releases won't break compatibility | 10:14 |
| nuclear_eclipse | well, my point is why are we completely breaking compatibilty for silly things like db_get_table()? | 10:14 |
| dhx_m | but 1.x releases may | 10:14 |
| nuclear_eclipse | it's one thing to break compat on a large change, but when you could maintain compatibility just by adding a small, simple function to the API, it seems like a no-brainer to me... | 10:16 |
| dhx_m | is there a plugin_get_table command? | 10:16 |
| nuclear_eclipse | ie, I'd like to see a db_table() function than behaves like plugin_table, and then keep db_get_table() at least for a while so we're not completely breaking old plugins on our first feature release... | 10:17 |
| nuclear_eclipse | it just seems counter-intuitive to not want to minimize effort for plugin developers | 10:17 |
| nuclear_eclipse | all of my plugins would work 100% in 1.3-dev right now if not for the changes to db_get_table(), and than change doesn't really even serve a purpose other than cleaning up a bit of code that nobody really looks at =\ | 10:19 |
| dhx_m | the problem I see with that approach is we're indefinitely delaying changes | 10:19 |
| nuclear_eclipse | no, the point is that we're cleaning up the codebase without affecting plugins | 10:19 |
| dhx_m | and while db_get_table is insignificant... if we have multiple changes like this, you get inconsistencies in codebases | 10:20 |
| dhx_m | so one plugin might use db_get_table(), core might use db_table(), etc | 10:20 |
| dhx_m | which sucks if you're wanting to grep for all instances of db_get_table | 10:20 |
| dhx_m | for instance | 10:20 |
| nuclear_eclipse | we don't need to maintain the old implementation of db_get_table(), just make it strip mantis_ and _table from the param and tehn pass it to db_table() with the new implementation | 10:20 |
| dhx_m | yep but it's two ways of achieving the same outcome | 10:20 |
| dhx_m | so at some point of time we're going to have to make plugin authors update | 10:21 |
| dhx_m | I agree that giving plugin authors one release grace may work | 10:21 |
| nuclear_eclipse | yes, but tbh, if you're asking plugin authors to maintain forks/branches of their codebase for every feature release of Mantis, you'll soon not have any plugin authors left | 10:21 |
| nuclear_eclipse | not even Mozilla does that | 10:22 |
| dhx_m | but if we've got big API changes (bug_api OO overhaul last year) then plugins will need to update anyway | 10:22 |
| nuclear_eclipse | yes, but that's a feature change | 10:22 |
| dhx_m | Mozilla plugins are specified by authors to work on specific version ranges of Firefox | 10:22 |
| nuclear_eclipse | there's a difference between a feature change and a API change for sake of API change | 10:22 |
| dhx_m | so many of them don't currently work with 3.7 for instance | 10:22 |
| dhx_m | it's essential that plugin authors know how to branch their plugins against 1.2.x and 1.3.x so we can't really avoid that complexity | 10:24 |
| giallu | oh | 10:24 |
| nuclear_eclipse | my point is just that it would be a very simple change to support backward compatibility, so why aren't we doing it? | 10:24 |
| nuclear_eclipse | hi giallu | 10:24 |
| giallu | so we're already at the "plugin hell" stage I predicted some time ago ? ;) | 10:24 |
| giallu | Hi John | 10:24 |
| nuclear_eclipse | giallu: only because of dhx_m ;) | 10:25 |
| giallu | and everbody | 10:25 |
| nuclear_eclipse | giallu: did you get my email about mantisbot? | 10:25 |
| dhx_m | I guess I'm just taking a very polarised view on the issue because I'm thinking ahead for when plugin hell really does become an issue | 10:25 |
| giallu | yeh, I was out of town, just got back to mail mails today | 10:25 |
| nuclear_eclipse | ok | 10:25 |
| dhx_m | the fundamental issue is... do we train our plugin authors the "right way" (branching, keeping their plugins updated continuously rather than after a release, etc) | 10:26 |
| nuclear_eclipse | dhx_m: IMO, stuffing back-compat is not how you solve plugin hell... | 10:26 |
| nuclear_eclipse | well, plugin authors will never do things the "right way" in the first place, so try your damnedest | 10:27 |
| nuclear_eclipse | to make it easy for them | 10:27 |
| dhx_m | well the solution IMO is to "train" plugin authors to keep tabs on core development so they can update their plugins to match changes in core as they happen | 10:27 |
| dhx_m | rather than allow plugin authors to wait for 1.3.0 and then be faced with huge changes (with users annoyed that the plugin won't work with the new stable release) | 10:27 |
| nuclear_eclipse | and as I'm working on plugins, I don't want to be porting every single commit between multiple branches just because core decided to change an API method without a real feature attached to it ... | 10:28 |
| dhx_m | can we encourage more plugins to become part of the core project? | 10:28 |
| nuclear_eclipse | please no | 10:29 |
| nuclear_eclipse | as few plugins in core as possible | 10:30 |
| dhx_m | won't that reduce the quality of those plugins and make it harder for users to use? | 10:30 |
| *** Quits: daryn (~INTERACT\@rrcs-76-79-4-2.west.biz.rr.com) (Remote host closed the connection) | 10:30 | |
| dhx_m | there is no longer a central bug tracker and repository for all the plugins to use | 10:31 |
| nuclear_eclipse | keeping plugins out of core means that core doesn't get clogged with a lot of cruft | 10:31 |
| *** Quits: Cupertino (~Cupez@unaffiliated/cupertino) (Quit: I give up...) | 10:31 | |
| nuclear_eclipse | besides, the whole point of mantisforge was originally that paul'd be adding things for all plugin authors to use in a central location | 10:32 |
| dhx_m | well I didn't want to include every crap plugin... just the high quality ones which have plenty of users and developer interest | 10:32 |
| nuclear_eclipse | although it seems he's lost track of that | 10:32 |
| nuclear_eclipse | dhx_m: at that point, it becomes politics, and that's even worse than cruft | 10:32 |
| paul_ | dhx_m/nuclear_eclipse | 10:32 |
| paul_ | db_get_Table | 10:32 |
| *** Joins: daryn (~INTERACT\@rrcs-76-79-4-2.west.biz.rr.com) | 10:32 | |
| paul_ | i'm quite confident that we'll end up with seperate plugins for 1.34 | 10:33 |
| *** Quits: dhx_m (~anonymous@c122-107-157-71.eburwd5.vic.optusnet.com.au) (Ping timeout: 248 seconds) | 10:36 | |
| nuclear_eclipse | dhx get mad at me? | 10:41 |
| paul_ | ya | 10:41 |
| paul_ | anyway | 10:42 |
| paul_ | I still want to pull adodb out at some point | 10:42 |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 10:48 | |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 265 seconds) | 11:17 | |
| *** Quits: rolfkleef (~rolf@82-204-82-162.fttx.bbeyond.nl) (Ping timeout: 258 seconds) | 11:34 | |
| paul_ | nuclear_eclipse: still there? | 11:44 |
| *** Joins: moto-moi (~hylke@cara.xs4all.nl) | 11:51 | |
| nuclear_eclipse | yep | 11:59 |
| paul_ | need ldap setup on mantisbt.org | 12:04 |
| paul_ | tbh | 12:04 |
| paul_ | need ubuntu on mantisbt.org | 12:04 |
| daryn | uh oh...another ubuntu convert | 12:04 |
| paul_ | ldap | 12:05 |
| *** Joins: dhx_m (~anonymous@c122-107-157-71.eburwd5.vic.optusnet.com.au) | 12:12 | |
| nuclear_eclipse | welcome back dhx_m | 12:13 |
| dhx_m | nuclear_eclipse: yep... I accidently used the magic sysrq key ;/ | 12:13 |
| nuclear_eclipse | did you ragequit on me? :P | 12:13 |
| dhx_m | well long story... I ran out of memory so did SysReq+O to use the OOM killer | 12:13 |
| nuclear_eclipse | how do you run out of memory on a system with virtual memory? | 12:14 |
| dhx_m | for some reason I thought SysRq+O was "out of memory killer" when it is actually "shut off the system immediately" :p | 12:15 |
| dhx_m | I don't use virtual memory heh | 12:15 |
| nuclear_eclipse | doh | 12:16 |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 260 seconds) | 12:17 | |
| nuclear_eclipse | anyways | 12:17 |
| nuclear_eclipse | dhx_m: http://mantis.pastebin.com/KgkC8m9L | 12:18 |
| dhx_m | preg_match seems fairly heavyweight | 12:19 |
| nuclear_eclipse | well, that's just the basic idea | 12:19 |
| nuclear_eclipse | I'm sure there's a quicker way | 12:20 |
| nuclear_eclipse | ie, a pair of substr calls? | 12:20 |
| dhx_m | I won't mind if you make this change... I'm just arguing from the perspective that plugin authors should be updating their plugins to match the latest core development | 12:20 |
| dhx_m | if they don't, their plugins will probably die off shortly when they realise how behind they are with getting their plugins ready to work on 1.3.x | 12:21 |
| dhx_m | I guess it's two different development models | 12:21 |
| dhx_m | I'd be much happier if we had a deprecated_api.php containing deprecated stuff | 12:21 |
| dhx_m | and/or some sort of warning/log system that logs when deprecated stuff is used | 12:21 |
| nuclear_eclipse | well, I generally agree; this specific case just makes things a pain in the ass because it's more or less requiring you to maintain to nearly identical copies of your plugin for no feature change... =\ | 12:22 |
| dhx_m | so that plugin authors can quickly get an idea of what they need to change | 12:22 |
| dhx_m | I guess... but it's a problem plugin developers will face in the future | 12:22 |
| dhx_m | so if they don't address it now, they'll still have to address it in the future | 12:23 |
| nuclear_eclipse | well, it's a different class of problem, is what I'm getting at | 12:23 |
| nuclear_eclipse | if we change Bug API to restructure everything, that's a feature change, and requires a rework of code everywhere that uses it | 12:23 |
| nuclear_eclipse | changing the parameter to db_get_table to drop the leading/trailing string doesn't affect *how* it's used, it just expects different strings now | 12:24 |
| nuclear_eclipse | so you'd end up with two identical branches, save for a 1-line everywhere you need to access a core table, which btw is enough to break the ability to cherry-pick changes between those branchs if the change is near that line... | 12:25 |
| nuclear_eclipse | meaning it would a big pain in the ass to have to maintain those two branches that are otherwise identical | 12:25 |
| nuclear_eclipse | if there was a feature change of some sort, you're not going to need to cherry-pick commits 1:1 between otherwise-identical branches | 12:26 |
| dhx_m | well at the moment most of the plugins aren't really versioned | 12:28 |
| dhx_m | so there is no difference between development/stable versions | 12:29 |
| dhx_m | I would expect that MantisBT plugins are forced to follow the development cycle of the MantisBT core itself | 12:29 |
| nuclear_eclipse | I would generally agree, yes | 12:29 |
| dhx_m | ie. stable branch for bugfixes, development branch for new features | 12:29 |
| dhx_m | otherwise it becomes unwieldy for plugin authors to ensure that their plugins work properly on multiple major versions of MantisBT | 12:30 |
| nuclear_eclipse | but atm, other than db_get_table, there isn't any need for that yet, and plugins most certainly aren't going to care much about 1.3 until we actually get to a point of releasing some sort of beta/RC | 12:30 |
| dhx_m | as you said, backporting becomes a PITA | 12:30 |
| dhx_m | I agree... all I'm saying is that these changes are simply delaying a problem rather than fixing it :) | 12:31 |
| nuclear_eclipse | my biggest issue is that whenever I switch to maste branch in git, my plugins die because of db_get_table... =\ | 12:31 |
| dhx_m | (temporary fix, not a long term fix) | 12:31 |
| dhx_m | yep I understand | 12:32 |
| nuclear_eclipse | well, ultimately, if db_get_table is the only thing that breaks plugins from 1.2 to 1.3, then we look like asshats... =\ | 12:32 |
| dhx_m | I agree with that completely | 12:32 |
| dhx_m | but I doubt it'll be the only thing :) | 12:32 |
| dhx_m | is there a way to mark functions as deprecated? | 12:33 |
| dhx_m | so that plugin authors know a better alternative exists? | 12:33 |
| nuclear_eclipse | not really, other than in the comments above the function | 12:33 |
| dhx_m | although it doesn't solve the problem | 12:33 |
| dhx_m | as they CAN'T switch to using the new feature as it'll stop their plugin working against 1.2.x | 12:34 |
| dhx_m | so they'll forever be using deprecated functions | 12:34 |
| nuclear_eclipse | right, either the plugin needs to have a bunch of if/else statements against the mantis version, or they need to maintain branches of the plugin; either option is painful | 12:35 |
| nuclear_eclipse | I just want to reduce the pain wherever we can | 12:35 |
| nuclear_eclipse | because tbh, most of my development these days happens in plugins | 12:35 |
| nuclear_eclipse | but getting to the above mention of asshats, I'd like to hit quicker release cycles, so who knows what will or won't hit 1.3 | 12:36 |
| dhx_m | I'm going to hit anyone who does PHP #ifdef in their plugins :p | 12:37 |
| dhx_m | yep quicker release cycles are good IMO | 12:38 |
| nuclear_eclipse | I'm tempted to say we should shoot for a January/July, 6-month release cycle, but we always come back to the problem of not having enough developer time to handle quick RC | 12:38 |
| paul_ | db_table/ db_get_table | 12:38 |
| paul_ | TBH | 12:38 |
| paul_ | who cares | 12:38 |
| dhx_m | well 1.3.x has a new admin/check/ script and a few other token "features" (hardly) | 12:38 |
| nuclear_eclipse | ie, if we drop an RC, we don't respond quick enough to bug reports against the RC to get a stable version out | 12:38 |
| paul_ | for 1.3 | 12:38 |
| paul_ | they'll probably need to update anyway | 12:39 |
| paul_ | nuclear_eclipse: part of the problem with that is we have 1000+ bug reports | 12:39 |
| nuclear_eclipse | paul_: I care, because db_get_table is the only change in 1.3 that breaks my plugins, otherwise they work in both 1.2 and 1.3 just fine | 12:39 |
| dhx_m | I'm really just worried about having plugin authors who don't understand the need to maintain different branches of their plugin (for different versions of MantisBT) | 12:39 |
| paul_ | I want to replace adodb ;p | 12:40 |
| paul_ | that'll break your plugins :P | 12:40 |
| dhx_m | and as such they'll rely upon deprecated MantisBT features as they're locked into them by the need to support older MantisBT versions | 12:40 |
| nuclear_eclipse | paul_: that will break everything | 12:40 |
| nuclear_eclipse | dhx_m: I don't think there's any good solution for that period, other than letting stupid developers release crappy stuff =\ | 12:41 |
| dhx_m | well if we have 6 month major releases of MantisBT | 12:42 |
| paul_ | nuclear_eclipse: yes ;) | 12:42 |
| paul_ | nuclear_eclipse: hence dont care about db_table/db_get_table :P | 12:42 |
| dhx_m | and X months bugfixing support for older releases... and Y months security support... (or whatever) | 12:42 |
| nuclear_eclipse | paul_: you're gonna have to at least keep the adodb datadict stuff, right? | 12:43 |
| paul_ | can we agree minimum php version for 1.3.x? | 12:43 |
| dhx_m | 5.2? | 12:43 |
| paul_ | nuclear_eclipse: fuck knows - i've got an idea of what i want to use / do | 12:43 |
| paul_ | just not had time to look | 12:43 |
| paul_ | however | 12:43 |
| paul_ | it's not really the datadict stuff i'm looking at 'fixing' | 12:44 |
| dhx_m | plugin developers would be locked into out 6 monthly cycle too | 12:44 |
| paul_ | so yes, I think if we changed, we'd keep existing stuff too | 12:44 |
| dhx_m | hence it works best for them if they release new features to coincide with MantisBT core releases | 12:45 |
| nuclear_eclipse | paul_: as long as the datadict/schema definitions stay the same, it shouldn't break plugins then | 12:45 |
| dhx_m | rather than try to add new features to their plugins for 1.2.x releases | 12:45 |
| dhx_m | again it comes back to time and resources... it's very expensive to maintain multiple branches | 12:45 |
| paul_ | nuclear_eclipse: want to change how we handle queries a bit ideally | 12:45 |
| dhx_m | which is why we dropped 1.1.x :p | 12:45 |
| paul_ | hmm, hometime soon | 12:46 |
| nuclear_eclipse | paul_: changing from adodb to XYZ wouldn't need to change our existing database_api... | 12:46 |
| nuclear_eclipse | otherwise wth was all the work for in coming up with db_query_bound if you're just going to scrap it? | 12:47 |
| dhx_m | do we ever use db_query_bound with boundaries? | 12:47 |
| nuclear_eclipse | bound = bound paramaters | 12:48 |
| nuclear_eclipse | and we do use that all the time :P | 12:48 |
| dhx_m | ah, not "paged results"? | 12:48 |
| paul_ | nuclear_eclipse: my issue is trying to work out how to use the new Microsoft driver for sql | 12:48 |
| nuclear_eclipse | paged results have been possible with normal db_query for as long as it's been around | 12:48 |
| dhx_m | ah :) | 12:49 |
| paul_ | I need to look at the new CTP of http://blogs.msdn.com/sqlphp/ | 12:49 |
| paul_ | the old version aka v1 | 12:49 |
| paul_ | wanted to know data types | 12:49 |
| paul_ | aka db_query_bound doesn't help :( | 12:49 |
| paul_ | at same time, i've been thinking more and more that moodle's db layer supports the db we are trying to support | 12:50 |
| paul_ | and abstracts off INSERT queries into some function i.e. equiv of db_insert(table, values) or something | 12:51 |
| paul_ | tbh, first things first | 12:51 |
| paul_ | need to look at what MS have done | 12:51 |
| nuclear_eclipse | paul_: if it needs to know data types, can't you figure that out just by using php's typeof() ? | 12:51 |
| paul_ | need to have another look tbh | 12:54 |
| paul_ | and also look against the new version | 12:54 |
| paul_ | bbiab | 12:55 |
| nuclear_eclipse | dhx_m: I pushed a quick commit to http://git.mantisforge.org/w/mantisbt/jreese.git?a=shortlog;h=refs/heads/db_table | 12:58 |
| nuclear_eclipse | moves db_get_table to db_table, and covers updating all usage of db_get_table to db_table | 12:59 |
| dhx_m | nuclear_eclipse: looks good to me in terms of the patch | 12:59 |
| nuclear_eclipse | only concern would be finding a faster version of preg_match | 12:59 |
| dhx_m | wait no | 13:00 |
| dhx_m | you have defined function db_table(...) twice :) | 13:00 |
| nuclear_eclipse | lol | 13:01 |
| nuclear_eclipse | how did php not complain when I tested it...? | 13:01 |
| dhx_m | also is it possible to add a comment to say that the function may be removed in favour of db_table() in the near future? | 13:01 |
| dhx_m | so that people clearly know which one to use in preference? | 13:01 |
| daryn | add @deprecated to the function comment for db_get_table | 13:03 |
| nuclear_eclipse | yeah, I gotta get some lunch, I'll take care of that, add some better comments, etc when I get back | 13:03 |
| dhx_m | also check the final patch against http://git.mantisbt.org/?p=mantisbt.git;a=commit;h=c8f355d04fb5120545d890ea2a7b2e2b6afc9b6c | 13:05 |
| dhx_m | to make sure you get all the required files :) | 13:05 |
| *** Quits: wolog (~wolog@195.6.104.193) (Remote host closed the connection) | 13:11 | |
| *** Joins: philip_ (~philip_@c-76-104-185-25.hsd1.wa.comcast.net) | 13:18 | |
| *** Quits: philip_ (~philip_@c-76-104-185-25.hsd1.wa.comcast.net) (Changing host) | 13:18 | |
| *** Joins: philip_ (~philip_@unaffiliated/philip) | 13:18 | |
| nuclear_eclipse | dhx_m: good call, I used sed, but didn't think about files in admin/api/plugins | 13:25 |
| philip_ | allowing anonymous comments to bug reports is allowed, right? | 13:26 |
| philip_ | if so, what sort of spam measures are implemented? | 13:26 |
| nuclear_eclipse | philip_: none | 13:27 |
| philip_ | so anonymous comments cannot be allowed? | 13:27 |
| nuclear_eclipse | they're allowed only if you create the anonymous account with permission to attach notes | 13:27 |
| philip_ | in which case users would need to login as that user? | 13:28 |
| nuclear_eclipse | ie, if the access level you assign to the anonymous account is high enough to attach bugnotes, then they can attach bugnotes | 13:28 |
| philip_ | hmm, so essentially the answer is no, it's not allowed | 13:28 |
| nuclear_eclipse | once you enable anonymous access and attach it to the account you created, any user that's not logged in will be "using" the anonymous account you created | 13:29 |
| *** Joins: fanno (~Morten@90.184.93.233) | 13:29 | |
| philip_ | just exploring options for php.net, we sorta require anonymous users, but worry about spam | 13:29 |
| nuclear_eclipse | philip_: with the plugins in 1.2, I've created an Akismet plugin that should help to prevent spam, but I never was able to get their API to | 13:30 |
| nuclear_eclipse | ... | 13:30 |
| nuclear_eclipse | I couldn't get the Akismet API to actually return a result other than ham, so I still ended up with spam on my site | 13:30 |
| philip_ | not a fan of captcha? :) | 13:31 |
| nuclear_eclipse | I'd be happy to receive patches to the plugin though to get it working | 13:31 |
| nuclear_eclipse | philip_: captcha is too easy to break | 13:31 |
| dhx_m | philip_: did I understand correctly that php.net is looking to upgrade their bug tracker? | 13:31 |
| philip_ | only preliminary, but yes | 13:32 |
| philip_ | maintaining a custom solution isn't as fun anymore, like it used to be | 13:32 |
| *** Joins: Watergad (~Watergad@watergad.pereslavl.ru) | 13:33 | |
| nuclear_eclipse | philip_: captcha should technically be possible with plugins too | 13:33 |
| nuclear_eclipse | I just figured Akismet was hte easier/cheaper target :P | 13:33 |
| philip_ | another option is to 'hide' comments, and allow any logged in user to 'unhide' or mark as spam | 13:33 |
| philip_ | if that makes sense | 13:33 |
| dhx_m | philip_: I suppose you're interested in selecting a bug tracker based on PHP? | 13:34 |
| nuclear_eclipse | I was planning to implement a "mark as spam" option, I just never got around to it | 13:34 |
| philip_ | yes, we like simple api/gui and php based | 13:34 |
| nuclear_eclipse | I ended up just removing anonymous reporting/commenting | 13:34 |
| philip_ | i like anonymous usage as it lowers the barrier of reporting | 13:35 |
| nuclear_eclipse | didn't have time to try and deal with spammers | 13:35 |
| philip_ | i've at least said "eh, no thanks" when having to create accounts just to report a simple bug | 13:35 |
| nuclear_eclipse | philip_: basically, anonymous reporting/commenting is definitely possible; I've done it on other sites before | 13:36 |
| nuclear_eclipse | it's just the issue of spam that stopped me | 13:36 |
| philip_ | are you the main developer? i found it difficult to determine who works on mantis | 13:36 |
| Watergad | dhx_m: you may patch and close #11011 . Still, upgrade to a new version is always a good occasion to find and fix something (: | 13:36 |
| nuclear_eclipse | philip_: I'm probably the one with the most visibility these days since I cut the releases, but there isn't really any one person in charge | 13:37 |
| nuclear_eclipse | I am the one who wrote the plugin system though, so if you're interested, I can help you put together a plugin that will add a captcha to the report/comment forms | 13:38 |
| philip_ | if we decided to use mantis, do you know of people who'd be willing to help convert? | 13:38 |
| dhx_m | philip_: the good thing is that the MantisBT project has a number of "key developers" so it is less likely to pack up and go home :) | 13:38 |
| dhx_m | philip_: I'd be interested in helping | 13:39 |
| nuclear_eclipse | philip_: I'd be happy to help out | 13:39 |
| nuclear_eclipse | :) | 13:39 |
| philip_ | we have an auth system written in the 90's | 13:39 |
| dhx_m | I think you'll find most people would be interested in helping with such a high profile project :) | 13:39 |
| philip_ | although one day here will likely move to openid | 13:39 |
| philip_ | okay cool, don't get too excited, but it's possible | 13:39 |
| dhx_m | yep, just for your consideration of course | 13:40 |
| nuclear_eclipse | philip_: I handled a large migration of 14k issues from a proprietary tracker to mantisbt at my last place of employment | 13:40 |
| dhx_m | I think you'll find other projects would also be interested in helping | 13:40 |
| nuclear_eclipse | so I've got a bit of experience at the conversion game :P | 13:40 |
| philip_ | :) | 13:40 |
| philip_ | you've not seen our bugs codebase ;) | 13:41 |
| dhx_m | 51k | 13:41 |
| dhx_m | almost 52 it seems | 13:41 |
| nuclear_eclipse | actually, I ended up writing the one-off conversion script as a plugin in mantis itself :P | 13:41 |
| *** Joins: wolog (~wolog@AOrleans-152-1-85-26.w90-21.abo.wanadoo.fr) | 13:42 | |
| dhx_m | for a project the size of PHP I imagine the survivability of the bug tracker project is quite important (ie. frequently updated) | 13:42 |
| philip_ | i stumbled into an old mantis manual, linked to from http://www.mantisbt.org/wiki/doku.php | 13:42 |
| dhx_m | multiple developers who respond quickly to patches, etc | 13:42 |
| nuclear_eclipse | philip_: newest stuff is at http://docs.mantisbt.org/master/en/ | 13:43 |
| dhx_m | I guess it depends on what you want to do with the bug tracker | 13:43 |
| dhx_m | ie. patch reviewing, revision control system integration, etc | 13:43 |
| nuclear_eclipse | philip_: does PHP still use CVS? | 13:44 |
| dhx_m | SVN afaik | 13:44 |
| philip_ | svn | 13:44 |
| nuclear_eclipse | ok | 13:44 |
| dhx_m | http://svn.php.net/viewvc/ | 13:44 |
| nuclear_eclipse | then you can integrate the repository data with Mantis too :P | 13:44 |
| philip_ | also, we only integrated svn this last year (with the bug tracker)... heck, people couldn't add patches until this year | 13:44 |
| dhx_m | nuclear_eclipse: does SourceIntegration handle the importing of 300000 commits OK? :p | 13:44 |
| nuclear_eclipse | dhx_m: if it can handle 5000 revisions without hitting the PHP memory limit, then yes :P | 13:45 |
| philip_ | we scan commit messages for the likes of "PHP Bug" and directly insert into the bug mysql db | 13:45 |
| nuclear_eclipse | philip_: yep | 13:45 |
| nuclear_eclipse | the integration plugins I wrote will basically do the same thing | 13:45 |
| philip_ | people freaked out at the idea of allowing other tasks via -m, like closing bugs | 13:46 |
| dhx_m | nuclear_eclipse: oh yeah, I remember now... it can use a local svn binary for importing ;) | 13:46 |
| nuclear_eclipse | dhx_m: it chunks everything into groups of 200 commits at a time anyways ;) | 13:46 |
| nuclear_eclipse | philip_: check out our own tracker for an example of how it works with our git repo | 13:48 |
| philip_ | okay, thanks for the feedback, it sounds doable, maybe we'll be in touch :) | 13:48 |
| nuclear_eclipse | http://www.mantisbt.org/bugs/plugin.php?page=Source/index | 13:48 |
| nuclear_eclipse | or http://www.mantisbt.org/bugs/view.php?id=11764 | 13:48 |
| dhx_m | philip_: MantisBT also allows you to split your project into sub-projects, each with their own settings, user permissions, etc... so you could have a documentation project and documentation team, etc | 13:49 |
| dhx_m | that is one of the main reasons I started using MantisBT (ability to customise the whole thing per-project) | 13:49 |
| philip_ | we need that for pear, pecl, gtk, ... | 13:49 |
| nuclear_eclipse | gtk? | 13:50 |
| philip_ | but can, let's say, a pecl extension have a doc bug that'd show up in both? | 13:50 |
| dhx_m | and someone has created an EmailReporting plugin for MantisBT to let you report bugs via email... but I've never tried it | 13:50 |
| philip_ | php-gtk, not important :) | 13:50 |
| nuclear_eclipse | didn't know php-gtk existed | 13:50 |
| * nuclear_eclipse googles | 13:50 | |
| nuclear_eclipse | fancy :P | 13:51 |
| nuclear_eclipse | anyways | 13:51 |
| nuclear_eclipse | to answer your question, no | 13:51 |
| nuclear_eclipse | issues can only be put into one project | 13:52 |
| dhx_m | philip_: you can link two issues together with relationships (custom ones too if you like) | 13:52 |
| nuclear_eclipse | but you could clone the issue into the other project, and use the relationship to go between the two linked issues | 13:52 |
| philip_ | do you have a "needs to be documented" status? | 13:53 |
| nuclear_eclipse | the list of statuses is completely customizable | 13:53 |
| philip_ | so bug might go like: open->verified->assigned->closed->needs to be documented (open)->ntbd (closed) | 13:53 |
| nuclear_eclipse | same with just about every list-based option on a bug | 13:53 |
| dhx_m | philip_: you can create a custom workflow such as: new, confirmed, assigned, reviewed, documented, committed | 13:54 |
| Watergad | custom statuses and workflows are easy enough, I've tried ) | 13:54 |
| dhx_m | philip_: you could also have a custom field checkbox "Has been documented" on an issue, although it isn't as useful as including the "needs documentation" step in the workflow | 13:54 |
| nuclear_eclipse | you could still filter/sort on the custom field though | 13:55 |
| nuclear_eclipse | philip_: basically, mantis can be configured to fit your exact workflow :P | 13:55 |
| dhx_m | yep, but a workflow lets you enforce the need for documentation before a bug is closed | 13:56 |
| dhx_m | whereas a bug could be closed with/without the checkbox ticked | 13:56 |
| dhx_m | besides, including it in the workflow lets you get statistics on how many bugs need documentation, etc | 13:56 |
| dhx_m | and you can setup access levels/user groups so that your documentation team has to sign off on each bug as being properly documented | 13:57 |
| philip_ | people here panic when they hear words like workflow and process :) | 13:57 |
| dhx_m | understandable :) | 13:57 |
| philip_ | well okay, we'll see, sounds doable and the idea of help sounds great too | 13:58 |
| nuclear_eclipse | I could be wrong, but I believe we are the only php-based bug tracker that's both configurable and has a plugin system ;) | 13:59 |
| dhx_m | unfortunately MantisBT's documentation doesn't quite live up to the high standards of PHP's documentation heh :) | 13:59 |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 14:00 | |
| nuclear_eclipse | mainly because we don't have anywhere near the same amount of contributers as PHP does :P | 14:00 |
| Watergad | but it has quite understandable code ) | 14:00 |
| dhx_m | Watergad: spot on... self-documenting code :p | 14:00 |
| philip_ | you'd be surprised how few people actually contribute to php | 14:00 |
| dhx_m | When I've tried reading the source code I've found it quite hard to get my head around at first | 14:01 |
| Watergad | self-documenting is one of the most thing I liked in java when we met ) | 14:01 |
| dhx_m | it's a large software project so the required knowledge to get involved with developing PHP is relatively high | 14:02 |
| dhx_m | not that this is a problem other programming languages avoid | 14:02 |
| dhx_m | the one thing that has always impressed me about PHP is the online manual with user comments | 14:03 |
| philip_ | is your manual stored in docbook? | 14:03 |
| nuclear_eclipse | yep | 14:04 |
| dhx_m | yes | 14:04 |
| philip_ | those user comments were cutting edge back in the 90's, before blogs and the like | 14:04 |
| *** Joins: cobexer (~cobexer@188-23-206-32.adsl.highway.telekom.at) | 14:04 | |
| dhx_m | Watergad: thanks for the help on #11011, I'll look at it a bit later... I have to thoroughly test UTF-8 + custom fields | 14:05 |
| dhx_m | indeed, well ahead of the times | 14:05 |
| * paul_ spots philip_ | 14:05 | |
| dhx_m | even today it's still well ahead of the times | 14:05 |
| paul_ | philip_: didn't someone rewrite your bugtracker ? | 14:07 |
| philip_ | simply due to the large user base, and the poor souls who find themselves moderating them | 14:07 |
| philip_ | yes, it was sorta rewritten | 14:07 |
| dhx_m | philip_: how many users are signed up to bugs.php.net? | 14:07 |
| paul_ | philip_: we'd need to write a standard response plugin | 14:08 |
| paul_ | for you | 14:08 |
| philip_ | bugs.php.net does not have its own user system, it essentially uses svn credentials | 14:08 |
| dhx_m | paul_: nuclear_eclipse already created a standard response plugin... where have you been hiding? :p | 14:08 |
| paul_ | ;p | 14:08 |
| dhx_m | philip_: ah I see, so the user base is relatively small... the reason I ask is that MantisBT uses dropdown boxes to list usernames in some places, so 100k+ users = very large dropdown list | 14:09 |
| philip_ | i expect a fancy jquery based search thingee, which we have now | 14:09 |
| dhx_m | philip_: those are the sort of scalability issues we haven't had to address yet (although it wouldn't be too hard to fix it) | 14:09 |
| philip_ | to find people to assign to, likely about a 1000 names | 14:09 |
| paul_ | philip_: is there a mailing list thread on this btw? | 14:10 |
| philip_ | no it's just me looking around, nothing official | 14:10 |
| paul_ | i'd probably be willing to see how well we coped with whats in php's db + svn( or git mirror) | 14:11 |
| philip_ | i've found myself touching our bugs system more than anyone else, and am tired of it :) | 14:11 |
| * paul_ thought it was supposed to be agsoc2009 project? | 14:11 | |
| philip_ | it failed | 14:11 |
| paul_ | ahh | 14:11 |
| * paul_ wonders if there's a export of php bug db anywhere | 14:12 | |
| nuclear_eclipse | philip_: I'd be interested in a list of anything you guys would require that's not in mantis, would be a good list of things to push for in 1.3 perhaps? :P | 14:13 |
| philip_ | i have a db dump here, although it shouldn't be public | 14:14 |
| paul_ | nuclear_eclipse: does your plugin work fine with svn or better with git btw? | 14:14 |
| nuclear_eclipse | it works great with both git and svn | 14:14 |
| paul_ | philip_: can you sanitise the user passwords for anon reporters out of it + emails) | 14:14 |
| paul_ | nuclear_eclipse: so same? | 14:14 |
| nuclear_eclipse | more or less, yess | 14:14 |
| nuclear_eclipse | the websvn support is out of date | 14:14 |
| dhx_m | paul_: perhaps they have private issues too (security vulnerabilities)? | 14:14 |
| paul_ | was just wondering, as whilst I think it might have got out of sync, when they moved to svn | 14:15 |
| paul_ | someone set up a git mirror on github | 14:15 |
| nuclear_eclipse | but the core SVN import gathering works just fine | 14:15 |
| dhx_m | philip_: does the voting system see much use @ php.net? I was looking into the possibility of doing something similar with MantisBT recently | 14:16 |
| paul_ | dhx_m: iirc, you can't submit a private bug, but mail security@php.net... | 14:16 |
| philip_ | nobody looks at or cares about the votes | 14:16 |
| philip_ | imho :) | 14:16 |
| paul_ | can't see pierre or jani caring about votes | 14:16 |
| dhx_m | yep you're probably right... extra complexity and features that aren't very useful... simple = best in many cases :) | 14:17 |
| dhx_m | paul_: remind me of that PHP bug where someone was telling rasmus how PHP worked? :p | 14:18 |
| paul_ | heh | 14:18 |
| paul_ | http://bugs.php.net/bug.php?id=50696 | 14:19 |
| paul_ | philip_: we'd probably need to add some more ajax stuff | 14:20 |
| dhx_m | paul_: haha thanks :) | 14:20 |
| paul_ | i might be wrong, but I get the impression we don't have more ajax stuff already is people here aren't yet experts on it | 14:20 |
| daryn | it's coming paul | 14:21 |
| dhx_m | paul_: the problem with people adding AJAX stuff is that they often don't consider those who don't use AJAX | 14:21 |
| daryn | phptal + jquery = easy ajax | 14:21 |
| dhx_m | + security concerns | 14:21 |
| dhx_m | daryn: hi :) | 14:21 |
| daryn | howdy | 14:21 |
| daryn | looking at the current filter ajax...very ugly | 14:21 |
| dhx_m | daryn: is your latest PHPTAL work on mantisforge? | 14:22 |
| daryn | well...sort of | 14:22 |
| daryn | i posted some plugin updates recently but have some new stuff too. Also, i'll be pushing phptal to lib so the plugin won't be necessary | 14:22 |
| dhx_m | yep | 14:23 |
| paul_ | still not convinced about phptal for core | 14:23 |
| daryn | paul__ you'll never be convinced. :P | 14:23 |
| daryn | i'll push it to a mantisforge branch for comments first | 14:23 |
| nuclear_eclipse | tbh, I'm not much convinced either, mainly just because I'm not fond of phptal itself | 14:23 |
| daryn | probably just not enough experience with it | 14:24 |
| nuclear_eclipse | I just don't like some of their design decisions | 14:24 |
| paul_ | dinner brb | 14:24 |
| daryn | you mean the tal language in general? | 14:24 |
| daryn | or phptal | 14:25 |
| daryn | implementation | 14:25 |
| nuclear_eclipse | a) I don't like the whole XHTML thing, b) I don't like the way they deal with translations, and c) I don't like the inability to have PHP in the template | 14:25 |
| daryn | you can have php in the template | 14:25 |
| daryn | it doesn't have to be xhtml | 14:25 |
| dhx_m | why wouldn't you use XHTML? | 14:26 |
| daryn | and they have a translation interface to replace the default | 14:26 |
| nuclear_eclipse | because I'd rather use HTML4 and HTML5 | 14:26 |
| nuclear_eclipse | XHTML is just annoying | 14:26 |
| daryn | both are supported | 14:26 |
| dhx_m | HTML5 includes XHTML :) | 14:26 |
| nuclear_eclipse | yes/no | 14:26 |
| nuclear_eclipse | there are some XHTML stuffs that weren't put in as part of the HTML5 drafts | 14:27 |
| nuclear_eclipse | either way | 14:27 |
| dhx_m | essentially the only differences are ensuring every tag is closed and ensuring parameters are in the format field="value" | 14:27 |
| dhx_m | it's not like you have to worry about XSLT, XML, etc | 14:27 |
| nuclear_eclipse | dhx_m: no, XHTML specifies what attributes are allowed for each tag, which means you can't attach your own semantic attributes | 14:28 |
| daryn | sure you can... | 14:28 |
| *** Quits: Watergad (~Watergad@watergad.pereslavl.ru) (Quit: Just left.) | 14:28 | |
| nuclear_eclipse | not when I tried to use it in the past | 14:29 |
| nuclear_eclipse | the HTML validators would bitch and moan, and sometimes even Firefox would crap out with an XML error | 14:30 |
| nuclear_eclipse | that was half the point of XTHML afaik, to insist that only 100% valid markup would be rendered | 14:31 |
| dhx_m | one thing I wanted to do with MantisBT is remove the idea of "print pages" entirely | 14:32 |
| dhx_m | and instead use CSS stylesheets to achieve the same thing | 14:32 |
| nuclear_eclipse | daryn: I guess my biggest question is what's the benefit of using something like phptal instead of something like smarty, or even raw PHP templates? | 14:33 |
| daryn | raw php is extremely ugly first of all | 14:34 |
| nuclear_eclipse | <?= $foo ?> ftw? | 14:34 |
| daryn | no | 14:34 |
| dhx_m | the idea of PHPTAL is that you can edit the templates as if they were ordinary HTML files | 14:35 |
| daryn | smarty, i've used and it's ok | 14:35 |
| dhx_m | which makes it extremely easy to develop templates | 14:35 |
| nuclear_eclipse | dhx_m: you can do that in raw PHP too | 14:35 |
| nuclear_eclipse | <html>...<?= $var ?>...</html> | 14:35 |
| dhx_m | nuclear_eclipse: can you open that .php file in a web browser and have it render ok though? | 14:35 |
| daryn | templates are always more complicated than simply printing out vars | 14:35 |
| nuclear_eclipse | yes | 14:36 |
| daryn | when you start looping over arrays to print out columns, set attributes, etc. jumping in and out of php is just fugly and difficult to read | 14:36 |
| nuclear_eclipse | right, but my point is that when you get to needing to loop over a set of data to print out rows, displaying the raw template in your browser isn't going to do it any justice | 14:36 |
| dhx_m | nuclear_eclipse: but it will show $var instead of actual placeholder text? | 14:37 |
| daryn | actually with phptal it does because the designer can just put in example text which the parser just removes | 14:37 |
| nuclear_eclipse | that just seems like it's crowding up a template with so much cruft though | 14:37 |
| daryn | although tbh, i don't usually do that | 14:37 |
| daryn | right | 14:38 |
| nuclear_eclipse | `<a href="<?= $url ?>"><?= $name ?></a>` vs `<a tal:attributes="href value/getUrl" tal:content="value/getTitle"/>` though? | 14:38 |
| dhx_m | daryn: I've been thinking that to make this work out... we'd need to first change MantisBT page by page using PHP templates | 14:38 |
| nuclear_eclipse | that's just ungodly verbose | 14:38 |
| daryn | i understand the argument ' php is a templating language' but having used php, smarty, and phptal...i much prefer phptal | 14:39 |
| dhx_m | daryn: sort of like Victor's bug_view_inc.php approach where variables are set at the start... with HTML below | 14:39 |
| dhx_m | daryn: that way we don't get as many merge conflicts when/if it becomes time to merge any template branch | 14:39 |
| daryn | i don't know...i started that and it was just a pain... | 14:40 |
| daryn | we should be able to just convert a page at a time | 14:41 |
| dhx_m | nuclear_eclipse: as opposed to: <a href="<?php echo $t_value ?>"><?php echo $t_title ?></a> | 14:41 |
| nuclear_eclipse | well, you don't need the echo statement | 14:41 |
| dhx_m | oh I see... shorthand syntax :) | 14:41 |
| nuclear_eclipse | <?= ?> is the same as <?php echo ?> | 14:41 |
| dhx_m | well I don't mind that idea either | 14:42 |
| micahg | nuclear_eclipse: I thought shorthand was deprecated in 5.3 | 14:42 |
| nuclear_eclipse | micahg: afaik, that only applies to the shorthand <? ?> tags | 14:42 |
| daryn | http://fabien.potencier.org/article/34/templating-engines-in-php | 14:42 |
| nuclear_eclipse | <?= is still valid in 5.3 iirc | 14:42 |
| nuclear_eclipse | I just don't like how verbose everything is in TAL | 14:43 |
| daryn | of course he's pushing his own templating system | 14:43 |
| daryn | but some good points. nuclear_eclipse: i hear that...it still is much cleaner than the alternatives. | 14:44 |
| cobexer | another argument for a templating system is that you can easily add multiple templates to mantis - and as a user you can install templates without risking the server security when there is no php inside the templates ;) | 14:44 |
| nuclear_eclipse | and besides, who really needs/wants to edit templates outside of the app they were meant for? that seems like it's defeating the purpose :X | 14:44 |
| nuclear_eclipse | cobexer: TAL templates are still compiled to PHP though, so I'm not sure what the security concern would be? | 14:45 |
| dhx_m | cobexer: actually it's possible to execute PHP code within PHPTAL templates ;) | 14:45 |
| dhx_m | cobexer: but if you have access to change templates, running PHP code isn't so much of an issue anyway | 14:46 |
| dhx_m | nuclear_eclipse: you do have a point if we're going down the dynamic webpage AJAX path | 14:46 |
| nuclear_eclipse | daryn: I'm not meaning to discourage you, TAL is still lightyears better than no templates at all, and it's still a livable option to me | 14:47 |
| nuclear_eclipse | I just personally prefer others because there's less to type and/or remember as you're doing it :P | 14:47 |
| cobexer | yes i was not refering to TAL directly. they are compiled for speed imho. smarty templates are compiled also and can execute php afaik but phpBB are using smarty and php execution is disabled there i think | 14:47 |
| nuclear_eclipse | phpbb actually forked smarty for what it's worth | 14:48 |
| daryn | the middle of the page on that link I sent has some performance numbers | 14:48 |
| daryn | phptal is significantly faster than smarty | 14:49 |
| daryn | actually any of the others listed except the one the guy wrote | 14:49 |
| daryn | and they're close | 14:49 |
| nuclear_eclipse | did the tester set up smarty to cache the compiled templates? | 14:49 |
| micahg | nuclear_eclipse: apparently it hasn't been deprecated... | 14:49 |
| daryn | i believe so. he has tests with and without compilation, etc. | 14:49 |
| nuclear_eclipse | because iirc, smarty doesn't cache templates by default | 14:49 |
| daryn | and iirc caching was one of things he was looking at | 14:50 |
| nuclear_eclipse | I wonder if smarty either does more than phptal by default, or what, because compiling a template to PHP should mean they're all the same if you're generating the same output | 14:50 |
| nuclear_eclipse | unless the overhead of dealing with cached templates is comepletely unoptimized... dunno | 14:51 |
| dhx_m | HTML5's <datalist> is going to be VERY useful :) | 14:54 |
| nuclear_eclipse | dhx_m: too bad we'll be waiting another 6 years before we can actually *use* it... =/ | 14:54 |
| dhx_m | the problem I see with <datalist> is that you can't store that data in a separate file | 14:55 |
| dhx_m | hence for a 100k+ item <datalist> the client has to download it each time? | 14:55 |
| dhx_m | which kind of defeats the purpose | 14:55 |
| dhx_m | ps. ubuntu 10.04 release: http://www.acc.umu.se/technical/statistics/ftp/monitordata/img/Day.800.png | 14:56 |
| dhx_m | internet bandwidth usage++ :) | 14:56 |
| *** Joins: AzaToth (~azatoth@wikipedia/AzaToth) | 14:57 | |
| nuclear_eclipse | dhx_m: I've been on the torrent for that since noon :P | 14:58 |
| dhx_m | 20MB/sec upload here :) | 14:58 |
| dhx_m | could do more if the tracker gave me more peers | 14:59 |
| nuclear_eclipse | wow, I hate you | 14:59 |
| dhx_m | and if there weren't so many slow users (<1MB/sec) | 14:59 |
| nuclear_eclipse | I have to limit it 20kB/s, which is more than half my upload pipe, and is already affecting my ability to use the internet... | 14:59 |
| dhx_m | the DVDs just came out :) | 15:00 |
| nuclear_eclipse | but I'm on a "7mbps" cable line.... /rolleyes | 15:00 |
| dhx_m | nuclear_eclipse: I'm using a remote server :) | 15:00 |
| dhx_m | nuclear_eclipse: my home connection isn't 1gbps... I wish! :) | 15:00 |
| nuclear_eclipse | ah, yeah, if I used my server to torrent it, I could probably match that, and then immediately hit my node's bandwidth caps :P | 15:00 |
| dhx_m | haha | 15:02 |
| nuclear_eclipse | my server already uses about 100G of its monthly 200G cap... | 15:03 |
| nuclear_eclipse | wouldn't take much to put it over that limiit | 15:03 |
| dhx_m | yep | 15:03 |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 276 seconds) | 15:05 | |
| nuclear_eclipse | daryn: when do you think you'll have a reasonable branch online with phptal? | 15:05 |
| daryn | depends on what you want to see in it i guess... | 15:05 |
| paul_ | btw | 15:05 |
| nuclear_eclipse | if you've done all the work, I wouldn't argue about that being the major feature of 1.3 :P | 15:05 |
| dhx_m | nuclear_eclipse: not asking much heh :p | 15:05 |
| paul_ | ew ;) | 15:06 |
| paul_ | btw | 15:06 |
| paul_ | did we want to move where we host mantis tarballs for users to download? | 15:06 |
| dhx_m | nuclear_eclipse: no no, paul's elusive database changes are the major feature :P | 15:06 |
| paul_ | heh | 15:06 |
| nuclear_eclipse | daryn: I guess my biggest concern is how it interacts with the plugin system that's built on the expection of using a lot of sequential echo's :P | 15:06 |
| daryn | i'm trying to finish the filter changes...i told dhx_m i was shooting for (last) tue cob...i was a bit optimistic | 15:06 |
| paul_ | i'm *hoping* I wont need to do them | 15:07 |
| paul_ | dhx_m: can i merge lang api? | 15:07 |
| paul_ | you reviewed the logic before right? | 15:07 |
| dhx_m | yeah I think I said it looked good before :) | 15:07 |
| nuclear_eclipse | paul_: I'm not sure where we'd move the tarballs to | 15:07 |
| paul_ | k | 15:07 |
| dhx_m | but check with siebrand ;) | 15:07 |
| dhx_m | it'll break his stuff | 15:07 |
| dhx_m | (scripts) | 15:08 |
| paul_ | he was fine before | 15:08 |
| paul_ | but yea | 15:08 |
| nuclear_eclipse | sf.net may have a crappy admin ui, but it's good free hosting at least | 15:08 |
| paul_ | nuclear_eclipse: how much data transfer is it a month? | 15:08 |
| nuclear_eclipse | a lot | 15:08 |
| nuclear_eclipse | I dunno | 15:08 |
| paul_ | define a lot | 15:08 |
| dhx_m | daryn: yep one thing at a time... phptal conversion isn't quick or easy ;) | 15:08 |
| paul_ | heh | 15:08 |
| nuclear_eclipse | paul_: it sounds like sf.net is wanting to incorporate ohloh's automated upload system, so it should make generating and uploading release tarballs a cinch if that pans out | 15:09 |
| dhx_m | paul_: http://sourceforge.net/project/stats/detail.php?group_id=14963&ugn=mantisbt&type=prdownload&mode=alltime&file_id=0 | 15:09 |
| daryn | i'll take a look this weekend and see if i can come up with something. filter is gonna take that long anyway | 15:09 |
| nuclear_eclipse | ie, could have the buildrelease script generate an XML file and push the tarballs automatically to ohloh, and have then show up on sf.net, or something like that | 15:10 |
| paul_ | it's less than 100GB/month | 15:10 |
| paul_ | we could just serve em ourselfs tbh | 15:11 |
| dhx_m | I can provide 300GB/month @ 1Gbps West Coast USA | 15:11 |
| dhx_m | but why... | 15:11 |
| dhx_m | it's less reliable | 15:11 |
| dhx_m | maybe we could throw up a DNS round robin download.mantisbt.org that uses ohloh, sourceforge and other mirrors? | 15:12 |
| nuclear_eclipse | less reliable + less locality + less visibility | 15:12 |
| dhx_m | not sure what the pressing need is though | 15:12 |
| dhx_m | yep | 15:12 |
| paul_ | or just use google ;p | 15:12 |
| paul_ | there's probably an argument to upload mantis to code.google.com as well as sf.net ;p | 15:13 |
| nuclear_eclipse | ironically, sf.net is great for users, just not good for developers | 15:14 |
| paul_ | do they not have an api ? | 15:14 |
| nuclear_eclipse | nope | 15:14 |
| nuclear_eclipse | have to upload everything one at a time because they changed their interface to some stupid ajaxy crap | 15:14 |
| dhx_m | no more FTP uploads? | 15:15 |
| nuclear_eclipse | used to be able to SCP things as a lump, and then assign the uploads to a folder, but not anymore | 15:15 |
| nuclear_eclipse | but apparently they have yet another new interface in "beta", that I couldn't figure out either =\ | 15:16 |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 15:22 | |
| paul_ | i might put my mantisforge stuff onto a different box | 15:25 |
| *** Joins: giallu (~giallu@fedora/giallu) | 15:57 | |
| nuclear_eclipse | wb giallu | 16:07 |
| giallu | lo nuclear_eclipse | 16:07 |
| nuclear_eclipse | giallu: any idea why my supybot-mantis plugin won't connect to my tracker? | 16:07 |
| nuclear_eclipse | I have it running in an empty channel | 16:08 |
| nuclear_eclipse | well, had, rather | 16:08 |
| nuclear_eclipse | I booted windows to play a game :P | 16:08 |
| giallu | I remember I had a similar issue | 16:08 |
| nuclear_eclipse | I'm wondering if it has to do with some of the recent fixes to soap api? | 16:08 |
| giallu | in my case the culprit was in the soap config file (there is another one) | 16:09 |
| nuclear_eclipse | soap config? | 16:09 |
| nuclear_eclipse | :O | 16:09 |
| giallu | eh | 16:09 |
| giallu | look in api/soap | 16:09 |
| *** Joins: siebrand (~beis@sm.xs4all.nl) | 16:09 | |
| nuclear_eclipse | /mindblown | 16:09 |
| giallu | nuclear_eclipse, rememeber that was a separate project | 16:09 |
| nuclear_eclipse | lies :P | 16:09 |
| giallu | mc_config_defaults_inc.php | 16:10 |
| * nuclear_eclipse reboots into linux | 16:10 | |
| nuclear_eclipse | ok... | 16:15 |
| nuclear_eclipse | ah ha | 16:16 |
| nuclear_eclipse | $g_mc_readonly_access_level_threshold = REPORTER; | 16:16 |
| * nuclear_eclipse loads supybot | 16:17 | |
| nuclear_eclipse | it works! | 16:17 |
| giallu | eh :) | 16:17 |
| nuclear_eclipse | that's one thing solved | 16:18 |
| * paul_ sighs | 16:19 | |
| nuclear_eclipse | now, I want to also use this for a private bug tracker, and I only ever want the mantis plugin to respond in-channel, is there a way to do that? | 16:19 |
| paul_ | nuclear_eclipse: right, rewreite installer pls | 16:20 |
| nuclear_eclipse | giallu: is there a way to limit access like that using the normal supybot privilege sytem? | 16:24 |
| paul_ | yay, trunk seems broken ;/ | 16:24 |
| nuclear_eclipse | paul_: btw, source integration plugins don't work with anything but 1.2.x | 16:24 |
| paul_ | does that include trunk? | 16:24 |
| nuclear_eclipse | trunk == master == 1.3 | 16:25 |
| paul_ | source integration should work with master? ;p | 16:25 |
| nuclear_eclipse | paul_: this is why I was having that long discussion about db_get_table() earlier... | 16:25 |
| paul_ | i'm gonna go back to fixing installer this weekend | 16:25 |
| giallu | nuclear_eclipse, no, I'm not really familiar with that | 16:25 |
| giallu | I'd need to RTFM | 16:25 |
| paul_ | it's just pissed me off | 16:25 |
| nuclear_eclipse | giallu: now I just need to where the FM is located... | 16:26 |
| paul_ | nuclear_eclipse: fix it in git? | 16:26 |
| nuclear_eclipse | paul_: I was getting ready to in a short bit | 16:26 |
| paul_ | i mean in the plugin | 16:26 |
| nuclear_eclipse | well, "fixing" it either means breaking it for everyone (including me) who wants to use it with 1.2.x, or adding a lot of if/else code to handle db_get_table, or branching the plugin and maintaining all my features in two almost-identical branches... | 16:27 |
| giallu | uhm... every time I look for it some URL changed :( | 16:29 |
| nuclear_eclipse | maybe once 1.3 gets anywhere near a stable release, I'll consider branching the plugin, but right now, it'd be silly on my part to support 1.3 as a primary development target | 16:30 |
| paul_ | might need to adjust what i backup | 16:30 |
| paul_ | apparently backing up mantisforge.org box is 30gb | 16:30 |
| giallu | nuclear_eclipse, maybe debian is packaging the manuals? | 16:33 |
| nuclear_eclipse | I found some gzipped documentation on capabilities in /usr/share/doc/supybot, so we'll see where that gets me | 16:33 |
| paul_ | nuclear_eclipse: I assume it's just a find/replace for me though right? | 16:35 |
| *** Quits: cobexer (~cobexer@188-23-206-32.adsl.highway.telekom.at) (Read error: Connection reset by peer) | 16:35 | |
| nuclear_eclipse | yes/no, you have to change db_get_table('mantis_FOO_table') to db_get_table('FOO') | 16:35 |
| paul_ | btw, whats with 'readme.md'? .md? | 16:35 |
| nuclear_eclipse | sed could probably make it easy enough | 16:35 |
| nuclear_eclipse | .md == markdown | 16:35 |
| paul_ | why? ;/ | 16:36 |
| nuclear_eclipse | when I was hosting it on Github, that told Github what preprocessor to use when displaying it on the page | 16:36 |
| paul_ | ahh | 16:36 |
| paul_ | Unable to find a source of strong randomness for cryptographic purposes. | 16:36 |
| paul_ | dhx_m: | 16:36 |
| paul_ | gonna kill you soon :) | 16:36 |
| nuclear_eclipse | windows ftl, eh? :P | 16:36 |
| paul_ | it should work out of box | 16:37 |
| nuclear_eclipse | yet another reason I don't use 1.3 everywhere like I did while 1.2 was in development | 16:37 |
| *** Joins: rolfkleef (~rolf@urtica.xs4all.nl) | 16:37 | |
| paul_ | I bet dhx has disappeared now too | 16:39 |
| paul_ | nuclear_eclipse: i'm gonna assume that dhx will fix that before I get to coding this weekend | 16:40 |
| paul_ | as he might not like my fix :P | 16:40 |
| nuclear_eclipse | I doubt I'll like it either | 16:40 |
| paul_ | probably not :) | 16:41 |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Quit: Leaving.) | 16:41 | |
| paul_ | also | 16:42 |
| paul_ | your url stuff has broken stuff ;p | 16:42 |
| paul_ | I think | 16:42 |
| nuclear_eclipse | examples would be helpful | 16:43 |
| nuclear_eclipse | because I'm pretty sure it hasn't broken anything... ;) | 16:43 |
| paul_ | <link rel="stylesheet" type="text/css" href="http://127.0.0.1/admin/css/default.css" /> | 16:44 |
| paul_ | atm i've got it looking for the css folder under /admin | 16:44 |
| paul_ | it never used to do that ;p | 16:44 |
| paul_ | whats Branch Mappings ? | 16:44 |
| nuclear_eclipse | fancy stuff | 16:47 |
| paul_ | what was path to run the import from command line? | 16:47 |
| nuclear_eclipse | allows the plugin to automatically set the fixed-in-version when it imports a changeset that matches the "fixed bug regex" | 16:47 |
| paul_ | nuclear_eclipse: well, this is turning into more fun then I wanted ;/ | 16:58 |
| nuclear_eclipse | paul_: afaik, the css/js includes from admin/* have never worked anyways | 17:01 |
| paul_ | they used to work for me ;/ | 17:01 |
| paul_ | i'll check in a bit | 17:01 |
| paul_ | more importantly | 17:01 |
| paul_ | start /B /D "C:\Program Files (x86)\CollabNet\Subversion Client" svn.exe helpNULL | 17:02 |
| paul_ | that's returning null | 17:02 |
| nuclear_eclipse | don't ask me, I don't actually use that part :P | 17:02 |
| nuclear_eclipse | that's just a patch I got on my bugtracker | 17:02 |
| paul_ | can i run it from cmd lne | 17:03 |
| nuclear_eclipse | you can initiate it from command line via `curl http://mantis/plugin.php?page=....` :P | 17:03 |
| paul_ | ... | 17:04 |
| paul_ | i meant a real version ;p | 17:04 |
| nuclear_eclipse | no | 17:04 |
| paul_ | I guess would be easy to code | 17:04 |
| nuclear_eclipse | the point of the way it works is to allow both local and remote commit/import operation, and to allow the admin to choose what IP's are allowed to do so | 17:05 |
| paul_ | well it does't work atm :P | 17:05 |
| paul_ | at least not in iis7+windows | 17:05 |
| nuclear_eclipse | I blame you or windows | 17:05 |
| nuclear_eclipse | and unless you can get me some error logs, I can't fix it | 17:05 |
| paul_ | I suspect it's a case of some permission(s) or even profile issue | 17:09 |
| paul_ | also | 17:12 |
| paul_ | i'm not having a problem with db_Get_name etc atm? | 17:13 |
| nuclear_eclipse | only happens in certain cases where the plugin needs to access the mantis database | 17:13 |
| paul_ | ahh | 17:14 |
| paul_ | so i'll probably hit in a bit | 17:14 |
| nuclear_eclipse | ah, apparently only happens when you're searching for changesets | 17:14 |
| nuclear_eclipse | dinnertime | 17:18 |
| paul_ | svn: Can't determine the user's config path | 17:23 |
| paul_ | ahh | 17:23 |
| paul_ | can we use proc_open instead of shellexc? :) | 17:24 |
| *** Quits: daryn (~INTERACT\@rrcs-76-79-4-2.west.biz.rr.com) (Remote host closed the connection) | 17:40 | |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 17:57 | |
| *** Quits: rolfkleef (~rolf@urtica.xs4all.nl) (Ping timeout: 240 seconds) | 17:59 | |
| nuclear_eclipse | paul_: at that point I might as well use popen() | 18:51 |
| paul_ | yea | 18:53 |
| nuclear_eclipse | I just didn't want to deal with having to loop around doing incremental reads when I could just get one big string using shell_exec() | 18:53 |
| paul_ | :) | 18:53 |
| paul_ | anyway | 18:53 |
| paul_ | whats your plan with encodings? :P | 18:54 |
| nuclear_eclipse | no clue | 18:54 |
| nuclear_eclipse | it doesn't seem like there are any good options that will work everywhere | 18:54 |
| nuclear_eclipse | setlocale() breaks everything if you are using the threaded worker model of apache, setenv("LOCALE",...) only works on linux.... | 18:54 |
| paul_ | :) | 18:55 |
| nuclear_eclipse | I want a justgivemeutf8damnit() | 18:55 |
| paul_ | you could not use the svn client | 18:55 |
| philip_ | php 8 will have full unicode support ;) | 18:55 |
| nuclear_eclipse | I'll believe it when I see it | 18:56 |
| paul_ | is that the conclusion of that debate? ;p | 18:56 |
| paul_ | nuclear_eclipse: http://phpclasses.100pour100net.com/package/4270-PHP-Retrieve-files-from-an-SVN-repository-in-pure-PHP.html | 18:57 |
| paul_ | nuclear_eclipse: try doing svn in php only for kicks | 18:57 |
| paul_ | that might fix it :P | 18:57 |
| nuclear_eclipse | paul_: basically, if you can find me a way to get UTF8 strings from the SVN binary that will work on all installations, then I'll implement it | 18:57 |
| paul_ | http://www.3thirty.net/blog/?p=11 | 18:58 |
| paul_ | which apparently is actually now http://code.google.com/p/phpsvnclient/ | 18:58 |
| nuclear_eclipse | there's a php module for working with SVN repos, but it's not included with windows installations, and lives in an optional package on Linux | 18:58 |
| paul_ | I might actually take a look at that class tomororw | 18:59 |
| paul_ | but right now, apparently it's bed time | 18:59 |
| paul_ | so good night | 18:59 |
| nuclear_eclipse | hmm, the question is how well it supports UTF8 characters; if it works well and isn't slow/bloated, I'd be willing to use that instead | 19:00 |
| paul_ | actually | 19:00 |
| paul_ | the question is more whether you want to be trying to implement each revision control system protocol in php in your spare time ;p | 19:01 |
| nuclear_eclipse | well, thankfully I'm not fully reimplementing any of them ;) | 19:06 |
| nuclear_eclipse | I just implemented a very basic core dataset, and each vcs plugin is only a go-between to fill in the dataset from a dump of the repo | 19:07 |
| paul_ | anyway, nn | 19:07 |
| nuclear_eclipse | cheers | 19:08 |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 264 seconds) | 19:21 | |
| *** Quits: AzaToth (~azatoth@wikipedia/AzaToth) (Remote host closed the connection) | 19:48 | |
| *** Quits: scribe9343423 (~scribe934@mantisforge.org) (Remote host closed the connection) | 20:00 | |
| *** Joins: scribe9343423 (~scribe934@mantisforge.org) | 20:00 | |
| nuclear_eclipse | giallu: you happen to know where supybot's website has gone to? | 20:02 |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 20:07 | |
| *** Quits: philip_ (~philip_@unaffiliated/philip) (Quit: i'll be back one day) | 22:00 | |
| *** Quits: fanno (~Morten@90.184.93.233) (Read error: Connection reset by peer) | 22:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
