| *** Joins: rolfkleef (~rolf@urtica.xs4all.nl) | 00:54 | |
| *** Quits: rolfkleef (~rolf@urtica.xs4all.nl) (Ping timeout: 260 seconds) | 01:21 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 240 seconds) | 02:10 | |
| *** Joins: Cupertino (~Cupez@unaffiliated/cupertino) | 02:34 | |
| *** Joins: Cupez (~Cupez@unaffiliated/cupertino) | 02:46 | |
| *** Quits: Artefact2 (~Artefact2@ip-223.net-89-2-51.rev.numericable.fr) (Ping timeout: 276 seconds) | 03:34 | |
| *** Joins: Artefact2 (~Artefact2@ip-223.net-89-2-51.rev.numericable.fr) | 03:46 | |
| *** Joins: Rixie (~Rixie@0x4dd7390e.adsl.cybercity.dk) | 03:58 | |
| *** Joins: rolfkleef (~rolf@82-204-30-154.dsl.bbeyond.nl) | 04:26 | |
| *** Quits: rolfkleef (~rolf@82-204-30-154.dsl.bbeyond.nl) (Ping timeout: 252 seconds) | 04:42 | |
| *** Quits: siebrand (~beis@sm.xs4all.nl) () | 04:52 | |
| *** Joins: slim_ (~slim1@41.153.214.232) | 04:57 | |
| slim_ | hello all, i installed mantis 1.2.1, and i have a database from older mantis, how can i install old database ? | 05:00 |
|---|---|---|
| *** Quits: CIA-24 (cia@208.69.182.149) (Ping timeout: 264 seconds) | 05:13 | |
| *** Joins: orac1 (~jb_buldog@193.190.57.9) | 05:15 | |
| slim_ | hi | 05:22 |
| *** Joins: rolfkleef (~rolf@82-204-30-154.dsl.bbeyond.nl) | 05:26 | |
| *** Quits: slim_ (~slim1@41.153.214.232) (Quit: Ex-Chat) | 05:27 | |
| *** Joins: slim_ (~slim1@41.153.52.13) | 05:27 | |
| slim_ | is it possible to upgrade from version 0.17.5 to 1.2.1 ? | 05:30 |
| *** Joins: CIA-22 (cia@208.69.182.149) | 05:42 | |
| slim_ | as i read that to upgrade to version 1.0.0 first, but i got error also when upgrade to version 1.0.0 anyone can help me in this ? | 05:58 |
| *** Quits: slim_ (~slim1@41.153.52.13) (Ping timeout: 240 seconds) | 06:08 | |
| *** Quits: orac1 (~jb_buldog@193.190.57.9) (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) | 06:08 | |
| *** Joins: slim_ (~slim1@41.153.195.11) | 06:20 | |
| *** Joins: fanno (~Morten@90.184.93.233) | 06:21 | |
| dhx_m | slim_: you're on your own with this one... 0.17.5 is older than the internet and it is unlikely anyone here (or on the mailing list) was around that long ago (and/or remembers how such an early version worked) | 06:23 |
| slim_ | dhx_m: we use old version long time ago, yesteday only my manager asked me to upgrate to current version | 06:24 |
| slim_ | after i read i find that i have to upgrade to version 1.0.0 first | 06:24 |
| dhx_m | you should really be updating more frequently or else you run into these situations | 06:35 |
| dhx_m | unless you have the inhouse skills to write your own conversion scripts | 06:35 |
| slim_ | of course , you are right . | 06:36 |
| dhx_m | otherwise you can try crawling the bug tracker and mailing list for historical information about upgrading earlier versions | 06:36 |
| slim_ | this i do now , | 06:36 |
| dhx_m | it's a bit like someone asking how to upgrade from Windows 3.1 to Windows 7... it's easier to just start again and move data across yourself than to upgrade (if it's even possible) | 06:37 |
| dhx_m | except with Windows you are better to start afresh every time you upgrade/reinstall :p | 06:37 |
| slim_ | yes to avoid this i'm working with linux :) | 06:38 |
| *** Quits: rolfkleef (~rolf@82-204-30-154.dsl.bbeyond.nl) (Ping timeout: 240 seconds) | 06:46 | |
| *** Quits: Artefact2 (~Artefact2@ip-223.net-89-2-51.rev.numericable.fr) (Ping timeout: 265 seconds) | 07:09 | |
| slim_ | dhx_m: now the current version working well :) | 07:14 |
| dhx_m | :) | 07:14 |
| dhx_m | that was quicker than I was expecting :D | 07:14 |
| slim_ | yes, there was something near in forum | 07:14 |
| *** Quits: philip_ (~philip_@unaffiliated/philip) (Ping timeout: 245 seconds) | 07:15 | |
| *** Quits: slim_ (~slim1@41.153.195.11) (Quit: Ex-Chat) | 07:19 | |
| nuclear_eclipse | wow | 07:27 |
| nuclear_eclipse | 0.17.5 | 07:28 |
| *** Joins: philip_ (~philip_@c-76-22-32-17.hsd1.wa.comcast.net) | 07:28 | |
| *** Quits: philip_ (~philip_@c-76-22-32-17.hsd1.wa.comcast.net) (Changing host) | 07:28 | |
| *** Joins: philip_ (~philip_@unaffiliated/philip) | 07:28 | |
| nuclear_eclipse | and I thought all those 1.0.x users were really bad at staying up to date... | 07:28 |
| nuclear_eclipse | :P | 07:29 |
| *** Joins: Artefact2 (~Artefact2@ip-223.net-89-2-51.rev.numericable.fr) | 07:30 | |
| dhx_m | lol | 07:46 |
| dhx_m | maybe we should have asked slim_ for a testimonial for the website... "I upgraded a 5 year old MantisBT installation to the latest version in minutes!" | 07:47 |
| *** Joins: SouBE (irc@ilari.stenroth.fi) | 07:51 | |
| *** Quits: philip_ (~philip_@unaffiliated/philip) (Ping timeout: 240 seconds) | 07:58 | |
| *** Joins: philip_ (~philip_@unaffiliated/philip) | 08:03 | |
| dhx_m | lol at this patent I came across relating to login security (user/pass) | 08:17 |
| dhx_m | they've reinvented challenge/response using something that resembles caeser shift | 08:17 |
| dhx_m | I think there needs to be a law created to ban people from creating their own crap crypto systems :p | 08:19 |
| *** Joins: kirillka (~Miranda@220-210-36-78.baltnet.ru) | 08:23 | |
| *** Joins: daryn (~daryn@rrcs-76-79-4-2.west.biz.rr.com) | 09:30 | |
| Draggor | So just to check, dokuwiki and mantisbt integration is currently borked? | 09:34 |
| nuclear_eclipse | Draggor: it just takes a bit of manual work to get them to work with each other... =/ | 09:39 |
| Draggor | nuclear_eclipse: Right now I'm having this "sg function not defined" in the mantis.class.php I added in dok | 09:48 |
| nuclear_eclipse | "sg"? | 09:52 |
| Draggor | http://www.mantisbt.org/wiki/doku.php/mantisbt:issue:7075:integration_with_dokuwiki I'm following this | 09:53 |
| nuclear_eclipse | I have no clue | 09:55 |
| *** Quits: Rixie (~Rixie@0x4dd7390e.adsl.cybercity.dk) (Quit: Rixie) | 09:55 | |
| nuclear_eclipse | those instructions are really out of date | 09:55 |
| Draggor | Ahh, heh. Is there a better way I should go about it? | 09:55 |
| nuclear_eclipse | I know that quite a bit of mantis has changed since then | 09:55 |
| nuclear_eclipse | Draggor: pick something other than Dokuwiki ;) | 09:55 |
| Draggor | Aww, but I like dokuwiki :( <3 flat file storage for small stuff | 09:56 |
| nuclear_eclipse | well, then I can't really help =\ | 09:56 |
| Draggor | well, mainly, I greatly enjoy dokwiki's syntax and block editing | 09:56 |
| nuclear_eclipse | I stopped using Dokuwiki years ago because file-based storage is really annoying | 09:57 |
| nuclear_eclipse | makes upgrading and backups a pain | 09:57 |
| Draggor | So far upgrading has been simple and backups divine | 09:57 |
| nuclear_eclipse | permissions also constantly kept creeping up to bite me | 09:57 |
| Draggor | Okay so my conf and data dirs might be a bit.. loose, heh | 09:58 |
| nuclear_eclipse | it's far easier to just dump all your databases at night than to have your data spread out in multiple locations | 09:58 |
| Draggor | I mean, someone asks me for a wiki, so I just unzip the thing and pint the install page to them | 09:58 |
| Draggor | point* | 09:58 |
| Draggor | It's a two minute affair | 09:59 |
| Draggor | Part of it is my own fault for locking down my DB so heavily | 09:59 |
| Draggor | I'd be willing to rediscover how to merge dokiwiki with mantis could be a fun mini project | 10:01 |
| nuclear_eclipse | Draggor: if you do so, it would be nice to have an updated wiki article :P | 10:02 |
| Draggor | I would do that too :3 | 10:03 |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 10:26 | |
| *** Quits: Cupertino (~Cupez@unaffiliated/cupertino) (Quit: I give up...) | 11:03 | |
| *** Joins: moto-moi (~hylke@cara.xs4all.nl) | 11:58 | |
| *** Joins: siebrand (~beis@sm.xs4all.nl) | 12:00 | |
| *** Quits: fanno (~Morten@90.184.93.233) (Ping timeout: 260 seconds) | 12:01 | |
| CIA-22 | Mantisbt: s.mazeland master-1.2.x * r429142a6b0f2 / (7 files in 2 dirs): Localisation updates from http://translatewiki.net | 12:41 |
| *** Quits: Artefact2 (~Artefact2@ip-223.net-89-2-51.rev.numericable.fr) (Ping timeout: 265 seconds) | 12:43 | |
| *** Joins: Artefact2 (~Artefact2@ip-223.net-89-2-51.rev.numericable.fr) | 12:56 | |
| *** Quits: kirillka (~Miranda@220-210-36-78.baltnet.ru) (Read error: Connection timed out) | 13:02 | |
| *** Joins: fanno (~Morten@90.184.93.233) | 13:06 | |
| *** Joins: nuclear_eclipse (~jreese@irc.leetcode.net) | 13:30 | |
| *** Quits: Artefact2 (~Artefact2@ip-223.net-89-2-51.rev.numericable.fr) (Ping timeout: 260 seconds) | 13:35 | |
| *** Joins: rolfkleef (~rolf@urtica.xs4all.nl) | 13:58 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 258 seconds) | 14:10 | |
| *** Joins: slestak (~sromanow@63-144-86-130.dia.static.qwest.net) | 14:15 | |
| slestak | hi guys. I got a curl line workign that runs a repo_import_last for my sourceintegration use. The one question I have is it requires the id arg for the repo. Is there a general call I can use to run it on all the repos? | 14:17 |
| nuclear_eclipse | slestak: id=all | 14:21 |
| slestak | ahh, tyvm | 14:24 |
| slestak | i was just writing a python script to iterate over the rows in mantis_plugin_Source_repository_table | 14:24 |
| slestak | ty for saving me from myself | 14:25 |
| nuclear_eclipse | youre welcome | 14:25 |
| nuclear_eclipse | if at all possible, you should try to use post-commit hooks rather than a cronjob, but I implemented both methods because I know that's not always possible, eg, SourceForge repos | 14:26 |
| *** Joins: Draggor1 (~Draggor@adsl-99-144-211-79.dsl.emhril.sbcglobal.net) | 14:33 | |
| *** Quits: Draggor (~Draggor@adsl-99-142-66-24.dsl.emhril.sbcglobal.net) (Ping timeout: 240 seconds) | 14:36 | |
| *** Joins: kirillka (~Miranda@30-81-52-95.baltnet.ru) | 14:42 | |
| *** Quits: PennStater (Aaron@unaffiliated/pennstater) (Quit: Never look down on someone unless you're helping them up.) | 15:02 | |
| slestak | i liek the idea of the cron, because I can have one spot to get tehm all, otherwise I am making X post-commit hooks for X repos | 15:05 |
| slestak | if i used a post commit hook, each repo needs to know its mysql id number, unless I am going to say update all when any have a commit, that would be wasteful | 15:06 |
| slestak | is id 'all' new since sourceintegration 0.14? when I use it I get "Invalid remote import address" returned | 15:07 |
| slestak | would be cool if the repo displayed its last import datetime | 15:08 |
| *** Quits: Cupez (~Cupez@unaffiliated/cupertino) (Quit: I give up...) | 15:09 | |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 15:09 | |
| slestak | i see that in strings. plugins/Source/lang/strings_english.txt:$s_plugin_Source_invalid_import_url = 'Invalid remote import address'; | 15:10 |
| *** Draggor1 is now known as Draggor | 15:11 | |
| slestak | ok, the error message from above only occurs when i try to go to that url in firefox for testing | 15:14 |
| slestak | when I use curl on the mantis vm, it works for integer id keys, however, id=all does not work with curl | 15:14 |
| *** Joins: PennStater (Aaron@unaffiliated/pennstater) | 15:27 | |
| nuclear_eclipse | slestak: yes, that's new since 0.14 | 15:32 |
| slestak | i am using dhx_m's hgweb version so I will upfate them indiviually until that reaches 0.16 | 15:33 |
| slestak | is the best method of installing (and tracking) plugins to use git to clone them to mantis/plugins/ ? | 15:34 |
| nuclear_eclipse | my preferred method is cloning plugins to a separate directory and then symlinking from the other location into the mantis/plugins directory | 15:35 |
| slestak | think i will do that. that is how I keep mantis, symlinked to /usr/local/src | 15:36 |
| nuclear_eclipse | slestak: you might also want to considering attempting to run dhx's hgweb plugin with the up-to-date framework at 0.16.1 | 15:37 |
| nuclear_eclipse | and if it doesn't work, I imagine it shouldn't take much to fix it | 15:38 |
| slestak | i think i tried that and had issues. sry, cannot remember | 15:38 |
| nuclear_eclipse | most of the changes since 0.14 took place in the framework features themselves | 15:38 |
| slestak | i'd liek to, but with my workload right now I need to be a user more than dev, | 15:38 |
| nuclear_eclipse | np | 15:38 |
| nuclear_eclipse | just thought I'd sugest it | 15:38 |
| slestak | i'd liek to. I think step one may be to reinstall my existing plugins using the methd you describe so I can maybe keep multiple version | 15:39 |
| nuclear_eclipse | other suggestion is to just bug dhx about getting his hgweb plugin up to date :P | 15:40 |
| slestak | nah, im very pleased and thankful to have what i got | 15:41 |
| *** Quits: PennStater (Aaron@unaffiliated/pennstater) (Read error: Connection reset by peer) | 15:44 | |
| *** Joins: PennStater (Aaron@unaffiliated/pennstater) | 15:44 | |
| *** Quits: kirillka (~Miranda@30-81-52-95.baltnet.ru) (Read error: Operation timed out) | 15:48 | |
| *** Quits: PennStater^AtWrk (Aaron@unaffiliated/pennstater) (Ping timeout: 252 seconds) | 15:59 | |
| *** Joins: PennStats (Aaron@unaffiliated/pennstater) | 16:03 | |
| *** PennStats is now known as PennStater^AtWrk | 16:20 | |
| *** Joins: orac1 (~jb_buldog@082-146-096-153.dyn.adsl.xs4all.be) | 16:54 | |
| *** Joins: mantisbt_85060 (bef8187a@gateway/web/freenode/ip.190.248.24.122) | 17:09 | |
| *** Quits: orac1 (~jb_buldog@082-146-096-153.dyn.adsl.xs4all.be) (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) | 17:10 | |
| *** Parts: mantisbt_85060 (bef8187a@gateway/web/freenode/ip.190.248.24.122) | 17:10 | |
| *** Parts: slestak (~sromanow@63-144-86-130.dia.static.qwest.net) | 17:11 | |
| *** Quits: philip_ (~philip_@unaffiliated/philip) (Quit: philip_) | 17:26 | |
| *** Quits: rolfkleef (~rolf@urtica.xs4all.nl) (Ping timeout: 248 seconds) | 17:33 | |
| *** Quits: daryn (~daryn@rrcs-76-79-4-2.west.biz.rr.com) (Remote host closed the connection) | 17:59 | |
| *** Quits: moto-moi (~hylke@cara.xs4all.nl) (Quit: Ex-Chat) | 18:13 | |
| *** Joins: Draggor1 (~Draggor@adsl-99-152-244-49.dsl.emhril.sbcglobal.net) | 19:24 | |
| *** Quits: Draggor (~Draggor@adsl-99-144-211-79.dsl.emhril.sbcglobal.net) (Ping timeout: 240 seconds) | 19:27 | |
| nuclear_eclipse | dhx_m: | 19:39 |
| nuclear_eclipse | dhx_m: you broke things | 19:39 |
| nuclear_eclipse | dhx_m: http://git.mantisbt.org/?p=mantisbt.git;a=commit;h=7062c67759c8dd002a187ed24a8a4a710f2e6eb5 | 19:42 |
| nuclear_eclipse | that commit breaks the ability to configure the default next status in the workflow | 19:42 |
| nuclear_eclipse | just because the default configuration settings sucked, doesn't mean you get to ignore them :P | 19:42 |
| *** Quits: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 19:59 | |
| *** Joins: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) | 20:00 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Read error: Operation timed out) | 20:11 | |
| dhx_m | nuclear_eclipse: wrong commit? | 20:16 |
| nuclear_eclipse | sorry, commit 886dccd9a467c892a165e7a755a6b13d0d8ed365 | 20:19 |
| dhx_m | ah yep that's on the TODO list to fix | 20:29 |
| dhx_m | I'm trying to decide at the moment how to handle email notifications on bug_update.php | 20:29 |
| dhx_m | it's not easy :( | 20:29 |
| dhx_m | say someone wants to me notified on change of handler | 20:30 |
| dhx_m | yet they don't want to know when the status changes | 20:30 |
| nuclear_eclipse | yeah, good luck on that one | 20:30 |
| dhx_m | lol I think I'll leave it how it was (mostly) for now | 20:30 |
| dhx_m | ie. precedence of rules... handler > status > update | 20:31 |
| dhx_m | which is rather idiotic at the moment | 20:31 |
| * nuclear_eclipse thinks you opened a gigantic can of worms | 20:31 | |
| dhx_m | but then so too are the email notification settings where half of them don't work (and can't work in many cases) | 20:32 |
| dhx_m | lol | 20:32 |
| dhx_m | I have been thinking for a long time that notifications should tap into the event system | 20:32 |
| nuclear_eclipse | yeah, I would completely agree -- it's just a matter of "how do you do that without pissing off > 50% of current users" | 20:33 |
| dhx_m | so a bundled email plugin responds to EVENT_BUG_UPDATE_POST_COMMIT to send out emails of the changes made | 20:33 |
| dhx_m | well given that email doesn't really work at the moment... I think they're probably already quite annoyed :p | 20:33 |
| dhx_m | you might be interested in #11967 | 20:34 |
| nuclear_eclipse | well, it *does* work, just not the way people expect it to work out of the box; and for anyone who's taken the time to learn and config mantis to do exactly what they want, just about *anything* will be abreaking change for them | 20:34 |
| dhx_m | yep | 20:35 |
| dhx_m | RE #11967 we need to add an event prior to committing a bug update to the database (as well as after) | 20:35 |
| dhx_m | I was thinking of having EVENT_BUG_UPDATE_PRE_COMMIT and EVENT_BUG_UPDATE_POST_COMMIT to replace the current EVENT_BUG_UPDATE event | 20:35 |
| dhx_m | as my new bug_update.php does all validation before making any changes to the database | 20:36 |
| dhx_m | therefore database commits are "guaranteed" (race conditions unavoidable though) | 20:36 |
| dhx_m | whereas before it was possible for some data to be committed (the status change for instance) yet an access check would fail later on in the script for adding a bug note... hence you only get 50% of the changes committed, the other 50% missing | 20:37 |
| nuclear_eclipse | not a fan of those names, but I agree that the events around bug update should be consistent with events for bug report, where REPORT_BUG_DATA allows pre-processing, and standard REPORT_BUG allows post processing | 20:40 |
| dhx_m | ok I'll try that approach instead (will need documentation updates too though) | 20:41 |
| dhx_m | I think I prefer VALIDATE to DATA but it's better to be consistent :) | 20:42 |
| nuclear_eclipse | well, it's more than just validation that it allows | 20:44 |
| nuclear_eclipse | the point is that REPORT_BUG_DATA allows plugins to actually modify the bug data before the database is updated | 20:45 |
| dhx_m | true, it can add/change it too | 20:45 |
| dhx_m | yep | 20:45 |
| nuclear_eclipse | it the case of some proprietary plugins I wrote, we used that to auto-assign issues based on custom field values, as well as updating custom fields based on other changes, like automatically filling in a custom field whenever changing to a certain status | 20:47 |
| nuclear_eclipse | (just for a bit of context) | 20:47 |
| *** Draggor1 is now known as Draggor | 20:51 | |
| dhx_m | ok cool :) | 21:00 |
| dhx_m | can we also change the parameters of the event where needed? | 21:01 |
| dhx_m | I think EVENT_BUG_UPDATE_DATA should send the existing and updated bug objects to the event handler | 21:01 |
| dhx_m | and EVENT_BUG_UPDATE should receive the updated bug object | 21:02 |
| dhx_m | does that sound reasonable? | 21:02 |
| dhx_m | the catch is we only do a shallow copy (PHP's clone) of the BugData object | 21:03 |
| dhx_m | which at the moment is OK... but in the future if BugData becomes more complex by holding other objects will require a __clone() method on BugData | 21:03 |
| dhx_m | actually... bug_update only modifies primitives anyway, so I can't see it being an issue | 21:04 |
| nuclear_eclipse | dhx_m: just as long as you document any changes made to the events so that it's obvious in what version of mantis it changed, I'm fine with that | 21:05 |
| dhx_m | yep | 21:05 |
| nuclear_eclipse | and by document changes, I mean modify the docbook event reference so that it mentions that behavior was changed in version 1.x.x | 21:06 |
| dhx_m | ok | 21:09 |
| dhx_m | 1.2.2? | 21:09 |
| *** Joins: daryn (~daryn@h64.157.16.98.dynamic.ip.windstream.net) | 21:09 | |
| nuclear_eclipse | that's the problem, I don't like major event changes for minor versions, but I agree that it needs to change... =/ | 21:09 |
| nuclear_eclipse | so yeah | 21:09 |
| nuclear_eclipse | go ahead | 21:09 |
| dhx_m | btw I think I know what we need to do with the new email notification system... create a cache (in the database for now, looking towards memcache support in the future) of every change a user should be notified of | 21:10 |
| dhx_m | and have a cron job (or similar) check once every few minutes to collate those changes into a single email | 21:10 |
| dhx_m | so if someone updates the handler of a bug at 03:45 and then updates the resolution at 03:46... the user will receive an email collating these changes at 03:46+5min as long as no other changes have occurred in the mean time | 21:11 |
| daryn | dhx_m: i like the sound of that | 21:12 |
| nuclear_eclipse | the problem is that it requires some sort of cronjob | 21:13 |
| daryn | yeah...anything is better than what we get now | 21:13 |
| daryn | well...maybe not anything. | 21:14 |
| nuclear_eclipse | right, but Windows servers don't have cronjobs, and I don't like forcing people to set up a cronjob just to deal with email | 21:14 |
| dhx_m | I could have a look at Mediawiki's work queues too | 21:18 |
| dhx_m | I gather those work by running a few items from the work queue on each page request | 21:18 |
| nuclear_eclipse | dhx_m: I still like the idea though -- perhaps it could just work the same as right now, where it does potentially fancy stuff, but then just flushes out all the emails at the end of the page load | 21:18 |
| dhx_m | yep | 21:18 |
| dhx_m | make the timer 0 in other words | 21:18 |
| dhx_m | (in the event there is no cron job) | 21:19 |
| nuclear_eclipse | yeah, just keep using the same config option to tell it whether to rely on a cronjob or not | 21:19 |
| nuclear_eclipse | what you're talking about would also facilitate the much-requested diff-style emails, too | 21:19 |
| dhx_m | daryn: btw hi :) | 21:20 |
| daryn | hello | 21:20 |
| dhx_m | that's a nice side effect | 21:20 |
| dhx_m | one of the main problems I had when using MantisBT last year for a University project was people receiving too many emails | 21:20 |
| dhx_m | so they became less relevant | 21:21 |
| dhx_m | hence why I suggest allowing 5-10min of no changes to a bug before sending a digest | 21:21 |
| nuclear_eclipse | lol, and the biggest complaint when I set up mantis at my old job was not receiving *enough* email :P | 21:21 |
| dhx_m | lol | 21:21 |
| dhx_m | well yeah that too... it's broken :p | 21:21 |
| daryn | everyone at our work pretty much turns them off and uses rss feeds | 21:21 |
| dhx_m | it's either broken and emails aren't sent... or broken and too many emails are sent | 21:21 |
| nuclear_eclipse | dhx_m: I'd also caution to err on the side of sending an email sooner rather than later | 21:22 |
| nuclear_eclipse | people get anxious if they don't get an email immediately after something happens | 21:22 |
| dhx_m | that's true... I'd guess it'd be better left as a user customisable setting | 21:22 |
| dhx_m | "minimum time between notifications on the same bug" or something similar | 21:23 |
| nuclear_eclipse | either way, I'd be more than happy to see the current set of notification options and configuration values get obliterated | 21:23 |
| dhx_m | lol | 21:24 |
| dhx_m | I'm not sure if we should use the event system for notifications or introduce a built-in notification system that plugins can hook into | 21:24 |
| nuclear_eclipse | we just need to make sure there's *some way* of migrating old behaviors to something close enough in the new system, or else you'll hear a *lot* of complaints and bug reports | 21:24 |
| dhx_m | yep | 21:25 |
| dhx_m | [master 43de33b] Refactor bug_update to fix multiple bugs | 21:25 |
| dhx_m | 1 files changed, 405 insertions(+), 254 deletions(-) | 21:25 |
| dhx_m | rewrite bug_update.php (76%) | 21:25 |
| nuclear_eclipse | dhx_m: I'd be more inclined to create a fresh notification API, and allow plugins to hook notification events to enable new notification methods other than email | 21:25 |
| dhx_m | yep I was heading that direction too | 21:25 |
| dhx_m | so MantisBT core has some understanding of notifications | 21:26 |
| daryn | i concur | 21:26 |
| daryn | not that it matters, heh | 21:26 |
| dhx_m | I haven't used git in months... now I have to remember it all heh | 21:27 |
| daryn | either of you looked at filters yet? | 21:27 |
| nuclear_eclipse | lol, I've been a bit too busy chasing david's bugs :P | 21:28 |
| daryn | dang it | 21:29 |
| dhx_m | how was I meant to know the first element in the status enum list was the default (it's not documented at all) :p | 21:29 |
| dhx_m | and no clues as to that being the case hehe | 21:29 |
| nuclear_eclipse | all my mantis time is filled atm with a todo list of stuff I need to accomplish due to a project getting ready for a public release | 21:29 |
| nuclear_eclipse | it was "obvious", duh! | 21:30 |
| nuclear_eclipse | :P | 21:30 |
| dhx_m | lol | 21:30 |
| daryn | i have a class...MantisBugFilter that basically replaces filter api...however, i want to abstract it more and create a class that I can build other filters for that aren't necessarily querying the bug table | 21:32 |
| daryn | i need a name... | 21:32 |
| nuclear_eclipse | MantisFilter? :P | 21:32 |
| daryn | that would be great except thats what you called the abstract field class | 21:32 |
| nuclear_eclipse | no, that's what I called the abstract filter class... | 21:33 |
| dhx_m | with git rebase... when you squash a commit into a previous one... which commit message is used? | 21:33 |
| dhx_m | I guess it lets you edit it anyway | 21:33 |
| nuclear_eclipse | both | 21:33 |
| daryn | but it's for individual fields... | 21:33 |
| daryn | MantisBugFilter is a collection of all the fields in the filter | 21:34 |
| nuclear_eclipse | daryn: I'm confused what you mean -- MantisFilter is what abstracts the ability to a) show a set of inputs to control a filter query, and b) generate a query for the given inputs | 21:35 |
| dhx_m | GRRR I squashed the wrong things | 21:35 |
| nuclear_eclipse | dhx_m: git rebase --abort | 21:35 |
| dhx_m | already done | 21:36 |
| nuclear_eclipse | or check `git reflog` for the old tip's commit hash, and do `git reset --hard <ref>` | 21:36 |
| dhx_m | ah nice, thanks :) | 21:37 |
| daryn | nuclear_eclipse: help me understand... a) show a set of inputs to control a filter query... | 21:38 |
| daryn | this is for one field per instance, correct? | 21:38 |
| nuclear_eclipse | well, one input element, if that's what you mean | 21:39 |
| daryn | so...if it were applied to standard fields, status would be one instance, priority a different instance, etc. | 21:39 |
| nuclear_eclipse | right | 21:39 |
| daryn | yes | 21:39 |
| dhx_m | daryn: I'll commit these changes and backport them... then I'll have a look at filters :) | 21:39 |
| daryn | ok...so i'm talking about a collection of all the input elements on the 'filter' | 21:40 |
| dhx_m | prepare for the worst... :p | 21:40 |
| daryn | to me the filter is the whole thing | 21:40 |
| dhx_m | ... | 21:40 |
| CIA-22 | Mantisbt: hickseydr * r4c7915236c46 /core/bug_api.php: Issue #12096: Add reporter and handler to monitor list on duplicate | 21:40 |
| CIA-22 | Mantisbt: hickseydr * recc102ed24be /core/constant_inc.php: Fix #12094: ERROR_BUG_READ_ONLY_ACTION_DENIED is not obsoleted | 21:40 |
| CIA-22 | Mantisbt: hickseydr * r69c55f958680 /core/bug_api.php: Fix #12095: bug_monitor_copy() should check users exist | 21:40 |
| CIA-22 | Mantisbt: hickseydr * r035a1302792a /bug_update.php: Refactor bug_update to fix multiple bugs | 21:40 |
| CIA-22 | Mantisbt: hickseydr * rfdaef4f8a6cc / (core/constant_inc.php lang/strings_english.txt): Add new error ERROR_BUG_RESOLVE_DEPENDANTS_BLOCKING | 21:40 |
| dhx_m | there we go | 21:40 |
| daryn | but that is semantics | 21:40 |
| dhx_m | I'd use the term "rule" perhaps? | 21:41 |
| dhx_m | a filter consists of multiple rules | 21:41 |
| daryn | dhx_m: i hope that 'prepare for the worst' isn't directed towards filters! | 21:41 |
| daryn | perhaps | 21:42 |
| dhx_m | it wasn't sorry (my bad timing)... it was aimed at those commits | 21:42 |
| daryn | :) | 21:42 |
| daryn | dhx_m i don't suppose you've looked at filters either... | 21:43 |
| daryn | :P | 21:43 |
| dhx_m | not yet sorry, been busy with those changes for 1.2.2 | 21:43 |
| daryn | i want to abstract more but i'd like some feedback | 21:43 |
| daryn | ya, cool | 21:44 |
| dhx_m | I really hate maintaining 2 branches | 21:44 |
| nuclear_eclipse | dhx_m: then don't worry about it, | 21:44 |
| dhx_m | I can see why the Linux Kernel went with their approach :) | 21:44 |
| nuclear_eclipse | we can just push 1.3.0 in a couple weeks and call it a 6 mo release cycle :P | 21:45 |
| dhx_m | lol really? I'm for that haha | 21:45 |
| daryn | let's push filters and break it good! | 21:45 |
| dhx_m | quick, get the beta out today! | 21:45 |
| daryn | btw...i took the MantisTemplate branch and made a new plugin with it to replace phptal plugin | 21:45 |
| nuclear_eclipse | so dhx_m, wanna learn how to build a release? :P | 21:46 |
| daryn | not pushed yet | 21:46 |
| dhx_m | nuclear_eclipse: sure :) | 21:46 |
| dhx_m | actually I don't have a non-expired GPG key at the moment | 21:46 |
| dhx_m | still TODO pending my new email address | 21:46 |
| nuclear_eclipse | well, I can just do the tag myself | 21:47 |
| dhx_m | thanks for the config from before ;) | 21:47 |
| dhx_m | I don't mind posting/etc | 21:47 |
| nuclear_eclipse | step 1) figure out everything noteworthy that's changed between 1.2.x and 1.3.0-dev | 21:48 |
| nuclear_eclipse | step 2) write up release notes in doc/RELEASE with a high level overview of those changes, and remove the old 1.2.x release notes | 21:48 |
| dhx_m | RELEASE NOTES: blame daryn :p | 21:49 |
| nuclear_eclipse | lol | 21:49 |
| daryn | whaaaa? | 21:49 |
| dhx_m | actually blame me for the new bug_update() :p | 21:49 |
| dhx_m | filters ;) | 21:49 |
| dhx_m | daryn: do I need remotes/daryn/filter-constants | 21:51 |
| daryn | we should probably get the Ajax call on bug report removed first...it breaks collapse js | 21:51 |
| daryn | no | 21:51 |
| daryn | filters | 21:51 |
| nuclear_eclipse | step 3) commit the new release notes, and update the codebase to reflect the next designated release version | 21:51 |
| nuclear_eclipse | in this case, 1.3.0-beta1 ? | 21:51 |
| daryn | going straight to beta, eh? | 21:52 |
| nuclear_eclipse | meh, it's not like mantis doesn't have a giant base of stable code... | 21:53 |
| nuclear_eclipse | IMO, alpha is generally reserved for completely new codebases, or times when a huge portion of the release has been untested | 21:53 |
| dhx_m | filters? :p | 21:54 |
| daryn | yeah... | 21:54 |
| daryn | uh huh | 21:54 |
| * nuclear_eclipse pulls up github to look at filters | 21:54 | |
| dhx_m | btw 1.2.0 was only 3 months ago | 21:54 |
| nuclear_eclipse | ? | 21:54 |
| nuclear_eclipse | really? | 21:54 |
| dhx_m | so perhaps we should make it a quarterly release | 21:55 |
| dhx_m | Mon, 22 Feb 2010 20:21:46 +0000 (15:21 -0500) | 21:55 |
| nuclear_eclipse | jreese@mach ~/workspace/mantisbt ±master-1.2.x » git show release-1.2.0 | 21:55 |
| nuclear_eclipse | tag release-1.2.0 | 21:55 |
| nuclear_eclipse | Tagger: John Reese <jreese@leetcode.net> | 21:55 |
| nuclear_eclipse | Date: Mon Feb 22 15:29:36 2010 -0500 | 21:55 |
| daryn | this will blow everyone's mind after the last release | 21:55 |
| nuclear_eclipse | that's more than 3 months ago.. | 21:55 |
| dhx_m | lol | 21:55 |
| dhx_m | 2 years from 1.1.x to 1.2.x and 3 months to 1.3.x | 21:55 |
| dhx_m | indeed it is | 21:55 |
| daryn | barely | 21:56 |
| dhx_m | http://git.mantisbt.org/?p=mantisbt.git;a=summary must be wrong | 21:56 |
| nuclear_eclipse | well, in all truthfulness, I'll giwe it some slack since it's exactly four months, but if it still says three tomorrow... | 21:57 |
| dhx_m | ah I see :) | 21:57 |
| nuclear_eclipse | either way, two months from beta to rc to final seems reasonable... | 21:57 |
| dhx_m | headline features would be... filters? | 21:57 |
| daryn | then 1.4 templates in 3 more months? | 21:58 |
| daryn | :D | 21:58 |
| dhx_m | haha get busy :p | 21:58 |
| nuclear_eclipse | daryn: sounds good to me :P | 21:58 |
| dhx_m | I'm up for that, thanks for offering to do all the work too :) | 21:58 |
| nuclear_eclipse | http://www.mantisbt.org/bugs/changelog_page.php?version_id=101 | 21:58 |
| dhx_m | ah so I did make a few minor user noticeable changes | 21:59 |
| nuclear_eclipse | dhx_m: seems like the highlight is "lots of small, but progressive changes" | 21:59 |
| dhx_m | fancy new page footer too | 21:59 |
| daryn | if we're going to put filters in i need to add a bunch of filter bugs that will be fixed | 21:59 |
| dhx_m | lol | 21:59 |
| nuclear_eclipse | dhx_m: I can name a few important fixes for 1.3 though | 22:00 |
| dhx_m | by how many megabytes does nuclear_eclipse need to expand the mantisbt.org database server by to accommodate these bugs? | 22:00 |
| nuclear_eclipse | well, before an official 1.3 | 22:00 |
| dhx_m | yep | 22:00 |
| daryn | no, i mean target exisitng bugs for the release and mark them fixed | 22:01 |
| dhx_m | *cough* that preselection of next status feature I blogged about | 22:01 |
| daryn | of course the other might be true also... | 22:01 |
| nuclear_eclipse | a) version inheritence is incomplete and has a few bad side effects, like roadmap/filter handling, etc | 22:01 |
| dhx_m | ah yep | 22:01 |
| nuclear_eclipse | b) new random/crypto stuff is broken by default | 22:02 |
| dhx_m | it's fixed now | 22:02 |
| nuclear_eclipse | ah | 22:02 |
| dhx_m | ie. Windows is made to be insecure as there is no other working option | 22:02 |
| dhx_m | it uses the weak pseudo-random number generator | 22:03 |
| dhx_m | oh it's not fixed | 22:05 |
| nuclear_eclipse | I didn't think so :P | 22:05 |
| dhx_m | (for Windows) | 22:05 |
| nuclear_eclipse | c) we need to document changes that plugin authors need to be aware of when making plugins compatible with 1.3 | 22:06 |
| nuclear_eclipse | d) rewrite admin guide :P | 22:06 |
| daryn | filters will affect that too | 22:06 |
| dhx_m | nuclear_eclipse: db_get_table hah | 22:07 |
| nuclear_eclipse | ;) | 22:07 |
| daryn | yeah... | 22:07 |
| nuclear_eclipse | daryn: filters is branched from master, right? | 22:09 |
| daryn | yes | 22:09 |
| daryn | although...i may not have your changes from today in it. don't remember | 22:09 |
| nuclear_eclipse | k, gonna pop a diff onto my phone so I can review it later | 22:09 |
| daryn | cool. thx | 22:10 |
| nuclear_eclipse | tsk tsk daryn, git is highlighting all your bad whitespacing... :P | 22:11 |
| daryn | yeah...i try to remove it all but you know i missed some | 22:11 |
| nuclear_eclipse | `git diff master...daryn/filters` highlights bad spacing in red for me | 22:12 |
| daryn | it does for me too but sometimes i get in a hurry | 22:12 |
| * nuclear_eclipse wags his finger at daryn | 22:12 | |
| nuclear_eclipse | anywho, bedtime for me | 22:12 |
| daryn | i usually check all that and clean it up before pushing but was in a hurry for you guys | 22:12 |
| daryn | of course it didn't help any | 22:13 |
| daryn | :P | 22:13 |
| nuclear_eclipse | dhx_m: you going to be around in ~10hours? | 22:13 |
| dhx_m | yep | 22:13 |
| nuclear_eclipse | k, I'll ping you when I get to work | 22:13 |
| dhx_m | will try and have lots of bugs fixed by then | 22:13 |
| dhx_m | ok, cya then :) | 22:13 |
| nuclear_eclipse | awesome | 22:13 |
| nuclear_eclipse | cheers | 22:13 |
| dhx_m | 'night | 22:14 |
| daryn | gnite | 22:15 |
| daryn | dhx_m you in australia? | 22:15 |
| dhx_m | daryn: yep | 22:15 |
| daryn | my wife tells me we're going there next year. her friend is getting married there | 22:16 |
| dhx_m | just be careful of the sharks, world's most poisonous snakes, dropbears, poisonous spiders, lethal jellyfish, etc :p | 22:17 |
| daryn | :) | 22:17 |
| daryn | don't say snakes...she might change her mind | 22:17 |
| dhx_m | hah | 22:17 |
| dhx_m | I even forgot crocodiles from that list duh :p | 22:18 |
| daryn | hehe | 22:18 |
| dhx_m | are you using Windows at the moment? | 22:22 |
| *** Joins: daryn_ (~daryn@h225.210.31.71.dynamic.ip.windstream.net) | 22:27 | |
| daryn_ | no...linux only | 22:27 |
| CIA-22 | Mantisbt: hickseydr * r3436d148684f /core/crypto_api.php: Use insecure built-in PRNG on Windows (no other options available) | 22:28 |
| dhx_m | yep same here, I'll ask paul later to check the latest version of PHP 5.3 on Windows with openssl_random_pseudo_bytes() | 22:28 |
| *** Quits: daryn (~daryn@h64.157.16.98.dynamic.ip.windstream.net) (Ping timeout: 260 seconds) | 22:30 | |
| *** Joins: daryn__ (~daryn@h163.223.31.71.dynamic.ip.windstream.net) | 22:30 | |
| *** daryn__ is now known as daryn | 22:30 | |
| *** Quits: daryn_ (~daryn@h225.210.31.71.dynamic.ip.windstream.net) (Ping timeout: 264 seconds) | 22:34 | |
| *** Quits: fanno (~Morten@90.184.93.233) (Read error: Connection reset by peer) | 22:47 | |
| daryn | dhx_m any chance when reworking notifications you can make it so a user can completely remove notification regarding a specific bug even if they have written bugnotes? | 22:53 |
| dhx_m | that sounds to me like the monitor list should act as both a whitelist and blacklist | 22:54 |
| daryn | maybe change it so when adding a note they are added to the monitor list and only use that for sending emails | 22:54 |
| dhx_m | also while notifications are high priority... so too is theming :) | 22:54 |
| daryn | yeah... | 22:54 |
| dhx_m | personally I'd like to focus on templating/theming for the next MantisBT release | 22:55 |
| dhx_m | as I think it's something that may interest developers in helping out the MantisBT project | 22:55 |
| dhx_m | it's easier work writing HTML templates than it is rewriting core parts of Mantis :) | 22:55 |
| *** Quits: daryn (~daryn@h163.223.31.71.dynamic.ip.windstream.net) (Ping timeout: 260 seconds) | 22:59 | |
| *** Joins: daryn (~daryn@h161.210.31.71.dynamic.ip.windstream.net) | 23:11 | |
| *** Joins: daryn_ (~daryn@h64.10.96.216.dynamic.ip.windstream.net) | 23:14 | |
| *** Quits: daryn (~daryn@h161.210.31.71.dynamic.ip.windstream.net) (Ping timeout: 265 seconds) | 23:17 | |
| *** Joins: socorropc (~socorropc@190.131.162.18) | 23:23 | |
| CIA-22 | Mantisbt: hickseydr * r373d998a1aab /bug_update_advanced_page.php: Issue #12097: Remove usage of update_mode parameter | 23:25 |
| CIA-22 | Mantisbt: hickseydr * r981621614d60 / (43 files in 4 dirs): Fix #12085: Remove $g_allow_close_immediately | 23:25 |
| socorropc | hello good evening. I've recently upgraded my mantis installation from 1.2rc3 up to 1.2.1. I upgraded the application, and everything is working great except from the "View Issue Detail" page which is not showing up the issue detail (numbre of issue, assigned to, etc.) Only shows custom fields I created... Any ideas? I guess it might be a configuration parameter which I might be using incorrectly... | 23:26 |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 23:28 | |
| *** Joins: daryn__ (~daryn@h40.40.213.151.dynamic.ip.windstream.net) | 23:38 | |
| *** Quits: daryn_ (~daryn@h64.10.96.216.dynamic.ip.windstream.net) (Ping timeout: 260 seconds) | 23:40 | |
| socorropc | "View Issue Detail" page which is not showing up the issue detail (numbre of issue, assigned to, etc.) Only shows custom fields I created... Any ideas? | 23:44 |
| *** Joins: daryn_ (~daryn@h112.213.31.71.dynamic.ip.windstream.net) | 23:57 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!