*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 01:26 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 256 seconds) | 01:35 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 02:59 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 276 seconds) | 03:08 | |
*** Joins: Heady| (~Heady@i59F76B4A.versanet.de) | 03:15 | |
*** Quits: wolog_ (~wolog@ASt-Lambert-152-1-64-207.w82-120.abo.wanadoo.fr) (Remote host closed the connection) | 03:17 | |
*** Joins: cobexer (~cobexer@91-113-120-6.adsl.highway.telekom.at) | 03:53 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 04:34 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 265 seconds) | 04:42 | |
*** cobexer is now known as \cobexer|away | 05:16 | |
paul__ | dhx_m: openssl is slow :P | 05:36 |
---|---|---|
*** Quits: Heady| (~Heady@i59F76B4A.versanet.de) () | 05:47 | |
*** Joins: rolfkleef (~rolf@urtica.xs4all.nl) | 05:51 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 06:07 | |
*** Quits: \cobexer|away (~cobexer@91-113-120-6.adsl.highway.telekom.at) (Remote host closed the connection) | 06:11 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 240 seconds) | 06:15 | |
dhx_m | hey | 06:40 |
dhx_m | paul__: apparently so :( | 06:40 |
*** Joins: fanno (~Morten@90.184.93.233) | 06:49 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 07:02 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 252 seconds) | 07:11 | |
*** Joins: AzaToth (~azatoth@wikipedia/AzaToth) | 07:21 | |
*** Joins: moto-moi (~hylke@cara.xs4all.nl) | 07:53 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 07:58 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 265 seconds) | 08:06 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 08:54 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 246 seconds) | 09:02 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 09:57 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 256 seconds) | 10:05 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 11:03 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 264 seconds) | 11:11 | |
nuclear_eclipse | dhx_m: I told you so :P | 12:00 |
*** Joins: daryn__ (~INTERACT\@h133.83.88.75.dynamic.ip.windstream.net) | 12:00 | |
*** Quits: daryn_ (~INTERACT\@h83.145.28.71.dynamic.ip.windstream.net) (Ping timeout: 248 seconds) | 12:04 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 12:09 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 256 seconds) | 12:18 | |
*** Quits: mellen (~thansen@x1-6-00-22-02-00-0c-40.k253.webspeed.dk) (Ping timeout: 260 seconds) | 12:28 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 13:18 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 260 seconds) | 13:26 | |
*** Joins: wolog (~wolog@AOrleans-152-1-81-151.w90-21.abo.wanadoo.fr) | 13:40 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 14:25 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 245 seconds) | 14:33 | |
*** Joins: ZiNC (~zinc@188.120.158.32) | 15:16 | |
ZiNC | Hey. | 15:17 |
ZiNC | Why is there view.php (that just maps to bug_view_page.php)? | 15:19 |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 15:30 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 276 seconds) | 15:39 | |
paul__ | dhx_m: just drop crypto api :P | 16:25 |
paul__ | also, you there? | 16:25 |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 16:34 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 252 seconds) | 16:43 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 17:39 | |
*** Joins: mellen (~thansen@x1-6-00-22-02-00-0c-40.k253.webspeed.dk) | 17:46 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 256 seconds) | 17:47 | |
*** Quits: moto-moi (~hylke@cara.xs4all.nl) (Quit: Ex-Chat) | 18:08 | |
*** Joins: giallu (~giallu@fedora/giallu) | 18:14 | |
*** Quits: aptituz (schoenfeld@85.214.56.206) (Remote host closed the connection) | 18:27 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 18:42 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 252 seconds) | 18:50 | |
*** Quits: scribe9343423 (~scribe934@mantisforge.org) (Remote host closed the connection) | 19:00 | |
*** Joins: scribe9343423 (~scribe934@mantisforge.org) | 19:00 | |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 19:56 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 256 seconds) | 20:04 | |
*** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 245 seconds) | 20:07 | |
*** Quits: rolfkleef (~rolf@urtica.xs4all.nl) (Ping timeout: 265 seconds) | 20:12 | |
*** Quits: daryn__ (~INTERACT\@h133.83.88.75.dynamic.ip.windstream.net) (Ping timeout: 246 seconds) | 20:31 | |
*** Joins: daryn (~INTERACT\@h52.149.55.139.dynamic.ip.windstream.net) | 20:46 | |
*** Joins: micahg (~micah@ubuntu/member/micahg) | 20:47 | |
micahg | hi, is there a bug tracker for the plugins on mantisforge? | 20:47 |
nuclear_eclipse | depends on the plugn | 20:48 |
nuclear_eclipse | I have a tracker set up on my own domain for my plugins | 20:48 |
dhx_m | nuclear_eclipse: hey | 20:48 |
nuclear_eclipse | hi dhx_m | 20:48 |
dhx_m | nuclear_eclipse: I agree on pushing 1.2.x out the door :) | 20:48 |
micahg | nuclear_eclipse: I'm referring to Timecard (yours I believe) :) | 20:49 |
dhx_m | nuclear_eclipse: and if there are things waiting, put them in a follow-up 1.2.1 release | 20:49 |
nuclear_eclipse | yes, http://leetcode.net/mantis/ should do the trick :) | 20:49 |
nuclear_eclipse | dhx_m: sounds good to me | 20:49 |
micahg | k, thanks nuclear_eclipse, it's great, I just have an idea | 20:49 |
dhx_m | I'd much rather we stuck to some sort of release schedule so we have continuous releases | 20:49 |
nuclear_eclipse | yeah | 20:49 |
dhx_m | perhaps like the Linux Kernel... release every 3 months a 1.X release | 20:49 |
nuclear_eclipse | micahg: code submissions are always appreciated too :) | 20:50 |
dhx_m | and we support the last Y months of releases with critical bug fixes and security updates | 20:50 |
micahg | nuclear_eclipse: k, I might be up for that | 20:50 |
dhx_m | or does that not work for the Redhat "We can only use software older than 6 years" crowd? :p | 20:50 |
micahg | nuclear_eclipse: is it currently possible to display timecard entries for a single release? | 20:50 |
nuclear_eclipse | dhx_m: the real trouble is trying to support distros that will keep "stable" versions in their repos for up to 2 or 3 years | 20:50 |
micahg | nuclear_eclipse: I would suggest making 1 release every 2 or 3 years an LTS | 20:51 |
dhx_m | IMO it's their problem... the kernel (which is quite important!) doesn't do that | 20:51 |
nuclear_eclipse | very true | 20:51 |
dhx_m | instead you have Redhat maintaining their own kernel fork | 20:52 |
micahg | dhx_m: kernel is a lot more popular/complicated | 20:52 |
dhx_m | no one else is going to do it for them :p | 20:52 |
dhx_m | micahg: indeed it is, but they have a lot more people working on it too | 20:52 |
micahg | dhx_m: indeed | 20:52 |
nuclear_eclipse | dhx_m: I know Debian still uses 1.1.x, but what peeves me the most about Debian is that they more or less fork Mantis everytime they pull in a new version because of the way their silly DB system works | 20:52 |
dhx_m | micahg: I'm more referring to a smaller project such as MantisBT with only a handful of developers... maintaining old "stable" forks reliably isn't going to happen | 20:53 |
nuclear_eclipse | which causes a *lot* of issues for us because people have problems when they try to upgrade from a debian package to an official tarball | 20:53 |
dhx_m | just recently I've found things fixed in 1.3.x that hadn't been backported to 1.2.x | 20:54 |
micahg | dhx_m: the maintenance for stable releases in Ubuntu at least is high priority bugs and security updates | 20:54 |
nuclear_eclipse | it seems every time someone complains of an upgrade problem, the root cause is Debian =\ | 20:54 |
micahg | are there really that many CVEs for mantis that it's hard to support for 2-3 years? | 20:54 |
nuclear_eclipse | micahg: it's more a lack of developer time | 20:54 |
dhx_m | nuclear_eclipse: I'm not sure who moderates the mantisbt-dev mailing list, but I made a post (in moderation due to an attachment) about a new integrity checker I built into a revised check.php system | 20:54 |
dhx_m | nuclear_eclipse: essentially it tells users if they're using modified files, have stray left-overs hanging around from old releases, etc | 20:55 |
nuclear_eclipse | afaik, victor is the only maling list moderator, which I've tried to change multiple times and failed | 20:55 |
dhx_m | micahg: if I cared about CVEs, I would have submitted about 40 of them in the last few months for Mantis :) | 20:56 |
nuclear_eclipse | well, I think I'll start prepping my columns fix, and then once I get that patched in, start looking to another release | 20:56 |
micahg | dhx_m: that's not encouraging | 20:56 |
dhx_m | micahg: that is seriously how much more secure 1.3.x is when compared to some old "stable" version | 20:56 |
dhx_m | micahg: you need to learn to get used to it... most web software is filled with security bugs | 20:56 |
micahg | well, that makes me glad my company's mantis installation is behind a FW | 20:57 |
dhx_m | micahg: most of these security issues I point out are relatively minor... | 20:57 |
micahg | dhx_m: yes, but the hope is that when people find them, they patch/report them | 20:57 |
dhx_m | micahg: right, which is why they have been fixed quickly as they're discovered | 20:58 |
dhx_m | micahg: Mantis 1.2.x now has full CSRF protection, better security against XSS (I've done a lot of testing and fixing of obscure XSS problems), better cryptography in 1.3.x, etc | 20:59 |
micahg | dhx_m: cool | 21:00 |
nuclear_eclipse | speaking of "better" cryptography, dhx_m, I told you so | 21:00 |
nuclear_eclipse | openssl RNG is slow as balls | 21:00 |
dhx_m | nuclear_eclipse: I did say I didn't test openssl_pseudo_random_bytes :p | 21:00 |
micahg | I wish I had more time to contribute, but I'm already into too many open source projects | 21:00 |
dhx_m | nuclear_eclipse: I'll make it optional/off by default | 21:00 |
nuclear_eclipse | that would be appreciated :P | 21:00 |
dhx_m | nuclear_eclipse: in case someone has a fast hardware RNG | 21:00 |
nuclear_eclipse | it makes mantis on my VPS chug | 21:01 |
nuclear_eclipse | also dhx_m, we should switch from Docbook to Markdown :P | 21:02 |
dhx_m | nuclear_eclipse: yes please! :) | 21:02 |
dhx_m | nuclear_eclipse: I think you saw my post about MediaWiki a while ago... I'm not so sure about it though | 21:03 |
*** Quits: ZiNC (~zinc@188.120.158.32) (Read error: Connection reset by peer) | 21:03 | |
nuclear_eclipse | I've been putting together a simple pre-processor for Markdown that will do a few fancies right now | 21:03 |
*** Joins: ZiNC (~zinc@188.120.158.32) | 21:03 | |
dhx_m | nuclear_eclipse: but I still like the idea of making it easier for people to write documentation for Mantis | 21:03 |
nuclear_eclipse | eg, it scans the document for headers, and generates a TOC | 21:04 |
dhx_m | having to checkout a git repository, edit text files, create patches, submit them, etc is too much work | 21:04 |
nuclear_eclipse | well, I don't think so :P | 21:04 |
dhx_m | if you're a developer it's OK | 21:04 |
nuclear_eclipse | I actually like having the documentation version controlled with the source code | 21:04 |
dhx_m | same | 21:04 |
nuclear_eclipse | it makes it very straightforward to request appropriate documentation changes with patches, and trivializes the need for differing documentation for various versoin branches | 21:05 |
nuclear_eclipse | and tbh, I really don't think docbook is that difficult to work with; it's no harder than generating HTML... | 21:06 |
dhx_m | I just hate Docbook because of it's verbosity (XML = readable by computers, not by humans) | 21:06 |
nuclear_eclipse | and the Docbook tags are at least descriptive and consistent, more than you can say about HTML | 21:06 |
dhx_m | I wouldn't say I like HTML that much either though | 21:06 |
dhx_m | yes | 21:06 |
nuclear_eclipse | my point is that for a *web app*, if you can write HTML, writing Docbook should be trivial, esp since you can use the rest of the documentation as an example of how to do it | 21:07 |
nuclear_eclipse | hell, copy-paste and change the necessary bits if it's really that difficult | 21:07 |
nuclear_eclipse | my biggest complaint about Markdown is that it defers to HTML a bit too much, eg, no way to generate nested lists (that I know of), or to generate simple tables, etc | 21:09 |
nuclear_eclipse | but then again, that's also one of its biggest selling points | 21:10 |
dhx_m | yeah generating tables is horrible with plaintext documentation formats | 21:10 |
dhx_m | although most of the times people use tables, they shouldn't | 21:10 |
nuclear_eclipse | and Mediawiki's table format is almost as bad as raw HTML | 21:10 |
dhx_m | yep | 21:10 |
nuclear_eclipse | anyways, I'm toying with ideas to make | 21:11 |
nuclear_eclipse | rather | 21:11 |
nuclear_eclipse | to extend my Markdown preprocessor thingy work with a set of files, a la docbook | 21:11 |
nuclear_eclipse | it's still a very toyish script anyways | 21:11 |
nuclear_eclipse | don't even know if I'm gonna keep it or try something different | 21:12 |
nuclear_eclipse | I'm just trying to find a way to make a simple documentation format that's in between the complexities of markdown and docbook | 21:12 |
nuclear_eclipse | eg, I love the fact that Docbook can do a lot of generation of TOC, pages, etc | 21:13 |
nuclear_eclipse | and I like that it's trivial to link to exact positions in other pages and chapters | 21:13 |
dhx_m | yep | 21:14 |
nuclear_eclipse | eg, assuming you give everything of value in your docbook a unique id, you can link to any of those from anywhere else, regardless if you rearrange the documentation | 21:14 |
dhx_m | being able to nest sections at will is goo | 21:14 |
dhx_m | *good | 21:14 |
nuclear_eclipse | yep | 21:14 |
dhx_m | unlike LaTeX where it's all linear | 21:14 |
dhx_m | you can't have a chapter that you include at different depths elsewhere | 21:14 |
nuclear_eclipse | yeah, ntm Latex is all but greek to non-programmers | 21:14 |
dhx_m | although I did write a Mediawiki > LaTeX convertor that worked quite well :) | 21:15 |
dhx_m | section depth reordering, etc | 21:15 |
dhx_m | LaTeX formatted documents look a lot better than Docbook documents though | 21:15 |
nuclear_eclipse | I really wouldn't mind wikis if it weren't so easy to orphan or lose information in the depths of the database... | 21:16 |
dhx_m | Docbook output looks like Microsoft Word output... ugly word processor rubbish | 21:16 |
dhx_m | (at least the examples I've seen) | 21:16 |
nuclear_eclipse | so improve the docbook template we use :P | 21:16 |
dhx_m | there is a lot more to typography than what is possible with simple templates | 21:16 |
nuclear_eclipse | well, docbook uses lisp templates... | 21:16 |
nuclear_eclipse | so if it's not possible with lisp templates, that's pretty bad :P | 21:17 |
dhx_m | microtypography for instance is all about preventing word breaks at the end of lines, allowing periods and commas to overhang the text margin to make the text appear better aligned, etc | 21:17 |
dhx_m | the number of words per line is very important too, as is control over float placement, etc, etc | 21:17 |
nuclear_eclipse | I'd rather focus on actually getting things documented than making the documentation text pretty :P | 21:18 |
dhx_m | precisely why I prefer a Wiki... so anyone can help us out | 21:18 |
nuclear_eclipse | the question is whether you really want all those people to be writing the documentation... | 21:19 |
nuclear_eclipse | esp things like documenting the APIs or plugin system is stuff that I'd not want "normal" users touching... | 21:19 |
dhx_m | with some oversight it'd be OK | 21:19 |
dhx_m | I'm thinking Mediawiki's new FlaggedRevs extension | 21:20 |
nuclear_eclipse | yet another reason I like the barrier to entry of documentation in source control :P | 21:20 |
dhx_m | yep | 21:20 |
dhx_m | I'd prefer one or the other | 21:20 |
dhx_m | not both | 21:20 |
nuclear_eclipse | that still requires someone's time to sit there and review every submission... | 21:20 |
dhx_m | the Wiki at the moment is fairly useless if you ask me... outdated, uncared for, etc | 21:20 |
nuclear_eclipse | well, yes | 21:20 |
nuclear_eclipse | half the prolbem | 21:20 |
dhx_m | you only have to review them up to the point where you know the person making changes knows what they're doing (more or less) | 21:21 |
nuclear_eclipse | is that dokuwiki is the worst wiki I've ever seen | 21:21 |
nuclear_eclipse | (imo) | 21:21 |
nuclear_eclipse | I've had nothing but headaches from supporting it at my old job | 21:21 |
nuclear_eclipse | constant issues with permissions breaking because it stores everything on the filesystem, etc | 21:22 |
dhx_m | yep | 21:22 |
nuclear_eclipse | and tbh, giving web apps permission to write to the filesystem is a sysadmin's worst nightmare | 21:22 |
dhx_m | I don't mind it too much, if you know what you're doing | 21:24 |
dhx_m | ie. don't put a writeable folder in your wwwroot! :) | 21:24 |
nuclear_eclipse | yep | 21:24 |
nuclear_eclipse | but with dokuwiki, that's a requirement =\ | 21:24 |
dhx_m | and web servers generally serve multiple websites/web apps all using the same Unix user ID/group ID | 21:25 |
dhx_m | which means one site on a server can mess with a different site | 21:25 |
nuclear_eclipse | dhx_m: do you happen to know of anything else besides Latex and Docbook for generating documentation/manuals? | 21:25 |
dhx_m | (if you're writing to the file system in any way) | 21:25 |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 21:27 | |
dhx_m | nothing that would allow you to make pretty documentation for printing | 21:28 |
nuclear_eclipse | hrm | 21:29 |
nuclear_eclipse | that's a shame | 21:29 |
dhx_m | although I personally don't see why that is overly important thesedays | 21:29 |
dhx_m | you don't read software manuals from start to end :p | 21:29 |
dhx_m | you tend to search them for particular information and help | 21:29 |
nuclear_eclipse | do you have an example of what your wiki->latex thingy can generate? | 21:29 |
dhx_m | I guess if we're trying to make a "how to develop MantisBT" book it makes more sense | 21:29 |
dhx_m | sure, PM :) | 21:29 |
nuclear_eclipse | dhx_m: well, that's what the developers' guide is :P | 21:30 |
*** Quits: fanno (~Morten@90.184.93.233) (Read error: Connection reset by peer) | 21:36 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 265 seconds) | 21:36 | |
*** Quits: AzaToth (~azatoth@wikipedia/AzaToth) (Remote host closed the connection) | 21:47 | |
*** Joins: daryn_ (~INTERACT\@h102.67.29.71.dynamic.ip.windstream.net) | 21:49 | |
micahg | nuclear_eclipse: I just contributed a bug + patch :) | 21:49 |
micahg | for timecad | 21:49 |
micahg | *timecard | 21:49 |
nuclear_eclipse | yay! | 21:49 |
micahg | http://leetcode.net/mantis/view.php?id=103 | 21:49 |
dhx_m | afaik I have fixed it as well in my branch @ http://git.mantisforge.org/w/timecard/dhx.git?a=shortlog;h=refs/heads/modtimestamp | 21:51 |
dhx_m | which adds optional minute resolution to Timecard | 21:51 |
micahg | hmm, maybe I should've pulled your branch dhx_m | 21:52 |
dhx_m | you didn't just rewrite that functionality yourself did you? heh | 21:52 |
*** Quits: daryn (~INTERACT\@h52.149.55.139.dynamic.ip.windstream.net) (Ping timeout: 256 seconds) | 21:52 | |
micahg | dhx_m: nah, just a simple check for no time | 21:52 |
dhx_m | I don't even have a time_get_diff() function anymore | 21:53 |
micahg | dhx_m: yep, I just returned N/A which I guess isn't the best solution for a localized product | 21:54 |
nuclear_eclipse | a good bit of that plugin was written by a coworker, so I have no liability :P | 21:54 |
micahg | in light of that, maybe I'll update my patch... | 21:56 |
dhx_m | it even had carriage returns! | 21:57 |
dhx_m | nuclear_eclipse: check my branch out :p | 21:57 |
nuclear_eclipse | maybe when I have nothing better to do ;) | 21:57 |
dhx_m | haha | 21:57 |
dhx_m | btw micahg/nuclear_eclipse... my branch is 1.3.x only | 21:58 |
micahg | then I'll have to wait :) | 21:58 |
nuclear_eclipse | dhx_m: it's actually quite unfortunate that you changed db_table calls in 1.3, breaks 100% of my plugins... =\ | 21:59 |
nuclear_eclipse | dhx_m: review: http://mantis.pastebin.com/m70e2da97 | 21:59 |
micahg | I revised that patch to use a localizable string | 22:00 |
dhx_m | yeah it did expose the problem with plugins... changes upstream can easily break plugins | 22:00 |
dhx_m | so you really need to maintain a version of a plugin for each version of Mantis | 22:01 |
dhx_m | ... at least until the core Mantis API becomes stable... which will be never at this rate :p | 22:01 |
nuclear_eclipse | that's why I added the ability to specify a maximum mantis version | 22:01 |
dhx_m | yep | 22:01 |
dhx_m | I guess it'd be best to have the latest development version of each plugin as top tier on mantisforge | 22:02 |
dhx_m | scrap that... it's called branches duh :) | 22:02 |
nuclear_eclipse | lol | 22:02 |
dhx_m | I was going to suggest forking each plugin for each version of Mantis | 22:03 |
nuclear_eclipse | other alternative is to have conditionals in plugins for various apis :P | 22:03 |
dhx_m | ... not thinking | 22:03 |
dhx_m | nuclear_eclipse: you're lucky I can't reach through my screen and grab you at this moment :p | 22:03 |
nuclear_eclipse | ;) | 22:03 |
dhx_m | #ifdef SOMETHING #ifdef FIX1902 #ifdef APIV8 ... printf( 'Hello World' ); #endif #endif #endif | 22:04 |
micahg | most codebases do something similar for versioning.... | 22:04 |
* nuclear_eclipse <3 #ifdef | 22:05 | |
dhx_m | # | 22:05 |
dhx_m | * The following fields can not be included: | 22:05 |
dhx_m | # | 22:05 |
dhx_m | - * BUG_FIELD_ID, BUG_FIELD_PROJECT, BUG_FIELD_DATE_SUBMITTED, BUG_FIELD_LAST_UPDATED, BUG_FIELD_STATUS, | 22:05 |
dhx_m | # | 22:05 |
dhx_m | - * BUG_FIELD_RESOLUTION, BUG_FIELD_TAGS, BUG_FIELD_FIXED_IN_VERSION, BUG_FIELD_PROJECTION, BUG_FIELD_ETA, | 22:05 |
dhx_m | # | 22:05 |
dhx_m | - * BUG_FIELD_REPORTER. | 22:05 |
dhx_m | # | 22:05 |
dhx_m | + * 'id', 'project', 'date_submitted', 'last_updated', 'status', | 22:05 |
dhx_m | # | 22:05 |
dhx_m | + * 'resolution', 'tags', 'fixed_in_version', 'projection', 'eta', | 22:05 |
dhx_m | # | 22:05 |
dhx_m | + * 'reporter'. | 22:06 |
dhx_m | (grrr... bad spacing with copy/paste) | 22:06 |
nuclear_eclipse | flood :P | 22:06 |
dhx_m | I was going to suggest removing the quotation marks in those comments | 22:06 |
nuclear_eclipse | bah, that means I have to do more than a PCRE script... :P | 22:06 |
dhx_m | perhaps one field per line too in a list format | 22:06 |
dhx_m | ah :) | 22:06 |
dhx_m | otherwise looks good to me | 22:06 |
nuclear_eclipse | ok | 22:06 |
nuclear_eclipse | those constants are more annoying to type, and harder to grasp, than strings... | 22:07 |
dhx_m | yep | 22:07 |
nuclear_eclipse | and sticking with just strings will make an (eventual) plugin option more consistent | 22:07 |
dhx_m | I started work (if you'd call ~200 lines "started") on an OO approach to fields | 22:09 |
dhx_m | IntegerField, TextField, BooleanField, etc | 22:09 |
dhx_m | which are then extended to form things like PriorityField, SummaryField, etc | 22:10 |
dhx_m | so you have some base types (integers, currency fields, text fields, etc) that can be used for inbuilt fields as well as custom fields | 22:11 |
*** Quits: daryn_ (~INTERACT\@h102.67.29.71.dynamic.ip.windstream.net) (Remote host closed the connection) | 22:32 | |
nuclear_eclipse | dhx_m: good thing I tested my patch before committing :P | 22:39 |
dhx_m | nuclear_eclipse: oh you wanted me to do that? :p | 22:39 |
nuclear_eclipse | my script didn't check for category->category_id | 22:39 |
dhx_m | ah | 22:40 |
nuclear_eclipse | it was the only constant that didn't align with its string | 22:40 |
dhx_m | "openssl rand" on my computer outputs 100MB in a few seconds | 22:43 |
nuclear_eclipse | that's kinda slow :P | 22:44 |
dhx_m | for random numbers it's OK :) | 22:44 |
nuclear_eclipse | compare that to mt_rand | 22:44 |
dhx_m | mt_rand isn't secure though | 22:45 |
nuclear_eclipse | btw, I hate you | 22:45 |
nuclear_eclipse | APPLICATION ERROR #2900 | 22:45 |
nuclear_eclipse | For security reasons MantisBT will not operate when $g_crypto_master_salt is not specified correctly in config_inc.php. | 22:45 |
nuclear_eclipse | /facepalm | 22:45 |
nuclear_eclipse | so generate one :P | 22:46 |
nuclear_eclipse | and in any case, mt_rand is perfectly fine against all but the most persistent hackers -- you'll get a DOS attack before you get someone brutally singling out your randomly generated numbers for attack | 22:47 |
nuclear_eclipse | it's just a bugtracker for crying out loud | 22:47 |
nuclear_eclipse | any sufficiently-critical bugtracker will most likely be protected by a firewall, apache auth, or SSL client cert check ... | 22:49 |
dhx_m | haha | 22:49 |
nuclear_eclipse | or it'll be running over SSL | 22:49 |
dhx_m | we can't generate $g_crypto_master_salt without writing to config_inc.php | 22:49 |
nuclear_eclipse | I know, that was supposed to be a joke ;) | 22:49 |
dhx_m | :p | 22:49 |
nuclear_eclipse | dhx_m: I'd be more worried about usernames, passwords, and cookies running in the clear than someone potentially predicting the output from mt_rand, seriously | 22:51 |
micahg | BTW, if you guys need anything from Ubuntu, feel free to ping me on IRC | 22:51 |
nuclear_eclipse | micahg: I could use a job :) | 22:51 |
nuclear_eclipse | (paying job that is) | 22:51 |
micahg | nuclear_eclipse: http://webapps.ubuntu.com/employment/ | 22:51 |
nuclear_eclipse | micahg: any of those open for non-senior level engineers? :P | 22:52 |
micahg | nuclear_eclipse: idk, you'd have to read the individual descriptions | 22:53 |
nuclear_eclipse | ie, I graduated last may, and have only been doing "real" software engineering work for about three years, and no "official" experience beyond school projects and a job working on mantis | 22:53 |
micahg | that's a tough one... | 22:54 |
nuclear_eclipse | yep, it seems that's the way the entire job market is right now, esp if you don't live in NYC or California... | 22:54 |
dhx_m | I have just the job: | 22:55 |
micahg | nuclear_eclipse: maybe these: http://www.jobvite.com/CompanyJobs/Jobs.aspx?c=qpX9Vfwa | 22:55 |
dhx_m | http://hotjobs.yahoo.com/job-JHR3F06ROMU?source=SRP | 22:55 |
dhx_m | Comcast: check, CVS SCM: check, Java: check | 22:55 |
dhx_m | :p | 22:55 |
* nuclear_eclipse hits dhx_m with frying pan | 22:55 | |
dhx_m | unless that's a different CVS lol | 22:55 |
micahg | nuclear_eclipse: where are you located? | 22:56 |
nuclear_eclipse | Cincinnati, OH | 22:56 |
micahg | ah | 22:56 |
nuclear_eclipse | makes it difficult, because family and friends are here, and wifey doesn't want to move out of state | 22:57 |
micahg | nuclear_eclipse: http://www.jobvite.com/CompanyJobs/Job.aspx?c=qpX9Vfwa&v=1&j=orneVfwH | 22:57 |
dhx_m | nuclear_eclipse: that's true, but I guess crypto_api is really about using a standard approach to generating nonces (rather than reimplementing it multiple times in the codebase) | 22:57 |
nuclear_eclipse | dhx_m: I'm fine with that, I just think that we don't have any reason to need the power of openssl | 22:58 |
nuclear_eclipse | micahg: hmm, looks interesting, thank you | 22:58 |
dhx_m | nuclear_eclipse: yep I'm going to write it out as being optional | 22:58 |
micahg | nuclear_eclipse: np, good luck | 22:59 |
dhx_m | "Willingness to write tests (unit and functional), even if you don't want to" | 22:59 |
dhx_m | I love the "even if you don't want to" part :p | 22:59 |
nuclear_eclipse | the "remote possible" sounds like it would only work if I was head and shoulders above the other applicants though... =\ | 22:59 |
nuclear_eclipse | but it's still worth a try | 22:59 |
dhx_m | MantisBT development would probably help you out :) | 23:11 |
dhx_m | as it shows you "get" open source | 23:11 |
nuclear_eclipse | very true | 23:14 |
*** Joins: mantisbot (~supybot@81-174-26-126.static.ngi.it) | 23:19 | |
*** Quits: mantisbot (~supybot@81-174-26-126.static.ngi.it) (Ping timeout: 272 seconds) | 23:28 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!