| ../irclogs/#mantishelp.2010-06-29.log | ||
| --- scribe started --- | 00:00 | |
| dhx_m | #xoscommit is really annoying on our ManTweet page ;) | 00:00 |
|---|---|---|
| nuclear_eclipse | I know there's a bug for the roadmap/changelog issue, but I'm not sure if there's a bug posted for the filter issue | 00:00 |
| dhx_m | I'll try to remember to look into it with daryn's new filter code | 00:01 |
| dhx_m | otherwise remind me and I'll do a thorough test | 00:01 |
| dhx_m | (of versions... everywhere :)) | 00:01 |
| nuclear_eclipse | yeah, I know daryn's filter changes would make it difficult, so I was just wondering if there might be a quick/dirty fix that we could do just for 1.2.x... | 00:01 |
| dhx_m | we're still working on 1.2.x? | 00:02 |
| nuclear_eclipse | well, bug fixes for 1.2.x would be great :) | 00:03 |
| nuclear_eclipse | we do still need/want to support it | 00:03 |
| dhx_m | btw I finally upgraded my local install from lighttpd+fastcgi-wrapper+php-cgi (5.2)+xcache to nginx+php-fpm (5.3.3)+pecl-apc... so much faster :) | 00:04 |
| dhx_m | it's time consuming :( | 00:04 |
| nuclear_eclipse | I'd like to at least get a few of these fixes in and push a 1.2.2 release | 00:04 |
| dhx_m | the problem is that 1.2.x and 1.3.x are already quite different to each other so not much backports cleanly... it requires 2x the work to fix something | 00:05 |
| nuclear_eclipse | even though we're working on 1.3, people are still using 1.2 (or even 1.1 =\) for everything | 00:05 |
| dhx_m | how do I reproduce this bug? | 00:05 |
| dhx_m | add an inherited version | 00:06 |
| dhx_m | and see if it shows up in the "fixed in version" (etc) filter dropdowns? | 00:06 |
| nuclear_eclipse | select the child project, and go to view issues, and the inherited versions aren't shown in the filter dropdowns | 00:06 |
| dhx_m | aha | 00:06 |
| dhx_m | are they meant to inherit? | 00:07 |
| dhx_m | there is no option to toggle inheritance (as there is with categories) | 00:07 |
| nuclear_eclipse | well, there is an option, but it's a global option | 00:07 |
| nuclear_eclipse | and yes, it's enabled, because we use the inherited versions everywhere | 00:08 |
| dhx_m | $g_subprojects_inherit_categories | 00:08 |
| nuclear_eclipse | yep | 00:08 |
| dhx_m | $g_subprojects_inherit_versions | 00:08 |
| dhx_m | both default to ON | 00:08 |
| nuclear_eclipse | basically, the filter dropdowns aren't looking for versions from parent projects | 00:09 |
| dhx_m | if ( $p_project_id == ALL_PROJECTS ) { | 00:10 |
| dhx_m | $t_inherit = false; | 00:10 |
| dhx_m | } else { | 00:10 |
| dhx_m | if ( $p_inherit === null ) { | 00:10 |
| dhx_m | $t_inherit = ( ON == config_get( 'subprojects_inherit_versions' ) ); | 00:10 |
| dhx_m | so if you've got ALL_PROJECTS selected on the bugs view page | 00:11 |
| dhx_m | you won't see inheritied versions (there aren't any) | 00:11 |
| dhx_m | for me, nothing shows up for "Fixed in version" when ALL_PROJECTS is selected | 00:12 |
| dhx_m | seems wrong... I'd expect to see the versions of all projects and child projects, etc | 00:12 |
| nuclear_eclipse | yeah, I think the logic for that might have just been busted altogether or something =\ | 00:13 |
| dhx_m | do categories work ok for you? | 00:16 |
| nuclear_eclipse | yeah | 00:17 |
| dhx_m | ah | 00:19 |
| dhx_m | version_get_all_rows_with_subs has no concept of inherited versions | 00:19 |
| dhx_m | hmmm that didn't work | 00:26 |
| nuclear_eclipse | yeah, I couldn't find the root cause during my initial investigation | 00:27 |
| dhx_m | I suspect it may be the same issue that is affecting the roadmap/changelog | 00:39 |
| dhx_m | version_get_project_where_clause creates the list of projects from which versions are gathered from | 00:40 |
| dhx_m | and this function calls project_hierarchy_inheritance | 00:40 |
| nuclear_eclipse | yay fun | 00:40 |
| dhx_m | the where clause is returning projects 0 and 1 | 00:40 |
| dhx_m | when it should be returning 1, 3, 4 in my case | 00:41 |
| dhx_m | oh oops | 00:41 |
| dhx_m | I am looking at this the wrong way | 00:41 |
| dhx_m | it works now :) | 00:41 |
| dhx_m | ... sort of | 00:42 |
| dhx_m | projects nested 3 deep don't inherit anything | 00:42 |
| dhx_m | and subprojects aren't included in the version lists | 00:42 |
| dhx_m | sigh, project_hierarchy_inheritance isn't even a recursive function | 00:43 |
| dhx_m | how useless | 00:44 |
| nuclear_eclipse | welcome to the hell I went through :P | 00:44 |
| dhx_m | lol | 00:44 |
| dhx_m | what's your take on disabled projects... should they stop the recursive lookup or should they just be hidden from the total search results? | 00:49 |
| dhx_m | ie. ProjectA => ProjectB (disabled) => ProjectC | 00:50 |
| dhx_m | would the inherited versions list of Project C return Project A? | 00:50 |
| dhx_m | I would have though disabled projects should work recursively too | 00:50 |
| dhx_m | *thought | 00:50 |
| dhx_m | but that is broken too :p | 00:51 |
| nuclear_eclipse | they should stop the recursion IMO | 00:51 |
| dhx_m | yep | 00:51 |
| nuclear_eclipse | oh, never really thought about how to deal with disabled parent projects... | 00:51 |
| nuclear_eclipse | bluh | 00:52 |
| nuclear_eclipse | yet more hell | 00:52 |
| nuclear_eclipse | IMO that shouldn't be possible, or the disabled-ness should extend to the child projects too, but then a project can have multiple parents, and it all gets insane very quickly | 00:52 |
| dhx_m | indeed | 00:54 |
| dhx_m | REWRITE! :) | 00:54 |
| nuclear_eclipse | lol | 00:54 |
| dhx_m | I'll add that to my ever growing list of things to rewrite at some distant stage in the future | 00:55 |
| dhx_m | custom fields/fields being #1 still | 00:55 |
| dhx_m | although I think Daryn is interested in that too :) | 00:55 |
| dhx_m | this code sucks... it should be a simple tree search but isn't... | 00:56 |
| nuclear_eclipse | well, what makes it worse is knowing that the tree can potentially have loops, or children can have multiple parents... =/ | 00:57 |
| nuclear_eclipse | anywho, it's my bedtime | 00:57 |
| nuclear_eclipse | cheers mate | 00:57 |
| dhx_m | I'll have it fixed soon :) | 00:57 |
| dhx_m | cya later | 00:57 |
| dhx_m | oh no, this is really broken... the cache isn't recursive either | 01:00 |
| dhx_m | perhaps I will rewrite it now | 01:00 |
| dhx_m | daryn: hi :) | 03:36 |
| dhx_m | howdy | 13:33 |
| nuclear_eclipse | hi dhx_m | 13:36 |
| dhx_m | nuclear_eclipse: I've had a look at project hierarchy and I'm working on rewriting it | 13:39 |
| daryn | oh goody... | 13:40 |
| daryn | :) | 13:40 |
| dhx_m | my current thoughts are to implement MantisTree.class.php that implements a tree (computer science terms) and reads/writes to a database using the nested set model | 13:40 |
| nuclear_eclipse | oh dear | 13:40 |
| dhx_m | then MantisProjectHierarchy extends MantisTree | 13:40 |
| dhx_m | and we can reuse it for MantisVersion, etc | 13:40 |
| dhx_m | if that is needed | 13:41 |
| dhx_m | daryn: hey :) | 13:41 |
| daryn | gdday | 13:41 |
| nuclear_eclipse | dhx_m: KISS | 13:41 |
| dhx_m | we can't apply a simple fix to the problem you identified before nuclear_eclipse as project_heirarchy_api.php has no concept of 'trees' | 13:41 |
| dhx_m | it assumes there are two levels of projects ONLY | 13:42 |
| dhx_m | it is pretty simple :) | 13:42 |
| nuclear_eclipse | well, I just don't like having a bugfix turn into a complicated rewrite of a core API... =\ | 13:42 |
| nuclear_eclipse | that's a lot of changed code to push out for a maintenance release... | 13:43 |
| dhx_m | there is no other way to get nested projects to work for more than 2 layers | 13:43 |
| daryn | i'd say leave it broke in 1.2 then | 13:43 |
| dhx_m | well I might be able to get it to work with 2 layers of projects | 13:44 |
| nuclear_eclipse | well, IMO if it never worked with big chains before, is it possible to just fix the other bug in 1.2.x, and then do a rewrite for 1.3? | 13:44 |
| dhx_m | with minimal changes | 13:44 |
| daryn | nuclear_eclipse: you ever converted a git repo to svn? | 13:47 |
| nuclear_eclipse | good haevens no :P | 13:47 |
| daryn | i know... | 13:47 |
| dhx_m | garrgh my ears! | 13:47 |
| nuclear_eclipse | I know two potential methods though | 13:47 |
| daryn | we're using hudson to build mantis with plugins | 13:47 |
| daryn | hudson doesn't properly handle multiple git repos | 13:48 |
| daryn | but does svn | 13:48 |
| nuclear_eclipse | a) git can host a cvs server, and you could use SVN to convert the CVS repo... | 13:48 |
| nuclear_eclipse | b) there's a project available that can translate lots of various repo types to one another | 13:48 |
| nuclear_eclipse | I just can't remember the name of b) | 13:49 |
| daryn | tailor? | 13:49 |
| nuclear_eclipse | I think it starts with a t | 13:49 |
| nuclear_eclipse | yep | 13:49 |
| daryn | nuclear_eclipse: so much for tailor...:( | 14:54 |
| docgnome | is there a way to make it so reporters can't change the status of a ticket? I'm particular about how tickets are filed and we have a reporter who doesn't bother to read the docs and keeps changing the status | 15:38 |
| daryn | docgnome see Manage/Workflow Thresholds | 15:40 |
| daryn | Update issue status | 15:40 |
| daryn | and Limit reporter's access to their own issues | 15:41 |
| docgnome | ah. thanks. :-\ should have seen that. my bad | 15:41 |
| daryn | np | 15:41 |
| docgnome | huh. there isn't a checkbox for that option. | 15:42 |
| docgnome | like i see it in the table, but there are no controls to configure it | 15:42 |
| docgnome | how about a way to stop it from trying to assign tickets to me when i change the status? I keep forgetting that it puts me in that drop down automatically and keep having to unassign tickets | 15:43 |
| daryn | are you administrator? | 15:45 |
| docgnome | yeaha | 15:45 |
| daryn | hm..maybe it's new to dev | 15:45 |
| docgnome | running 1.2.1 | 15:45 |
| daryn | for Limit reporter, right? | 15:45 |
| docgnome | yeah | 15:46 |
| daryn | mine shows at bottom of list | 15:46 |
| docgnome | found a different way to do it though | 15:46 |
| docgnome | right, i see Limit Reporter blah blah blah there | 15:46 |
| docgnome | but no controls | 15:46 |
| docgnome | if i go to Workflow Transitions though i can set who has permissions to move tickets to what statuses | 15:46 |
| docgnome | so i just made it so they had to be higher than reporter to move ticket status | 15:47 |
| daryn | oh...limit reporter's just makes only see their own tickets | 15:47 |
| daryn | that works | 15:47 |
| docgnome | right. the second thing is bugging me more though heh | 15:47 |
| daryn | i don't know about that one | 15:47 |
| docgnome | durn. | 15:49 |
| nuclear_eclipse | daryn: I'm already exploiting github's new "organizations" feature... :P | 21:51 |
| daryn | haven't even looked | 21:52 |
| daryn | ic...i've been added to mantisbt organization | 21:52 |
| daryn | nifty | 21:52 |
| nuclear_eclipse | it gives a "canonical" endpoint for projects to host repos without requiring a shared account | 21:53 |
| nuclear_eclipse | I'd personally like to see Github become the official repo location for Mantis | 21:54 |
| nuclear_eclipse | just because it has so many nice features, and it makes collaboration so easy | 21:54 |
| daryn | i think i'm ok with that | 21:55 |
| daryn | i'm using it anyhow | 21:55 |
| nuclear_eclipse | yeah, my biggest | 21:55 |
| nuclear_eclipse | oops | 21:55 |
| daryn | we wouldn't have to worry about mantisforge crashing either | 21:55 |
| nuclear_eclipse | my concern is that we'd be losing post-commit emails and CIA.vc notifications, or at least not without a bit of custom scripting attached to Github's hooks | 21:57 |
| nuclear_eclipse | oh, hmm, Github supports CIA now | 21:57 |
| nuclear_eclipse | nifty, they've completely revamped their service hooks since I last looked | 21:58 |
| nuclear_eclipse | apparently I could write an "official" service hook that notified my source-integration plugins | 21:58 |
| nuclear_eclipse | I'd just have to learn how to write it in Ruby :P | 21:58 |
| daryn | cool | 21:58 |
| nuclear_eclipse | nevermind then :P | 21:58 |
| nuclear_eclipse | it seems the only hurdle is a) getting people to agree, and b) having people update their git remotes | 21:59 |
| nuclear_eclipse | dhx_m: you on board? | 22:00 |
| nuclear_eclipse | siebrand: ? | 22:00 |
| daryn | so...i have a mantisbt fork where i do dev before pushing to the official repo...should that go away and dev on branches in official? or should still use a fork? | 22:00 |
| nuclear_eclipse | I'd still use a fork for anything that's not an officially-supported branch | 22:00 |
| daryn | k | 22:00 |
| nuclear_eclipse | this would certainly make it easier to manage developers who have access to push to the repository | 22:01 |
| nuclear_eclipse | and it would also give an official pull-request mechanism that could send email to the mantisbt-dev list | 22:02 |
| daryn | i'm in | 22:04 |
| nuclear_eclipse | ok, the IRC notification from Github is pretty nifty | 22:07 |
| nuclear_eclipse | 18:06 - - Github [~Github@sh1-ext.rs.github.com] has joined #leetcode | 22:07 |
| nuclear_eclipse | 18:06 < Github> leetcode: master John Reese * 5ff0525 (1 files in 1 dirs): Added Piwik stats tracking code | 22:07 |
| nuclear_eclipse | 18:06 < Github> leetcode: master John Reese * 550b683 (1 files in 1 dirs): Updated URL to repo on Github | 22:07 |
| nuclear_eclipse | 18:06 < Github> leetcode: master commits 950e1d5...550b683 - http://bit.ly/9yjOCd | 22:07 |
| nuclear_eclipse | 18:06 - - Github [~Github@sh1-ext.rs.github.com] has left #leetcode [] | 22:07 |
| nuclear_eclipse | the email notification, not so much | 22:08 |
| nuclear_eclipse | email doesn't contain a diff, but I guess the real question is how much do people care about that or actually look at it? | 22:08 |
| daryn | weird...why does it show the official is forked from my fork? | 22:09 |
| nuclear_eclipse | because I forked it from mine, and then deleted mine, so yours in the oldest in that forking group | 22:09 |
| daryn | ah...so i should delete mine too | 22:09 |
| nuclear_eclipse | meh | 22:10 |
| nuclear_eclipse | you can if you want, but I wouldn't worry too much about it | 22:10 |
| daryn | just makes me look more important than i am, heh | 22:10 |
| nuclear_eclipse | I like the auto-generated bitly link in the IRC hook, just wish the email hook contained the same thing... | 22:11 |
| nuclear_eclipse | anywho, dinner time | 22:11 |
| nuclear_eclipse | cheers | 22:11 |
| daryn | cheers | 22:11 |
| daryn | nuclear_eclipse: this notice just popped up on my github page - "Know anyone that prefers Mercurial? Tell them they can use GitHub with our hg-git plugin." Now maybe paulr will be happy... | 22:33 |
| rb__ | hello all | 22:45 |
| rb__ | any warm bodies here | 22:45 |
| rb__ | anybody? | 23:02 |
Generated by irclog2html.py