| ../irclogs/#mantishelp.2010-01-28.log | ||
| --- scribe started --- | 00:00 | |
| CIA-19 | Mantisbt: hickseydr * rc0bdd8c98395 / (4 files in 2 dirs): Fix #11041: set_status_threshold doesn't work on a per-project basis | 00:57 |
|---|---|---|
| CIA-19 | Mantisbt: hickseydr master-1.2.x * r9a55e85ce5b0 / (4 files in 2 dirs): Fix #11041: set_status_threshold doesn't work on a per-project basis | 00:57 |
| alemayo | hi | 06:08 |
| alemayo | argh ... i hate helper_get_tab-index | 06:08 |
| alemayo | why do we need tabindex by the way ? | 06:08 |
| alemayo | don't do (all?) browsers anyway's arrange the tabindex sequentially ? | 06:09 |
| alemayo | the problem is, that I am dynamically (javascript) adding new rows with <input> fields - and taking care properly of the tabindex does not seem to be easy | 06:09 |
| kenguest | lo. what release was CVE-2008-4687 fixed in? Can't find mention of it in http://www.mantisbt.org/bugs/changelog_page.php | 11:17 |
| dhx_m | kenguest: http://git.mantisbt.org/?p=mantisbt.git;a=commit;h=4e32f5ae03f0efd3f5fc8de71ce154a37843afc3 | 11:42 |
| dhx_m | so, bug 9704 | 11:42 |
| * dhx_m wonders what the point of CVE is... it doesn't appear the public can amend the status/information on a bug? | 11:46 | |
| dhx_m | (even with a trusted review system in place) | 11:46 |
| kenguest | so fixed in release 1.1.4 and onwards. ok. | 11:46 |
| dhx_m | yep | 11:47 |
| kenguest | thanks for helping me answer my own question :D | 11:48 |
| dhx_m | haha | 11:48 |
| dhx_m | I have to say I agree with Linus' stance on security bugs | 11:49 |
| kenguest | which is? | 11:49 |
| kenguest | oh. http://bugs.php.net/bug.php?id=50696 | 11:49 |
| kenguest | is kinda entertaining btw ;-) | 11:49 |
| dhx_m | lol at that bug report | 11:51 |
| dhx_m | my favourite quote: "Part of your responsibility in your position is to keep track of your tools and the changes coming down the pipeline." | 11:53 |
| dhx_m | is there a bash.org for open source bug reports and mailing list threads? :) | 11:55 |
| kenguest | well...if there isn't, there ought to be :D | 11:55 |
| kenguest | the url for that bug report is currently in the topic for #php.pecl - that's how I found it | 11:56 |
| dhx_m | hah | 12:03 |
| kenguest | "Again, I sincerely apologize. We will try to stop fixing bugs in PHP. | 12:06 |
| kenguest | " | 12:06 |
| kenguest | gotta love it | 12:06 |
| dhx_m | it's funny because it's some unappreciative jerk who thinks he's PHP's #1 customer and concern | 12:12 |
| kenguest | and there've been a few of those. | 12:15 |
| mantisbot | Bug 9704 - thosjo - fixed - closed | 12:32 |
| mantisbot | Remote Code Execution in manage_proj_page.php - http://www.mantisbt.org/bugs/view.php?id=9704 | 12:32 |
| dhx_m | congratulations mantisbot... that was a very speedy 50 minute lookup :p | 12:35 |
| dawitaya | hi | 13:02 |
| alemayo | is there a way to inherit the database-configuration settings to subprojects ? | 13:38 |
| alemayo | how can I configure my_view_boxes per project? it is an assoc. array and the syntax in that configuration dialog is not clear | 14:13 |
| paul__ | nuclear_eclipse: dhx_m : both around? | 18:10 |
| nuclear_eclipse | paul__: here now | 19:48 |
| paul__ | so john | 21:09 |
| paul__ | we have someone new to triage bug reports? | 21:09 |
| nuclear_eclipse | yep | 21:11 |
| paul__ | whats your preferred webserver ? | 21:11 |
| paul__ | nginx or apache or what? | 21:12 |
| nuclear_eclipse | apache | 21:12 |
| paul__ | it's starting to nnoyme | 21:14 |
| dhx_m | hi | 21:16 |
| paul__ | lo | 21:16 |
| paul__ | dhx_m: you got bored today? | 21:19 |
| dhx_m | with my email? | 21:20 |
| paul__ | ya | 21:20 |
| dhx_m | it's been on my mind for a while :) | 21:20 |
| paul__ | it's an interesting 'problem' now a days | 21:20 |
| paul__ | from one point of view wiki's are great | 21:21 |
| paul__ | from another, if your gonna use it as a manual and export it to pdf | 21:21 |
| paul__ | you could end up spending hours managing changes to it | 21:21 |
| dhx_m | don't worry about that... converting to PDF isn't hard :) | 21:21 |
| dhx_m | you just create a page of links to other pages on the Wiki | 21:21 |
| paul__ | I think we should have video's to show users how to submit bugs :P | 21:21 |
| dhx_m | as in, a table of contents | 21:21 |
| dhx_m | and set your script on that page at regular intervals to rebuild the PDF | 21:22 |
| dhx_m | my real concern was not having documentation in a git repository (hence commits + documentation are split from each other) | 21:22 |
| paul__ | that's more structure | 21:23 |
| dhx_m | although I suppose the kind of documentation we need isn't the type you'd typically commit | 21:23 |
| paul__ | I know one of you two dislike it | 21:23 |
| paul__ | but i know in mercurial | 21:23 |
| paul__ | someone set up our 'intranet' | 21:23 |
| paul__ | to pull in multiple repositories | 21:23 |
| paul__ | which is kinda cool as you put 1 lib in one repo etc | 21:23 |
| paul__ | at same time, does make life more interesting | 21:23 |
| dhx_m | yep | 21:23 |
| dhx_m | I just think our current Wiki is too hard for our users to edit (restrictions are very tight on making new pages, for instance) | 21:24 |
| dhx_m | and is outdated | 21:24 |
| dhx_m | more to the point, it duplicates our efforts with the Docbook manual | 21:24 |
| nuclear_eclipse | dhx_m: I'd much rather see the current wiki information dumped into docbook | 21:28 |
| nuclear_eclipse | wiki markup is much harder to understand and edit IMO than tags that are quite explicit about what they mean | 21:29 |
| paul__ | we still need to convert our docbook content to xml! | 21:29 |
| dhx_m | I'd argue that Wiki markup is more natural to humans | 21:30 |
| dhx_m | you don't have to constantly write out a million XML tags | 21:30 |
| nuclear_eclipse | there aren't all that many tags in docbook... | 21:30 |
| dhx_m | XML is great at allowing computers to talk to each other | 21:30 |
| dhx_m | but not so good at letting humans talk to a computer | 21:30 |
| dhx_m | IMO at least | 21:30 |
| nuclear_eclipse | there's almost as much markup in wiki, but it's much less explicit | 21:30 |
| nuclear_eclipse | <code>...</code> is much easier to understand and write than making sure you have 4 spaces in front of any random preformatted content | 21:31 |
| paul__ | I'd like to see us change how we store the docbook stuff and how we build it a little, but I quite like the idea of having manual in 'docbook' as it were | 21:31 |
| dhx_m | most Wiki source formatting is done with <code> tags anyway :) | 21:31 |
| nuclear_eclipse | and btw, we can have just as many links to other doc pages in docbook as you can on a wiki ;) | 21:32 |
| dhx_m | but what about links between different Docbook manuals? | 21:32 |
| paul__ | (i'd like to align our docbook stuff to how php.net do theres so we can get editing/commenting functionality in easily) | 21:32 |
| nuclear_eclipse | I dunno about that, I've never even tried | 21:32 |
| paul__ | If we moved to a wiki | 21:32 |
| paul__ | whilst wiki's are great and all | 21:32 |
| paul__ | we need to monitor what gets changed | 21:33 |
| paul__ | delete any junk/spam before it turns up in a pdf manual | 21:33 |
| nuclear_eclipse | I think the real problem with wikis is that you both want user contribution, but don't want "bad" user contribution, and there's no way to properly maintain that without someone dedicated to reviewing every single user contribution | 21:33 |
| dhx_m | well there is FlaggedRevs to let you do just that | 21:33 |
| dhx_m | at least it would be getting documented :p | 21:34 |
| nuclear_eclipse | or trashed, or documented incorrectly, or... | 21:34 |
| paul__ | tbh, i'd like to simplify things a bit | 21:34 |
| paul__ | dhx/myself had a discussion about templates etc other day | 21:35 |
| paul__ | and my issues with mantis atm for that | 21:35 |
| paul__ | also kinda applies to the manual | 21:35 |
| nuclear_eclipse | ntm there's never any proper or automatically-maintained index or order to wiki information, it's just randomly available from some other random page, and impossible to find what you want | 21:35 |
| paul__ | atm, we have a config variable for everything | 21:35 |
| paul__ | I'm surprised actually we don't have a config variable to specify the colour of the mantis logo | 21:36 |
| paul__ | nuclear_eclipse: is there a method atm to see what hooks are registered | 21:37 |
| dhx_m | nuclear_eclipse: not necessarily, you can make "portal pages" | 21:37 |
| dhx_m | nuclear_eclipse: ie. top level pages that have a sole purpose of linking to content in a particular order | 21:37 |
| dhx_m | nuclear_eclipse: for example, http://en.wikibooks.org/wiki/X86_Assembly | 21:39 |
| dhx_m | then a Wiki=>LaTeX conversion script can scrape the table of contents page to structure a book out of different Wiki pages | 21:39 |
| nuclear_eclipse | dhx_m: those still have to be manually maintained | 21:40 |
| nuclear_eclipse | docbook by definition builds a proper index for everything in the manual based on the headers and section orders | 21:40 |
| nuclear_eclipse | paul__: not without looking at the global cache set up by event_api | 21:41 |
| dhx_m | nuclear_eclipse: you'd typically have a chapter per file with DocBook, and a master page that acts as an index | 21:41 |
| nuclear_eclipse | paul__: not sure there should be any need to find that inforamiot though | 21:41 |
| dhx_m | not too different to how it's handled on a Wiki in other words | 21:42 |
| nuclear_eclipse | dhx_m: my point is that it's impossible to add sections to a docbook manual without the newly generated index reflecting that change, and in a "proper" ordering based on where the section was added | 21:43 |
| paul__ | need a reboot | 21:43 |
| paul__ | brb | 21:43 |
| nuclear_eclipse | ie, if I added a new section to the event reference chapter, the index automatically lists that section in the proper order | 21:43 |
| dhx_m | nuclear_eclipse: well with a Wiki, you'd insert a new page with content, add a link in the table of contents page and rebuild the PDF... with similar results | 21:44 |
| dhx_m | the only catch is needing to edit two places instead of one | 21:44 |
| paul__ | more work | 21:44 |
| paul__ | :) | 21:44 |
| dhx_m | but given how often one would want to add new content vs modify existing pages, it's not too significant | 21:44 |
| nuclear_eclipse | yes, my point being that it's a) more manual work, and b) impossible to police general users to make sure they do that | 21:44 |
| dhx_m | I think general users would be more likely to fix mistakes and improve wording | 21:45 |
| dhx_m | than rewrite whole chunks of the manual? | 21:45 |
| nuclear_eclipse | with Openmoko, they hired someone to do nothing but keep track of the wiki, and it consumed her fulltime job just to maintain the indexes and portal pages, and make sure there weren't any dangling or orphaned pages, etc | 21:45 |
| nuclear_eclipse | it's an immense amount of work to keep a wiki in usable condition, and it will not happen on its own | 21:46 |
| dhx_m | it'd also be a lot of work to take all of Openmoko's documentation efforts and start using Docbook | 21:46 |
| dhx_m | ie. merging branches of changes to the manuals, etc | 21:46 |
| nuclear_eclipse | yes, but converting wiki to docbook is a one-off piece of effort -- continually maintaining a wiki is an endless sink of time and effort... | 21:47 |
| dhx_m | I agree it'd be a little costly at first setting up pages and copying content across from the current Wiki and Docbook manuals | 21:47 |
| dhx_m | but maintaining a Docbook manual is also a lot of effort when you have a lot of editors | 21:47 |
| nuclear_eclipse | or without effort, it becomes the worthless cesspool that we already have on the wiki for mantis... ;) | 21:48 |
| dhx_m | it doesn't scale as well because you'd have to be managing merge conflicts more often | 21:48 |
| nuclear_eclipse | not really | 21:48 |
| nuclear_eclipse | it's text | 21:48 |
| nuclear_eclipse | it's no harder to handle merges than in code | 21:48 |
| dhx_m | not hard, time consuming :) | 21:48 |
| nuclear_eclipse | can't possibly be any more time than trying to maintain a wiki | 21:49 |
| dhx_m | there isn't that much work involved | 21:49 |
| nuclear_eclipse | ... | 21:49 |
| dhx_m | especially if you have something like FlaggedRevs | 21:50 |
| nuclear_eclipse | on the surface, I would agree, a wiki is the easy option, but to keep a wiki in a usable fashion, to review user changes to make sure they don't trash content, etc, is a lot more work is the end | 21:50 |
| nuclear_eclipse | and you really can't expect a wiki to be anywhere near as useful to publish/distribute with releases as opposed to a manual built from the ground up to be a published document | 21:51 |
| nuclear_eclipse | the end goal of the docbook efforts is that the very same documentation found on mantisbt.org is the documentation that gets distributed with every release of Mantis | 21:52 |
| dhx_m | you can convert from Wiki => LaTeX without much effort and it looks much better than Docbook output :) | 21:52 |
| dhx_m | we've actually had people complaining about accessibility of documentation in our release tarballs | 21:53 |
| nuclear_eclipse | it might have a better template, but it's not going to be nearly as usable to the person looking for help or instruction | 21:53 |
| dhx_m | not that a Wiki would help that ;) | 21:53 |
| dhx_m | why do you say that? hyperref can add bookmarks, hyperlinks, etc to PDFs | 21:54 |
| nuclear_eclipse | because wikis by definition have no proper ordering of content | 21:54 |
| nuclear_eclipse | you can't take a giant stack of pages and say "this one is the first section, this is the next, etc" | 21:55 |
| nuclear_eclipse | or at least not on any wiki I know of | 21:55 |
| dhx_m | well you can create index pages and/or navigation templates | 21:55 |
| nuclear_eclipse | /facepalm :P | 21:55 |
| nuclear_eclipse | you keep mentioning my biggest dislike of wikis as the reason why it'll work... | 21:56 |
| dhx_m | more to the point, I doubt the first place people would want to go for documentation is a PDF in book format (straight from the 18th century) which is hard to search and navigate through | 21:56 |
| nuclear_eclipse | that's why we distribute the HTML format documentation too... | 21:57 |
| dhx_m | whereas in a Wiki, the pages get searched by Google and appear easily in search results | 21:57 |
| daryn | you know i think dhx_m and nuclear_eclipse need to get an opinion. it's obvious neither of you has one. | 21:57 |
| dhx_m | lol | 21:57 |
| nuclear_eclipse | shut up daryn :>P | 21:57 |
| daryn | :D | 21:57 |
| nuclear_eclipse | dhx_m: our docbook pages already show up in google searches... | 21:57 |
| dhx_m | the HTML documentation is ugly :p | 21:57 |
| dhx_m | source code syntax highlighting, images, etc | 21:58 |
| nuclear_eclipse | dhx_m: so help improve the templates... | 21:58 |
| nuclear_eclipse | I've already been making a few small efforts | 21:58 |
| nuclear_eclipse | but I barely have time to write the documentation, let alone make a docbok template... | 21:59 |
| daryn | documentation? we have documentation? | 21:59 |
| nuclear_eclipse | http://www.mantisbt.org/docs/master/en/ | 21:59 |
| dhx_m | the reason I don't write documentation is similar to the view here: http://www.ibm.com/developerworks/library/x-sbxml.html | 22:00 |
| dhx_m | "Soapbox: Humans should not have to grok XML" | 22:00 |
| nuclear_eclipse | seriously dhx_m, our docbook isn't xml... | 22:00 |
| nuclear_eclipse | and tags are really not that hard .. | 22:00 |
| dhx_m | it's not too bad | 22:01 |
| dhx_m | but things like: | 22:02 |
| dhx_m | <link linkend="dev.events.types">event type</link> | 22:02 |
| dhx_m | vs. | 22:02 |
| dhx_m | [[Some page]] | 22:02 |
| dhx_m | still make it a bit more verbose in places | 22:02 |
| nuclear_eclipse | the most "ugly" part is giving an id to things, but that's just so that you can link to it more easily from other sections | 22:02 |
| dhx_m | it's even uglier in LaTeX :) | 22:02 |
| paul__ | wow guys | 22:03 |
| dhx_m | also can you reuse pages easily between different Docbook manuals? | 22:03 |
| dhx_m | ie. you want the same page/section to be included in all our manuals? | 22:03 |
| paul__ | I think | 22:03 |
| paul__ | we should use adobe's tech suite | 22:03 |
| paul__ | for manual! | 22:03 |
| dhx_m | preserving section numbering/depth, etc | 22:03 |
| dhx_m | paul__: I AGREE | 22:04 |
| dhx_m | paul__: :p | 22:04 |
| * paul__ is being serious | 22:04 | |
| nuclear_eclipse | dhx_m: actually, yes we could | 22:04 |
| paul__ | http://www.adobe.com/products/technicalcommunicationsuite/ | 22:04 |
| daryn | how about MS Word? | 22:04 |
| paul__ | http://www.adobe.com/products/technicalcommunicationsuite/ | 22:04 |
| nuclear_eclipse | with unique ids for each section, we could include sections in multiple docbook manuals | 22:04 |
| dhx_m | daryn: too usable and recent, I recon MS Works is better | 22:05 |
| paul__ | capitvate demo's of how to do stuff | 22:05 |
| paul__ | framemarker/robehelp for docs | 22:05 |
| dhx_m | nuclear_eclipse: well that's good then, better than LaTeX with that regard :) | 22:05 |
| paul__ | what you guys reckon? | 22:05 |
| dhx_m | paul__: too cheap, only US$1900... I only use software US$10k and up | 22:06 |
| paul__ | it can't be that much | 22:06 |
| nuclear_eclipse | what OS do you use? | 22:06 |
| nuclear_eclipse | cuz not even solaris costs that much.. | 22:06 |
| dhx_m | I wrote my own OS in Mediawiki thanks :p | 22:07 |
| nuclear_eclipse | then you can't use it, because it didn't cost you... | 22:07 |
| dhx_m | $10k development costs at least :) | 22:07 |
| nuclear_eclipse | anyways | 22:07 |
| dhx_m | btw did anyone see kenguest's link to: http://bugs.php.net/bug.php?id=50696 | 22:08 |
| paul__ | now you guys are billy sill | 22:08 |
| nuclear_eclipse | if you want to put in the effort to convert all the documentation to wiki, and then spend all the effort to build a whole new toolchain to make distributable pdf/html manuals, and then spend the effort to build and maintain indexes and portal pages, and review all the user contributoins, and make sure we don't have orphaned pages or things that nobody can find, that would be fine with me | 22:09 |
| paul__ | kenguest? | 22:09 |
| paul__ | when was that? | 22:09 |
| nuclear_eclipse | I just think it's a lot less effort for better results to maintain manuals in docbook | 22:09 |
| dhx_m | 11hrs ago | 22:10 |
| nuclear_eclipse | I saw that link posted on Hacker News a few weeks ago | 22:10 |
| dhx_m | well there were a number of other reasons I touched on too such as making the website easily editable as well | 22:10 |
| dhx_m | and thus easy translation of the web page and manual | 22:10 |
| dhx_m | if anyone can be bothered that is | 22:10 |
| nuclear_eclipse | dhx_m: I do like the idea of site and documentation being under one roof | 22:11 |
| paul__ | dhx_m: tbh | 22:11 |
| paul__ | that should return "" not NULL :P | 22:11 |
| nuclear_eclipse | paul__: +1 :P | 22:11 |
| dhx_m | paul__: lol :) | 22:11 |
| paul__ | string number_format ( float $number [, int $decimals ] ) | 22:12 |
| paul__ | string | 22:12 |
| paul__ | ;) | 22:12 |
| nuclear_eclipse | dhx_m: anyways, I don't mean to just shut down your idea altogether, I was just trying to voice my general concerns about the cost of maintaining a quality wiki | 22:12 |
| nuclear_eclipse | sorry for getting a little overheated about it | 22:12 |
| dhx_m | nuclear_eclipse: I appreciate your comments and do agree it's a bit of work setting it up (although I'd tend to disagree on running maintenance costs) | 22:13 |
| dhx_m | and for the record, you haven't see my overheated in a debate about software :p | 22:14 |
| nuclear_eclipse | dhx_m: we can't even get decent turnaround time on forum moderations, so I have little hope for wiki moderations... :P | 22:14 |
| dhx_m | we have forums? :p | 22:14 |
| nuclear_eclipse | yeah, exactly | 22:14 |
| dhx_m | every time I've visited I think my activity has followed this pattern: | 22:15 |
| dhx_m | 1) click on a forum | 22:15 |
| nuclear_eclipse | it's a bunch of whinging users who can't figure out how to get Mantis to work correctly with everything else... | 22:15 |
| dhx_m | 2) skip half way down the page beyond all the "helpme!!!!1!" and "plz fix Mantis" threads | 22:15 |
| dhx_m | 3) see something that finally might be worth looking at ("How do I integrate DokuWiki with Mantis?") | 22:16 |
| dhx_m | 4) open it up and see "HELP ME NOW!" as the message (or something similarly useless) | 22:17 |
| dhx_m | 5) give up | 22:17 |
| nuclear_eclipse | dhx_m: I worry that with an open wiki we'll eventually see idiots posting support questions on the instructions page 5 lines above the answer.... :P | 22:17 |
| dhx_m | nuclear_eclipse: oh I'm sure it'd happen... or we'd have people editing incorrect rubbish into it "You can integrate Mantis with Microsoft Excel 97 by using this .exe file" | 22:19 |
| dhx_m | but I still think a Wiki would be easier to use even if it were limited to developers and other trusted users | 22:20 |
| dhx_m | or FlaggedRevs was used | 22:20 |
| dhx_m | anyhow, I've gtg for now | 22:23 |
| nuclear_eclipse | like I said, if you are willing to put in the effort, I'd be willing to help arrange it all | 22:23 |
| dhx_m | will be away for a week, so I won't be on IRC | 22:24 |
| dhx_m | but I'm still reading emails :) | 22:24 |
| dhx_m | when I get back I might have a look at it and setup a demo Wiki to demonstrate the idea | 22:24 |
| dhx_m | I already have config from "one prepared earlier" to make that an easier job to handle | 22:24 |
| nuclear_eclipse | ok, well have fun for a week | 22:25 |
| nuclear_eclipse | cheers david | 22:25 |
| paul__ | fun for a week?? | 22:26 |
| paul__ | oh | 22:26 |
| dhx_m | also HgWeb is updated for 0.14, but no file parsing yet ;) | 22:26 |
| dhx_m | holiday :) | 22:26 |
| nuclear_eclipse | ok | 22:26 |
| dhx_m | be good with commits while I'm away :p | 22:27 |
| dhx_m | cya | 22:27 |
| nuclear_eclipse | bye | 22:27 |
Generated by irclog2html.py