| ../irclogs/#mantishelp.2009-04-23.log | ||
| --- scribe started --- | 00:00 | |
| nuclear_eclipse | dhx_m: talk to giallu, he wrote it :) | 00:28 |
|---|---|---|
| dhx_m | nuclear_eclipse: yep, I wasn't directing that towards you :) | 00:28 |
| nuclear_eclipse | ah, ok | 00:29 |
| dhx_m | I'm trying to import the Mantis repo from mantisforge... so slow | 00:29 |
| dhx_m | a nice feature would be the ability to perform a shallow checkout/import | 00:29 |
| dhx_m | ie. only import commits from point X in time | 00:29 |
| nuclear_eclipse | yeah, the downside to the current implementation is that it's just screen-scraping gitweb | 00:30 |
| dhx_m | yep | 00:31 |
| dhx_m | if I have a branch... it doesn't try to import every commit from the branch separately does it? | 00:31 |
| nuclear_eclipse | an eventual goal would be to somehow utilize cli to do the imports, but I'm not too fond of requirong Mantis to clone the entire repo locally =/ | 00:31 |
| dhx_m | yeah true | 00:31 |
| nuclear_eclipse | it'll only import unique commits, so as soon as it gets through the unique portion of the branch, it'll stop | 00:32 |
| dhx_m | I guess you could have the ability to use git CLI to read a local repo | 00:32 |
| dhx_m | and just give the user the option? | 00:33 |
| dhx_m | or more precisely... a new "localgit" plugin | 00:33 |
| nuclear_eclipse | that's an option, but still requires a local copy of the repo *somewhere*... | 00:33 |
| dhx_m | yep, it'd be the responsbility of the admin to create the local clone, keep it updated, etc | 00:34 |
| dhx_m | or maybe Mantis could update it | 00:34 |
| dhx_m | unless git can read remotely via ssh | 00:34 |
| nuclear_eclipse | no, that's what I originally wanted to, a la svn remote logging style import, but I couldn't find a way to do it without just cloning altogether... =/ | 00:36 |
| dhx_m | hmm you're right | 00:37 |
| dhx_m | I personally don't see a problem with a local repo | 00:38 |
| dhx_m | I can understand why some might | 00:38 |
| dhx_m | maybe a local repo can be maintained | 00:38 |
| dhx_m | where it only holds the latest commits that need importing | 00:38 |
| nuclear_eclipse | biggest obstacles are a) where to create the clone, b) how to handle keeping it up to date, c) how to handle merge/rebase conflicts | 00:39 |
| dhx_m | you're right that merge/rebase conflicts wouldn't work | 00:39 |
| nuclear_eclipse | and so I just got to the point that I figured it was simpler and less error prone to just screen-scrape until I could determine a better solution | 00:40 |
| dhx_m | yeah every idea I'm trying to come up with at the moment leads to problems | 00:40 |
| dhx_m | like "how many revisions are waiting to be imported" | 00:41 |
| nuclear_eclipse | the downside is performance, but only when using a remote gitweb server, and after the initial import, the cost is basically negligible compared to the benefits | 00:41 |
| nuclear_eclipse | well, even the gitweb solution more or less just blindly imports commits until it reaches commits that it already knows about, so that's not the problem | 00:42 |
| dhx_m | what I was thinking... was you could rm -R the locally cloned repo before each update | 00:42 |
| nuclear_eclipse | ouch, no thanks :P | 00:43 |
| dhx_m | and then git clone --depth X to get the latest X revisions | 00:43 |
| dhx_m | or something along those lines... to conserve disk space | 00:43 |
| dhx_m | very ugly :) | 00:43 |
| nuclear_eclipse | I'd much rather keep a full clone and just do `git fetch; git checkout -f origin/branch` :P | 00:43 |
| nuclear_eclipse | s/checkout/log/ | 00:43 |
| dhx_m | what I was trying to get at is if a project as large as KDE wanted to use Mantis | 00:44 |
| dhx_m | they'd be a little stuffed :p | 00:44 |
| nuclear_eclipse | well, I think they'd be stuffed regardless of what they tried to use :D | 00:45 |
| dhx_m | well that is true :) | 00:49 |
| dhx_m | let's pick on gnome then | 00:49 |
| dhx_m | as they just officially moved to git a few days ago | 00:49 |
| dhx_m | and they setup their repos correctly (1 repo per piece of software/library) | 00:49 |
| dhx_m | so you'd effectively be importing 100 projects into Mantis | 00:50 |
| dhx_m | as I understand the situation, someone would need to manually "Import Latest" on each repo? | 00:50 |
| nuclear_eclipse | yes/no | 00:51 |
| nuclear_eclipse | you can set up "remote imports", which can be triggered automatically by some "remote" system, as validated by inbound IP address | 00:51 |
| dhx_m | that'd work nicely then :) | 00:52 |
| nuclear_eclipse | so for instance, on my server at leetcode.net, I have a cronjob that every five minutes triggers a series of curl calls for a list of repository ID's that triggers the remote import action | 00:52 |
| nuclear_eclipse | s/five/ten/ | 00:53 |
| dhx_m | yep | 00:53 |
| dhx_m | I don't suppose it is possible to fork a PHP script into multiple concurrent threads? | 00:55 |
| nuclear_eclipse | nope | 00:55 |
| dhx_m | ah and gitweb doesn't seem to have a log view that lists files changed | 00:56 |
| nuclear_eclipse | also, in the case of Gnome, where they are in 100% control of their repos, I've included a post-receive hook for Git that will automatically trigger a remote import only when necessary, which is naturally more efficient than polling every ten minutes :P | 00:56 |
| dhx_m | nice :) | 00:56 |
| dhx_m | I seem to be averaging 1 commit import/sec | 00:57 |
| dhx_m | maybe another idea for initial imports is to write a script that works off a local repo (could be anywhere) to create a formatted file which can be uploaded to Mantis | 00:58 |
| nuclear_eclipse | that sounds about right given latencies and bandwidth... | 00:58 |
| dhx_m | and Mantis will parse that file | 00:58 |
| dhx_m | to quickly import (without all the overhead of HTTP calls) | 00:58 |
| nuclear_eclipse | true | 00:58 |
| dhx_m | I guess you don't have to import often | 00:59 |
| dhx_m | so having to wait 3hrs for an initial import isn't too bad | 00:59 |
| dhx_m | in the scheme of things | 00:59 |
| nuclear_eclipse | yeah, that's generally what I assumed, plus in most cases, you'll generally have the gitweb instance on either the same server, or a more local server anyways, which greatly speeds up the import rate | 01:00 |
| dhx_m | yep | 01:01 |
| nuclear_eclipse | I tested importing the full mantisbt.git from my local gitweb, and it only took about 5 minutes for the 5000+ commits | 01:01 |
| dhx_m | that's quite good | 01:02 |
| dhx_m | I'm a little confused with how branching works | 01:04 |
| dhx_m | do I have to specify branches as being a "primary branch" in order for them to show in Mantis? | 01:04 |
| nuclear_eclipse | you do need to specify in your repo management page what branches/refs you want to follow | 01:06 |
| dhx_m | ok so you wouldn't follow branches that are likely going to be deleted in the future? | 01:06 |
| nuclear_eclipse | you can if you want, it just depends on how much you care about them being tracked in mantis :) | 01:07 |
| nuclear_eclipse | at most, it will just try to import a non-existent branch and silently eat the failure and continue to the next branch | 01:07 |
| dhx_m | what would be nice is if you delete a branch (after merging it into master) the branch commits can also be removed from Mantis | 01:08 |
| dhx_m | and the new commits in master (after the merge) are linked in the same way there were in the branch | 01:08 |
| nuclear_eclipse | well, if you do a real merge (not a rebase), there's no reason to delete the commits, because they're identical to what you see in the remaining branch... | 01:08 |
| dhx_m | so it just updates the branch they're in? | 01:09 |
| nuclear_eclipse | git doesn't actually track what branch commits are "in" | 01:09 |
| dhx_m | nope | 01:09 |
| nuclear_eclipse | similarly, Mantis only tracks the name of the last branch it started importing from | 01:10 |
| dhx_m | I know that a commit to one branch will have the same hash when it is merged into another branch (without conflicts) | 01:10 |
| dhx_m | I was just wondering how Mantis works out which branches contain the commit | 01:10 |
| nuclear_eclipse | even with conflicts, it will stay as the same hash; the conflict resolutions are stored in the merge commit | 01:10 |
| dhx_m | "last imported from"? | 01:10 |
| dhx_m | ah ok | 01:11 |
| dhx_m | let's say you have master and master 2, where master2 is a direct copy of master | 01:11 |
| dhx_m | does Mantis report the commit as being contained within both branches, or just one? | 01:11 |
| nuclear_eclipse | just the branch that it imported from first | 01:12 |
| dhx_m | hmm ok | 01:12 |
| dhx_m | I guess that makes some sense :) | 01:13 |
| nuclear_eclipse | eg, it traces the 'master' branch, the first commit is hash 123abc, imports it as part of branch 'master', and then continues to import 123abc's parent; then it traces master2, see 123abc and stops because 123abc has already been imported | 01:13 |
| dhx_m | except if a commit is pulled from a remote repo into two separate branches? | 01:13 |
| nuclear_eclipse | it basically allows you to retain history of where a commit was first seen | 01:15 |
| nuclear_eclipse | eg, branch master to 'feature' make a commit, and import the feature branch; mantis will make the feature commits as on the feature branch, and later when you merge that to master, it retains the history of that commit having been made on a separate branch | 01:15 |
| dhx_m | yep | 01:16 |
| nuclear_eclipse | IMO that keeps more data than rewriting it later | 01:16 |
| dhx_m | but what if you had two feature branches | 01:16 |
| dhx_m | that have both pulled in a prerequisite from a remote branch somewhere else | 01:16 |
| dhx_m | or allow me to restart... | 01:17 |
| dhx_m | you have 2 Mantis projects A and B | 01:17 |
| dhx_m | and a gitweb repo setup called X | 01:17 |
| nuclear_eclipse | well, if they're both identical, then a) the first branch in the list "wins", and b) you have issues :P | 01:17 |
| dhx_m | the repo has two feature branches I and J | 01:17 |
| dhx_m | feature branch I is being developed by project A, and J by project B | 01:18 |
| dhx_m | hence both projects want to track process on their branches separately | 01:18 |
| dhx_m | s/process/progress | 01:19 |
| nuclear_eclipse | ok, I'm following you so far... | 01:19 |
| dhx_m | if they both pull in a patch from a remote repo | 01:19 |
| dhx_m | both projects A and B should link the corresponding changeset in Mantis to their 2 separate tickets for feature branch I and J? | 01:20 |
| dhx_m | ie. | 01:20 |
| dhx_m | changeset linked to Mantis ticket #1 in project A | 01:20 |
| dhx_m | changeset also linked to Mantis ticket #2 in project B | 01:20 |
| dhx_m | yet when they click on that changeset to view details, it will just show up as belonging to branch I, because that merge was done first? | 01:21 |
| nuclear_eclipse | that's correct | 01:21 |
| nuclear_eclipse | I'm not really sure of a better way to do it without duplicating a *lot* of data | 01:21 |
| dhx_m | what about the ability to link a changeset to multiple branches? | 01:22 |
| nuclear_eclipse | if that sort of behavior is really a problem, a local tracking branch of the remote commit could be made, and followed by mantis with a higher order than the feature branches.... | 01:22 |
| dhx_m | yep, I see | 01:22 |
| nuclear_eclipse | dhx_m: that also implies that Mantis needs to start tracing entire branches to check for commits on multiple branches, rather than being able to stop as soon as an existinc commit is found | 01:23 |
| dhx_m | just with the current system, it'd be a little weird to view ticket #1, click on the attached changeset... and be redirected to the gitweb branch J | 01:23 |
| dhx_m | hmm true | 01:24 |
| nuclear_eclipse | true, but if it's really a shared commit from a remote branch, I think there should be tracking of that remote branch in Mantis as well, not just the feature branches | 01:24 |
| dhx_m | yep, that makes sense | 01:24 |
| dhx_m | except that you'd have to go through the pain of importing repositories at a rate of 1commit/sec :p | 01:25 |
| dhx_m | although you're right, I doubt it'd be a HUGE problem ;) | 01:25 |
| nuclear_eclipse | well, I mean more that the local repo should have tracking branch that has any remote commits, and then have I/J pull from that tracking branch | 01:25 |
| nuclear_eclipse | eg, your local repo would have 'master', 'shared' branch for all remote commits, and 'I' and 'J' as feature branches pulling from master and shared.... | 01:26 |
| nuclear_eclipse | s/all/all shared/ | 01:27 |
| dhx_m | ah ok | 01:27 |
| nuclear_eclipse | this is one of those topics where I explicitly decided upon a more generalized approach to the topic, because trying to implement the perfect way of handling every VCS's little nuances would make this project impossible | 01:28 |
| dhx_m | yep | 01:28 |
| nuclear_eclipse | and it also greatly simplifies the data model to have only a single branch for each commit | 01:29 |
| dhx_m | yep | 01:29 |
| dhx_m | although that information will likely be incorrect if you've commited something to branch X and then a minute later, you merge it to Y | 01:30 |
| nuclear_eclipse | it's similar to the compromise I make on only storing a single parent commit, which discards data from merge commits, but also greatly simplifies the data model, and still lets the individual integrations follow multiple parent commits during the import process, while discarding them from the resulting data model | 01:30 |
| dhx_m | then Mantis 4 minutes later (on a cron job) first imports Y, then X... the branch for the changset will be wrong (it didn't first appear in Y) | 01:31 |
| nuclear_eclipse | I would argue that any feature branch that gets merged to another branch 1 minute later is useless to track in Mantis :P | 01:32 |
| dhx_m | :) | 01:32 |
| dhx_m | so best practice for using the plugin would be: use import hooks to ensure that commit notification is done in order | 01:33 |
| nuclear_eclipse | now, cherry-picking is a different story, and in that case, it will end up with a different commit hash, therefore showing up as committed to both branches... | 01:33 |
| dhx_m | oh fun lol... I can see why the simple approach is better :) | 01:33 |
| nuclear_eclipse | yes, the use of cronned-imports is generally only a usecase for when you don't have total control over the canonical repository, eg mantisforge.org or sourceforge.net | 01:34 |
| nuclear_eclipse | cherry-picking is the one use-case I can think of where merging a commit one minute later is useful, eg, for porting a fix on master back to a stable release branch | 01:35 |
| dhx_m | true | 01:35 |
| dhx_m | but then again, larger bugfixes you want to backport may have their own branches | 01:36 |
| dhx_m | so instead of cherry picking, you'd probably want to merge instead | 01:36 |
| nuclear_eclipse | true, but if you're truly backporting them, you have to cherry-pick, otherwise you're merging the entire history of whatever branch the fix was originally created on... | 01:36 |
| dhx_m | oh yeah, true :) | 01:37 |
| nuclear_eclipse | ie, the bugfix branch still contains the entire history of what it was based on, so a straight merge is not what you want to do | 01:37 |
| dhx_m | yep | 01:37 |
| nuclear_eclipse | one thing to remember is that I spent a *lot* of time researching how different VCS tools track data (software development tools in general are a big interest of mine), and I spent a lot of time designing the framework to fit as many different styles and situations, making some compromises along the way to keep it simple; so I probably have a reason or an argument for just about anything you can think of to change from it's current state, except | 01:39 |
| nuclear_eclipse | now, that said, I'd still love to discuss these things, because there's always the possibility that I'm too stubborn/stupid/blind, and I need people like you to question my decisions to actually make sure I'm doing things the best way | 01:43 |
| dhx_m | well actually, I'm just trying to learn more about how it works :) | 01:43 |
| dhx_m | I'm not trying to suggest you didn't research it, don't know what you're doing, etc :) | 01:43 |
| nuclear_eclipse | right, it was just a point I wanted to bring up, to make sure you didn't think I was being a stuckup jerk who didn't want to hear anything negative ;) | 01:44 |
| dhx_m | and I appreciate the help and feedback a lot | 01:45 |
| dhx_m | no no, you wouldn't be talking here if that was the case :) | 01:45 |
| nuclear_eclipse | hehe | 01:45 |
| dhx_m | ah.. problem encountered... my import stopped at commit 3973 | 01:46 |
| nuclear_eclipse | btw, my presentation over the weekend bombed something horrible; it was the worst trainwreck of a presentation I've ever been a part of | 01:46 |
| dhx_m | now I'll be negative lol | 01:46 |
| nuclear_eclipse | dhx_m: it's probably an OOM issue I assume? | 01:46 |
| dhx_m | nuclear_eclipse: the script is still loading... maybe a script timeout | 01:47 |
| dhx_m | nuclear_eclipse: or maybe this server kills runaway threads | 01:47 |
| dhx_m | ah, sorry to hear about the presentation | 01:47 |
| dhx_m | was it fun otherwise? :) | 01:47 |
| nuclear_eclipse | well, the day was fun up till the presentation... =/ | 01:47 |
| nuclear_eclipse | first, my laptop wouldn't display on the porjector, and then my demonstration failed due to a SQL error, even though I had rehearsed the whole thing twice the night before... | 01:48 |
| dhx_m | oh ouch it sucks when that happens | 01:48 |
| dhx_m | I'm sure it could have been a lot worse | 01:49 |
| nuclear_eclipse | anyways, the git plugins just keep importing changesets like mad until they hit a duplicate commit, so on a large repository it'll eventually OOM before it completese | 01:49 |
| dhx_m | 99% of Windows users take 5 minutes to get Powerpoint to show up :) | 01:49 |
| dhx_m | ah ok | 01:49 |
| nuclear_eclipse | as opposed to the SVN plugins, which only import in sets of 200 | 01:49 |
| nuclear_eclipse | I set up the framework that would allow me to replicate the SVN behaviors in Git as well, but I just haven't yet gotten around to implementing it | 01:50 |
| dhx_m | I'm surprised that it starts importing from the latest changeset to the oldest | 01:50 |
| nuclear_eclipse | dhx_m: that's because it has to | 01:50 |
| dhx_m | oh yeah true... tracing the parent, etc | 01:50 |
| nuclear_eclipse | Git/Hg/Bzr use a DAG, so you can't do anything but trace backwards | 01:51 |
| dhx_m | is it possible to just go to the last page of the shortlog in gitweb and look at each changeset 1 by 1 in reverse? | 01:51 |
| dhx_m | then you'd be importing by page (fixing the OOM issue) | 01:52 |
| nuclear_eclipse | dhx_m: but you lose a lot of info with the shortlog | 01:52 |
| nuclear_eclipse | ie, no list of modified files, no committer info | 01:53 |
| dhx_m | well you'd only use it as an index | 01:53 |
| dhx_m | then you'd load each commit in gitweb to read the details | 01:53 |
| dhx_m | but you'd know the reverse order of commits for each branch | 01:53 |
| nuclear_eclipse | the OOM issue is just a matter of adding a static counter to the import function, and dump info after the counter hits an upper limit | 01:53 |
| dhx_m | and you can ignore a commit if you already have a sha1 hash for it in another branch | 01:53 |
| nuclear_eclipse | I guess I'm not really convinced that it would do anything other than require an extra page load... | 01:54 |
| dhx_m | well if you do get an import error... you wouldn't have to start a full import all over again to fill in the blanks | 01:55 |
| nuclear_eclipse | well, you don't here either... | 01:55 |
| nuclear_eclipse | it looks for the oldest commit on the branch and tries importing starting from its parent, as well as starting an import from the branch itself | 01:56 |
| dhx_m | ah :) | 01:56 |
| dhx_m | nice | 01:56 |
| nuclear_eclipse | the only reason in your case that you would need to start a full import again is because the OOM issiue would have prevented the commit message-parsing from happening... | 01:57 |
| nuclear_eclipse | oh, and it also would have prevented the author/committer->user_id mapping from happening too | 01:57 |
| dhx_m | not an issue in my case | 01:57 |
| dhx_m | yep | 01:57 |
| * nuclear_eclipse gets an itch to fix the OOM issue | 01:57 | |
| dhx_m | I guess #24 would fix the issue of redoing message parsing at a later time | 01:59 |
| dhx_m | not really a priority though | 02:00 |
| dhx_m | most people can just run their own SQL query manually to make the fix for now | 02:00 |
| nuclear_eclipse | my biggest problem with #24 is that I'm not sure of a best solution for how to handle the update process without introducing multiple edge case | 02:01 |
| dhx_m | the problem to me appears to be that the userid column in the changeset table is really just a cache | 02:03 |
| dhx_m | the actual relationship between userid's and changesets is defined elsewhere | 02:04 |
| dhx_m | someone could change their real name at any time, for instance | 02:04 |
| nuclear_eclipse | well, yes, but who's realistically going to be changing something like that? | 02:04 |
| dhx_m | someone might change their name (marriage) :p | 02:05 |
| dhx_m | rare case | 02:05 |
| nuclear_eclipse | true, but that doesn't change the fact that all the previous commits they made under their old realname are no longer theirs... | 02:05 |
| nuclear_eclipse | and the source control tool will be forever storing it under that old name anyways... | 02:06 |
| dhx_m | yep, which is why I am interested in having the ability to let users control how the Mantis -> VCS user mapping is done | 02:06 |
| dhx_m | yep | 02:06 |
| nuclear_eclipse | Now, I'll agree that it could be useful to have multiple mappings of name to user id, but I don't think we should be re-parsing all of the existing changesets when a user's info or mappings have changed | 02:06 |
| dhx_m | it'd be useful if someone signs up to Mantis after they've been committing to the repository | 02:07 |
| dhx_m | let's say a project moves from Bugzilla to Mantis | 02:07 |
| dhx_m | they already have a VCS history and would like to link old changesets to the new Mantis userid's | 02:07 |
| nuclear_eclipse | well, a repository can always be re-imported.... | 02:08 |
| dhx_m | but then you lose changset => Mantis ticket mappings | 02:08 |
| nuclear_eclipse | and in the case of a migration, I would assume that the repo import would take place *after* all the existing accounts had been migrated to Mantis | 02:08 |
| dhx_m | hmm yeah, if you migrate accounts automatically for people that would be OK | 02:09 |
| dhx_m | rather than have them sign up | 02:09 |
| dhx_m | hmmm this is ugly | 03:00 |
| dhx_m | I imported mantisbt/dhx.git/master OK... then went to import my 'fyp' branch | 03:01 |
| dhx_m | which imported OK up to the point where I last merged master into my 'fyp' branch | 03:02 |
| nuclear_eclipse | right, which makes sense | 03:02 |
| dhx_m | except it won't import any of the commits that went into those merges? | 03:02 |
| nuclear_eclipse | it should follow the parent commit that's part of your feature branch, while ignoring any commits that came from the master branch | 03:03 |
| nuclear_eclipse | if that's not working, then yes, that's a probllem, and please file a bug report :P | 03:03 |
| dhx_m | Oldest 'master' branch parent: '' | 03:03 |
| dhx_m | Retrieving master ... processing e50944ce028886db539855a0d7d0acbf5dc3a94b ... already exists. | 03:03 |
| dhx_m | Oldest 'fyp' branch parent: 'e50944ce028886db539855a0d7d0acbf5dc3a94b' | 03:03 |
| dhx_m | Retrieving fyp ... processing 301c8ee78f47fd8e6b47432f01847fdf2328dc89 ... already exists. | 03:03 |
| dhx_m | Retrieving e50944ce028886db539855a0d7d0acbf5dc3a94b ... processing e50944ce028886db539855a0d7d0acbf5dc3a94b ... already exists. | 03:03 |
| nuclear_eclipse | so it that case, it seems that it's already imported from both sides of the merge... | 03:04 |
| dhx_m | yep | 03:05 |
| nuclear_eclipse | can you verify that by looking at the changesets listed in mantis? | 03:05 |
| dhx_m | if you check: http://git.mantisforge.org/w/mantisbt/dhx.git?a=shortlog;h=refs/heads/fyp | 03:06 |
| dhx_m | Mantis has imported changesets from 'fyp' down to 'master' (not including 'master') but hasn't imported any of the patches there were merged | 03:06 |
| dhx_m | ie the stuff from '10330' on down | 03:06 |
| dhx_m | oh I see | 03:08 |
| dhx_m | I'd need to add the branch that was merged | 03:08 |
| dhx_m | so that Mantis can follow the 2nd parent in the merge | 03:08 |
| nuclear_eclipse | hmm, you shouldn't need to... | 03:09 |
| dhx_m | well the importing of my 'fyp' branch stopped at http://git.mantisforge.org/w/mantisbt/dhx.git?a=commit;h=3e1f38ecf6297c6e5c28939d5283eee279db393d | 03:09 |
| nuclear_eclipse | eg, it should get to the merge commit, find two parent id's, and then queue both those parents for importing | 03:09 |
| dhx_m | and the first parent e509 is already in the master (that was where the fyp branch was started from) | 03:09 |
| nuclear_eclipse | hmm, I wonder if I botched implementation of multiple parent ids for gitweb | 03:09 |
| dhx_m | yeah I guess it might not have followed the 2nd parent id | 03:10 |
| nuclear_eclipse | I know for sure it works (or worked) for GitHub, but that uses GitHub's JSON API for importing data | 03:10 |
| nuclear_eclipse | go ahead and log a bug, and I'll look at it tomorrow if I get the chance | 03:10 |
| nuclear_eclipse | I'm unfortunately too busy atm working on classwork... =\ | 03:11 |
| dhx_m | if( preg_match( '#<tr><td>parent</td><td class="sha1"><a [^<>]*>([a-f0-9]*)</a></td>#', $t_gitweb_data, $t_matches ) ) { | 03:11 |
| dhx_m | $t_commit['parent'] = $t_matches[1]; | 03:11 |
| dhx_m | } | 03:11 |
| dhx_m | so it seems it only remembers one parent in Gitweb | 03:11 |
| nuclear_eclipse | that should probably be a preg_match_all() :P | 03:11 |
| dhx_m | no problem, I'll patch it up :) | 03:11 |
| dhx_m | then $t_commit['parent'] is changed to be an array of parentids? | 03:12 |
| nuclear_eclipse | I believe so | 03:12 |
| dhx_m | ok | 03:12 |
| dhx_m | $t_parents = array(); | 03:12 |
| dhx_m | if ( isset( $t_commit['parent'] ) ) { | 03:12 |
| dhx_m | $t_parents[] = $t_commit['parent']; | 03:12 |
| dhx_m | } | 03:12 |
| nuclear_eclipse | preg_match_all() makes me think hard everytime I try to use it... | 03:13 |
| nuclear_eclipse | well, think hard plus read and reread the online docs | 03:13 |
| dhx_m | yep :) | 03:14 |
| dhx_m | oh this is much harder now | 03:25 |
| dhx_m | the database only stores a single parent ID per changeset | 03:25 |
| dhx_m | is it OK to assume we're only interested in the 2nd (last) parent ID from the Gitweb output? | 03:26 |
| dhx_m | actually that isn't ok now I think about it | 03:26 |
| nuclear_eclipse | you could check to see if either of the commits already existi, and prefer non-existent commits | 03:27 |
| nuclear_eclipse | that should cover the majority of merges in feature branches | 03:28 |
| dhx_m | it'll be a problem when you have a commit like: | 03:28 |
| dhx_m | http://git.mantisforge.org/w/mantisbt/dhx.git?a=commit;h=74ad243099c1b5e802e254b56bf9425d37028c53 | 03:28 |
| dhx_m | where both parents are unknown | 03:28 |
| nuclear_eclipse | well, my point being that you could pick an arbitrary parent, with preference on parents that haven't yet been imported... | 03:29 |
| nuclear_eclipse | or you could just do what the github importer does, and just always choose the first parent | 03:30 |
| dhx_m | the problem though is that for the commit I just linked to, both parents haven't been imported yet | 03:30 |
| dhx_m | and you'd want to import both | 03:30 |
| dhx_m | the first parent lets you continue searching through the branch for previous commits/merges | 03:31 |
| dhx_m | the second parent will import the actual changesets from the merge | 03:31 |
| nuclear_eclipse | well, right, you'd naturally queue all the parent commits for import, but just pick an arbitrary parent as the one to store in the current changeset object | 03:32 |
| dhx_m | ah ok | 03:32 |
| dhx_m | although I think github just ignores the parent thing entirely | 03:32 |
| nuclear_eclipse | well, either way, by returning an array of parent commits, the importer process will eventually trace both paths | 03:33 |
| dhx_m | that's correct | 03:33 |
| nuclear_eclipse | if github doesn't actually set the parent_id on the changeset object, that's yet another bug :P | 03:34 |
| dhx_m | is the 'parent' field in the database largely irrelevant? | 03:34 |
| nuclear_eclipse | dhx_m: not entirely | 03:34 |
| nuclear_eclipse | a) it shows up when viewing an individual commit in Mantis, and b) it's used to continue importing a tree of commits in case of error/OOM prevention | 03:35 |
| dhx_m | so we'd really need to have 2 parent fields to cater for the instance of merging? | 03:35 |
| nuclear_eclipse | well, that's the real problem | 03:35 |
| dhx_m | I'm not sure if there would ever be 3 or more parents | 03:36 |
| nuclear_eclipse | technically, merges in Git/Hg can potentially have any number of merge parents | 03:36 |
| dhx_m | ah ugly | 03:36 |
| nuclear_eclipse | eg, that's what Git terms an 'Octopus' merge, and yes, it's ugly, but possible | 03:36 |
| dhx_m | yep | 03:36 |
| nuclear_eclipse | and that's the main reason I just chose an arbitrary schema of storing a single parent, because otherwise you'd need either an entire extra table to map changeset parents, or you'd need a fulltext field, which is no longer efficiently searchable | 03:38 |
| dhx_m | maybe it'd be better to just lookup the parent ids from github/gitweb | 03:38 |
| nuclear_eclipse | well, I'd prefer to not require constantly hitting the remote data source | 03:38 |
| dhx_m | or do the lookups when the parent is blank? | 03:38 |
| nuclear_eclipse | esp in the case of github or remote gitwebs, where the latency would be a huge pitfall | 03:38 |
| dhx_m | yep | 03:39 |
| nuclear_eclipse | I'd rather just discard extra data :P | 03:39 |
| dhx_m | although we can't discard the extra data in this case? | 03:39 |
| dhx_m | because if there is an import error that lands on a commit with more than one parent, it'll be stuck forever | 03:40 |
| nuclear_eclipse | there is one potential option though that would fit the current schema, but require more work on the app: storing multiple parent ids separated by | or something | 03:40 |
| dhx_m | that sounds like a performance hit compared to creating a new table | 03:42 |
| nuclear_eclipse | using a separator would allow 3-4 parent ids to be tracked in Git, but would require using the slow/complex LIKE clauses in queries | 03:43 |
| nuclear_eclipse | although using LIKE is faster than using a join :P | 03:43 |
| dhx_m | would you use a join though... or perform 2 separate queries (even slower?) | 03:43 |
| dhx_m | actually yeah multiple queries would be worse | 03:44 |
| nuclear_eclipse | well, my biggest concern with using a second table is that loading any changeset objects now requires a JOIN | 03:44 |
| dhx_m | you don't really need to get the parent on each query though? | 03:44 |
| dhx_m | ah, in OO PHP you would | 03:45 |
| dhx_m | I see | 03:45 |
| nuclear_eclipse | well, no, but then you add complexity to the codebase to start using conditional queries, and then what happens when you forget to explicitly load parent ids before referencing them... | 03:45 |
| nuclear_eclipse | the incidental complexities are what I try to avoid | 03:46 |
| dhx_m | yep | 03:46 |
| dhx_m | unless you can load the parent information upon first request? | 03:46 |
| nuclear_eclipse | there are only three JOINs in the entire object API, two of which are only used when gathering stats, and so are only used rarely... | 03:47 |
| nuclear_eclipse | dhx_m: I would *really* rather not start implementing lazy loading... :P | 03:48 |
| dhx_m | yeah, performance problems either way argh | 03:48 |
| nuclear_eclipse | lazy loading also generally implies a lot more database queries | 03:48 |
| dhx_m | yep | 03:48 |
| nuclear_eclipse | dhx_m: compromises suck, don't they? | 03:50 |
| dhx_m | sure do | 03:50 |
| dhx_m | I see the dilemma here | 03:50 |
| dhx_m | I feel like I'm the first other person in the world to use this plugin :) | 03:52 |
| nuclear_eclipse | hehe | 03:52 |
| dhx_m | I'm surprised more people aren't taking interest in it, given that it is a very cool feature | 03:52 |
| dhx_m | although if they're still running Mantis 1.0.1.... :p | 03:52 |
| nuclear_eclipse | yeah, that seems to be our biggest problem: getting 1.2.x out the door :P | 03:53 |
| nuclear_eclipse | but then again, we can barely get users to upgrade for major security fixes... :/ | 03:53 |
| dhx_m | users... useless :p | 03:57 |
| dhx_m | and to think Mantis users are most likely programmers heh | 03:57 |
| nuclear_eclipse | yeah.... | 03:57 |
| dhx_m | it is funny looking at some public trackers out there | 03:58 |
| dhx_m | http://straight-street.com/tracker/view.php?id=110 | 03:58 |
| dhx_m | they say "Child of xxx" in the summary of bugs | 03:59 |
| dhx_m | where xxx is the parent bug | 03:59 |
| nuclear_eclipse | lol | 04:00 |
| nuclear_eclipse | brought to you by the Department of Redundancy Department :) | 04:00 |
| dhx_m | haha | 04:00 |
| nuclear_eclipse | re #31: you can simply axe the appropriate regexes :P | 04:13 |
| nuclear_eclipse | but really, why would you have the ability to import repo data into mantis without linking changesets to issues? | 04:14 |
| dhx_m | initial commits | 04:14 |
| nuclear_eclipse | I'm curious what the purpose would be... | 04:14 |
| dhx_m | I wanted to import the mantis repo | 04:14 |
| dhx_m | and some of the very old commits were being linked to my existing bugs | 04:15 |
| nuclear_eclipse | ah | 04:15 |
| dhx_m | anyway... I think the linking settings should really be per-repo | 04:15 |
| dhx_m | a checkbox would also be good to have, as it is more user friendly | 04:15 |
| dhx_m | otherwise the current Mantis 1.0.0 users won't have any hope :p | 04:16 |
| nuclear_eclipse | just as a curiousity, why are you importing the mantis repo into your own tracker? | 04:16 |
| dhx_m | well I'm actually importing my own branch | 04:16 |
| dhx_m | so I can track my own development of the branch | 04:17 |
| nuclear_eclipse | oh, I see | 04:17 |
| dhx_m | and link fixes I make (or are made upstream) to bug reports on my own tracker | 04:17 |
| * nuclear_eclipse slaps dhx_m | 04:17 | |
| nuclear_eclipse | stop breaking my use cases! | 04:17 |
| dhx_m | haha | 04:17 |
| mantisbot | New bug: Bug 10373 - karthisudar - open - new | 04:18 |
| mantisbot | New bug: test - http://www.mantisbt.org/bugs/view.php?id=10373 | 04:18 |
| mantisbot | New bug: Bug 10374 - karthisudar - open - new | 04:18 |
| mantisbot | New bug: test - http://www.mantisbt.org/bugs/view.php?id=10374 | 04:18 |
| nuclear_eclipse | lord | 04:18 |
| dhx_m | again!!! | 04:18 |
| nuclear_eclipse | not again... | 04:18 |
| dhx_m | lol | 04:18 |
| * nuclear_eclipse wishes he had access to manage users... | 04:19 | |
| dhx_m | actually to really break your use cases, I'd go as far as saying 90% of the configuration settings in the Source Configuration page should instead be per-repo | 04:20 |
| * nuclear_eclipse tells ChanServ to ban dhx_m | 04:20 | |
| dhx_m | haha | 04:20 |
| dhx_m | although I think a new config backend would solve a lot of these problems | 04:21 |
| nuclear_eclipse | the biggest problem with using per-repo settings is losing the ability to a) piggyback off the existing config_api, and b) keep things simple by only having one place to make these changes | 04:21 |
| nuclear_eclipse | eg, if I want to change the regex for commit messages I now have to change the message for every repository I have in Mantis... | 04:22 |
| dhx_m | well IMO it'd be best to have a configuration system which has a concept of "context" | 04:23 |
| nuclear_eclipse | excuse me while I go laugh my ass off in the next room :P | 04:23 |
| dhx_m | :D | 04:23 |
| dhx_m | what I mean is... | 04:23 |
| dhx_m | you can set a high level configuration value | 04:23 |
| dhx_m | and then either inherit that for more fine grained cases | 04:24 |
| dhx_m | or you can override it as required with a more specific value | 04:24 |
| dhx_m | maybe this is a bit radical heh | 04:24 |
| nuclear_eclipse | right, you just want a more generalized case of the existing config_api's ability to set values on a project and/or user basis as well as globally | 04:24 |
| dhx_m | I guess so, yes | 04:24 |
| nuclear_eclipse | the problem is how to define a generalized context | 04:25 |
| nuclear_eclipse | esp once you bring in the concepts of the plugin system, where any plugin can now introduce it's own set of configuration options | 04:25 |
| dhx_m | I'm not sure who I was talking to in this channel about tagging, but maybe those sort of concepts can come into play? | 04:26 |
| nuclear_eclipse | that was me again :P | 04:26 |
| dhx_m | :) | 04:26 |
| dhx_m | what about having a system where you can tag configuration settings? | 04:26 |
| dhx_m | tag types might be "user", "group", "project", "repository" | 04:27 |
| nuclear_eclipse | urg | 04:27 |
| dhx_m | hah | 04:27 |
| nuclear_eclipse | and then you instantly have the ability for tags/contexts to overlap in meaning with plugins | 04:27 |
| dhx_m | the idea is that you would have unlimited ability to configure settings | 04:28 |
| dhx_m | not necessarily, you'd have an API which "registers" the contexts | 04:28 |
| nuclear_eclipse | you're making things more and more complex with every sentence, you know... | 04:28 |
| dhx_m | well yes, it is complex ;( | 04:29 |
| dhx_m | but it'd be very nice to be able to make settings like "the user group X can view source code repository A" | 04:29 |
| nuclear_eclipse | as one of my professors likes to harp on, the "grand unified data structure" is just a way to spend 100x the effort on 0.1x the implementation... :P | 04:30 |
| dhx_m | :) | 04:30 |
| dhx_m | I wonder if what I'm talking about has been done before... probably not ;) | 04:30 |
| nuclear_eclipse | I think the better approach would be to simply create more tables for contextual data like that | 04:31 |
| dhx_m | so to check if someone has view access, you'd have something like: | 04:31 |
| nuclear_eclipse | the more generalized your data storage, the more complex your implementation | 04:31 |
| dhx_m | in our case you would be able to generate the data structure of tables automatically | 04:32 |
| dhx_m | ie. you have one config table with a column for each context | 04:32 |
| dhx_m | although that gets SOOOOOOO complicated :) | 04:33 |
| nuclear_eclipse | dynamic schema like that is a nightmare | 04:33 |
| nuclear_eclipse | you must remember that we have rigid schema restrictions for the purpose of backend independence and reliable/predictable upgrade paths | 04:34 |
| nuclear_eclipse | adding a column for each new context is more-or-less out of the question | 04:34 |
| dhx_m | only plugins would add columns though | 04:35 |
| dhx_m | and if you uninstall a plugin, the column goes away | 04:35 |
| nuclear_eclipse | well, we basically have a rule in place that plugins never touch core tables :P | 04:35 |
| nuclear_eclipse | and that schema changes only happen as a result of an explicit upgrade process | 04:36 |
| dhx_m | through core API of course :) | 04:36 |
| dhx_m | well currently there is already something like this in place | 04:36 |
| nuclear_eclipse | this is where it's a good thing you can't stab people over the internet... | 04:36 |
| dhx_m | the database configuration has config options named like: | 04:36 |
| dhx_m | plugin_SourceGithub_schema | 04:36 |
| dhx_m | haha | 04:36 |
| nuclear_eclipse | dhx_m: yes, but that doesn't actually change the schema definitions of Mantis | 04:36 |
| nuclear_eclipse | that allows you to have predictable schema changes for plugin tables, and shouldn't change anything involving core schemas | 04:37 |
| nuclear_eclipse | you must also remember that there are a good deal of users who have mantis connect to the database as a user that doesn't have alter permissions for database tables | 04:38 |
| nuclear_eclipse | so like I said before, dynamic schema is out of the question :P | 04:38 |
| dhx_m | plugins are already allowed to plant their own data in the core config table and I don't see the addition of a new column to the table being much different (as long as the core API does it) | 04:39 |
| dhx_m | yep | 04:39 |
| nuclear_eclipse | well, adding rows of data is a completely different ballgame compared to adding columns.... | 04:39 |
| dhx_m | yep, but if there is a unified way to add columns, that would be mostly solved | 04:40 |
| nuclear_eclipse | and letting plugins piggyback on the existing config_api is done so that plugins don't all have to define their own configuration tables and apis | 04:41 |
| dhx_m | the whole point being that you don't need multiple queries across a "core" and "plugin" table anymore | 04:41 |
| dhx_m | actually... | 04:41 |
| dhx_m | hmm | 04:42 |
| dhx_m | joining a plugin config table wouldn't work | 04:42 |
| nuclear_eclipse | I'm open to changes to the core schema, but only if that schema is a static schema - adding and removing columns on the fly, regardless if it's done through a core API, is borderline insane from a DBA point of view, IMO | 04:42 |
| dhx_m | well the only time you add/remove columns is part of an upgrade | 04:43 |
| dhx_m | in a similar way to if you upgraded Mantis core | 04:43 |
| dhx_m | the number of times it'd happen are very limited | 04:44 |
| dhx_m | to when you install or uninstall a plugin | 04:44 |
| nuclear_eclipse | well, I'm still of the mind that plugins should *never* modify core schema, even if it's done as part of a core API - way too much can go wrong, and all of a sudden you lose the reasonable ability to drop a plugin and reason about the stability of Mantis afterwards... | 04:44 |
| dhx_m | if you go to adm_config_report.php | 04:45 |
| dhx_m | you'll see there are already two columns "Username" and "Project Name" | 04:45 |
| nuclear_eclipse | but anywho, we can continue this discussion tomorrow; it's 12:45am, and I have class in 7 hours... :P | 04:45 |
| dhx_m | where those are "contexts" in my discussion here | 04:45 |
| dhx_m | :) | 04:45 |
| nuclear_eclipse | good night | 04:46 |
| dhx_m | (this is mainly theoretical will-happen-in-Mantis-v8) :p | 04:46 |
| dhx_m | ok cya | 04:46 |
| dhx_m | nuclear_eclipse: ah, what I was doing ^^ was talking about left joining various configuration tables into one (bad) when it'd be better to use tables than merge them | 05:11 |
| [KK]Kirill | morning | 05:50 |
| dhx_m | hi | 05:51 |
| [KK]Kirill | what's new? | 05:53 |
| [KK]Kirill | or nothing? | 05:53 |
| dhx_m | not much, was busy breaking nuclear_eclipse's use cases before :p | 05:54 |
| dhx_m | and now he wants to stab me though the internet :p | 05:54 |
| [KK]Kirill | :-) | 05:55 |
| dhx_m | then I got thinking about configuration on a per-anything basis | 05:56 |
| dhx_m | ie. I want to receive email notifications when a bug in project A is linked to a changeset from repository X, but not when any other changesets are linked | 05:57 |
| dhx_m | I guess I was going off on a theoretical tangent to see if that sort of thing is possible | 05:57 |
| dhx_m | (in a generic, easy, fast, etc way) | 05:58 |
| [KK]Kirill | sorry, for why? | 05:58 |
| [KK]Kirill | some example? | 05:58 |
| dhx_m | I just pulled that example from nowhere as an example of what could be possible under this imaginary config subsystem I was thinking of | 05:59 |
| dhx_m | a better example would be: | 06:00 |
| dhx_m | "I want to receive email notifications when a bug in project A is opened but I want to receive SMS notifications as well when the severity is above HIGH" | 06:00 |
| dhx_m | ... it gets too complex I guess | 06:01 |
| [KK]Kirill | yes.. I want this too | 06:01 |
| dhx_m | so it is probably easier to just let people write their own custom functions | 06:01 |
| [KK]Kirill | I think too | 06:02 |
| dhx_m | the problem is how you store and access that sort of configuration | 06:02 |
| dhx_m | it isn't easy | 06:02 |
| dhx_m | maybe you want to receive those SMS notifications when the priority is above HIGH | 06:03 |
| dhx_m | or when the person submitting it is a certain user | 06:03 |
| mantisbot | New bug: Bug 10375 - karthisudar - open - new | 06:03 |
| mantisbot | New bug: Testing the defect - http://www.mantisbt.org/bugs/view.php?id=10375 | 06:03 |
| mantisbot | New bug: Bug 10376 - karthisudar - open - new | 06:03 |
| mantisbot | New bug: wdasdsad - http://www.mantisbt.org/bugs/view.php?id=10376 | 06:03 |
| dhx_m | at this point, I'd like to wish all the worst spam upon karthisudar's inbox | 06:05 |
| [KK]Kirill | dit you have his mail? | 06:05 |
| dhx_m | nah lol | 06:06 |
| [KK]Kirill | I redirect my spam :) | 06:06 |
| [KK]Kirill | paul not wake up? | 06:08 |
| dhx_m | not that I've noticed :) | 06:11 |
| [KK]Kirill | :) did you have twitter? | 06:12 |
| dhx_m | nope | 06:12 |
| mantisbot | New bug: Bug 10377 - karthisudar - open - new | 06:13 |
| mantisbot | New bug: testing for cor - http://www.mantisbt.org/bugs/view.php?id=10377 | 06:13 |
| [KK]Kirill | *angry* | 06:14 |
| dhx_m | haha | 06:15 |
| dhx_m | I can understand the need to make a few test tickets | 06:15 |
| dhx_m | but making 20+ test tickets over the span of multiple days? | 06:15 |
| dhx_m | you would have thought after the first 5 or so, you'd have a good idea of how Mantis works | 06:15 |
| [KK]Kirill | I don't understand, why he can't test mantis on local system | 06:16 |
| dhx_m | well I'm just assuming he thinks /bugs is a testing ground for people to play around in | 06:17 |
| dhx_m | instead of using demo.mantisbt.org | 06:17 |
| [KK]Kirill | old version | 06:19 |
| dhx_m | true | 06:21 |
| mantisbot | New bug: Bug 10378 - karthisudar - open - new | 06:23 |
| mantisbot | New bug: testing defect - http://www.mantisbt.org/bugs/view.php?id=10378 | 06:23 |
| mantisbot | New bug: Bug 10379 - berton - open - new | 07:24 |
| mantisbot | New bug: Characters when $g_show_extended_project_browser = ON - http://www.mantisbt.org/bugs/view.php?id=10379 | 07:24 |
| mantisbot | New bug: Bug 10380 - quazardous - open - new | 08:39 |
| mantisbot | New bug: Using $g_csv_columns with custom field cause fatal error - http://www.mantisbt.org/bugs/view.php?id=10380 | 08:39 |
| mantisbot | New bug: Bug 10381 - karthisudar - open - new | 08:54 |
| mantisbot | New bug: testing for cor - http://www.mantisbt.org/bugs/view.php?id=10381 | 08:54 |
| mantisbot | New bug: Bug 10382 - karthisudar - open - new | 08:59 |
| mantisbot | New bug: testing for correlation - http://www.mantisbt.org/bugs/view.php?id=10382 | 08:59 |
| [KK]Kirill | siebrand: ban karthisudar | 09:11 |
| dhx_m | that doesn't quite go far enough | 09:14 |
| mantisbot | New bug: Bug 10383 - karthisudar - open - new | 09:14 |
| mantisbot | New bug: test - http://www.mantisbt.org/bugs/view.php?id=10383 | 09:14 |
| dhx_m | someone needs to cast the "curse of much spam" on him | 09:15 |
| * giallu lose his magic wand | 09:15 | |
| dhx_m | [KK]Kirill: wouldn't we need to write a new "ban IP" patch to do that? :p | 09:18 |
| [KK]Kirill | I think would | 09:19 |
| siebrand | [KK]Kirill: not possible, unless it would be done by a firewall/application server rule or a live patch. | 09:31 |
| siebrand | I have access to neither. | 09:31 |
| siebrand | I also do not have the access level to close the account, i think. | 09:32 |
| siebrand | nope, I do not. | 09:32 |
| siebrand | giallu appears to be on it. | 09:32 |
| dhx_m | if I were karthisudar, I'd be running right about.... NOW :) | 09:33 |
| siebrand | dhx_m: he's got a Yahoo account. He probably couldn't care less. | 09:35 |
| dhx_m | yeah heh | 09:37 |
| harpreet_singh | hi | 09:39 |
| dhx_m | hi | 09:39 |
| harpreet_singh | how are you | 09:41 |
| harpreet_singh | I am trying to Install Mantis on RHEL 4update 5 | 09:42 |
| harpreet_singh | but not sure how to setup the apache/php/mysql and mantis. | 09:42 |
| harpreet_singh | if possible can u send me the detailed document at harpreetrajan@gmail.com | 09:42 |
| harpreet_singh | I am new to this... | 09:42 |
| harpreet_singh | we have an existing setup which is running on Redhat 9 with Mantis 0.17. | 09:43 |
| harpreet_singh | but dont have any documentation for the setup. | 09:43 |
| harpreet_singh | please advise. | 09:44 |
| dhx_m | FYI http://www.catb.org/~esr/faqs/smart-questions.html#easyreply | 09:46 |
| dhx_m | There is a whole stack of Mantis documentation online at mantisbt.org | 09:47 |
| dhx_m | which covers installation | 09:47 |
| dhx_m | I think you may have problems with RHEL4 being from the stone age, hence Mantis might not work with the old version of PHP? | 09:48 |
| harpreet_singh | may I know the sutable configuration to Install mantis. | 09:50 |
| harpreet_singh | in mantis they say from this ver... onwards.. etc | 09:50 |
| dhx_m | http://www.mantisbt.org/requirements.php | 09:50 |
| dhx_m | you should be able to use Mantis 1.1.x | 09:51 |
| harpreet_singh | ok.. | 09:52 |
| harpreet_singh | can i assume only the listed version will work with mantis | 09:52 |
| dhx_m | no, it defines the minimum requirements | 09:52 |
| dhx_m | you might even be able to use lower versions of those products if you turn off some Mantis features, make some code fixes yourself, etc | 09:53 |
| harpreet_singh | to be brank from the last one week I am not able to make it. | 09:54 |
| harpreet_singh | to be frank.. from last one week I am not able to make it... | 09:54 |
| harpreet_singh | some time apache and php issue or some time mysql issue. | 09:55 |
| harpreet_singh | if u dont mind can i have your working configuration | 09:55 |
| dhx_m | the default configuration works for me just fine :) | 09:56 |
| harpreet_singh | like operating system, apache/php/mysql and Mantis | 09:56 |
| harpreet_singh | :) | 09:56 |
| harpreet_singh | so tonight again I can try to setup again. | 09:56 |
| dhx_m | RHEL4 + PHP5.1 + Apache2.2 + MySQL5 | 09:56 |
| dhx_m | Gentoo + latest version of everything else | 09:57 |
| dhx_m | if you come across an error, you should copy that down | 09:57 |
| dhx_m | and paste it here | 09:57 |
| dhx_m | I can't help you without some idea of what the real problem is (an error message or something technical would help) | 09:57 |
| harpreet_singh | now I am at home.. I will be in office during my night shift. | 09:58 |
| harpreet_singh | why mantis dont come in a single tar file for installation. | 09:59 |
| harpreet_singh | so during installation it should prompt for the installation location. Like Oracle database. | 09:59 |
| harpreet_singh | :) :) | 10:00 |
| dhx_m | this is a platform independent piece of software written in PHP | 10:00 |
| dhx_m | so a graphical installer makes no sense :) | 10:00 |
| dhx_m | just untar mantisbt-1.1.7.tar.gz to your web directory | 10:01 |
| dhx_m | you should really be reading the manual @ http://www.mantisbt.org/manual/manual.installation.php | 10:02 |
| harpreet_singh | do i have to install apache and php with some module | 10:02 |
| dhx_m | it explains everything | 10:02 |
| dhx_m | probably not | 10:02 |
| dhx_m | it depends on your operating system | 10:03 |
| dhx_m | as long as you have PHP scripts executing under Apache, you're fine | 10:03 |
| dhx_m | you don't even have to use Apache if you don't want to | 10:03 |
| harpreet_singh | ok. | 10:04 |
| harpreet_singh | Let me do it tonight.. If i have any issue. I will let you know. | 10:06 |
| harpreet_singh | many thanks for the advice.. | 10:06 |
| harpreet_singh | if u have any setup document you can pass me at harpreetrajan@gmail.com | 10:06 |
| dhx_m | I'm not sure you're reading what I write | 10:09 |
| dhx_m | I already said that all the documentation you'll ever need is at the URL I pointed out (the official website for Mantis) | 10:09 |
| dhx_m | :) | 10:09 |
| AndyH | Has anyone been able to use the configuration option $g_logo_image correctly? When ever enter it into Mantis, it says "Configuration option "logo_image" not found." | 10:11 |
| dhx_m | works for me in 1.2 | 10:12 |
| AndyH | im using 1.1.6 | 10:20 |
| AndyH | i'll make sure I get the latest | 10:20 |
| [KK]Kirill | latest 1.1.7 | 10:21 |
| AndyH | The site says the latest stable is 1.1.7, so I guess I'll have to wait till I can get 1.2 - I'd rather go for stable realises | 10:21 |
| [KK]Kirill | but i don't remember is present this var | 10:21 |
| dhx_m | maybe you're setting it wrong? | 10:21 |
| mantisbot | New bug: Bug 10384 - ruslan - open - new | 10:25 |
| mantisbot | New bug: Roadmap can/should show priority symbol for issues. - http://www.mantisbt.org/bugs/view.php?id=10384 | 10:25 |
| AndyH | Could some advice how to set it up correctly? I've typed in the following into manage Configuration | 10:25 |
| AndyH | username: admin.., project: all, configuration option: logo_image type:default, value: images\mantis_logo2.jif | 10:26 |
| AndyH | And the responce I get (i'm using version 1.1.6) is "Configuration option "logo_image" not found." | 10:27 |
| dhx_m | can you try setting the option in config_inc.php? | 10:28 |
| dhx_m | $g_logo_image= 'images/mantis_logo.gif'; | 10:29 |
| dhx_m | or maybe your config option is just named wrong... it should be logo_image | 10:29 |
| AndyH | Sounds like a good idea! :) i'll get back to you | 10:29 |
| mantisbot | New bug: Bug 10385 - ruslan - open - new | 10:30 |
| mantisbot | New bug: ROADMAP should HIDE released versions !!! - http://www.mantisbt.org/bugs/view.php?id=10385 | 10:30 |
| AndyH | It has no affect | 10:36 |
| AndyH | I've typed in: $g_logo_image = 'images/rss.gif'; | 10:36 |
| dhx_m | looks ok to me, assuming mantisroot/images/rss.gif actually exists | 10:37 |
| dhx_m | well... that isn't true... that doesn't have to exist | 10:37 |
| dhx_m | are you still getting the same error? | 10:37 |
| AndyH | I've typed in other configuration options into the 'Manage Configuration', things like $g_window_title which have worked fine. But arn't seen when I view my config_inc.php file, is there anything file that can over write config_inc.php | 10:38 |
| dhx_m | well the settings you're defining in Mantis itself are stored in the database | 10:39 |
| dhx_m | and they take precedence | 10:39 |
| dhx_m | config_inc.php is just the text file configuration method | 10:39 |
| AndyH | Ok, so even though I use Manage Configuration on the web front end, and the options don't appear in config_inc.php doesn't mean that the config_inc.php is invalid, simply means that stored in the mantis database | 10:41 |
| dhx_m | yes | 10:42 |
| AndyH | Thanks good to know, | 10:42 |
| AndyH | :) | 10:42 |
| dhx_m | config_defaults.php contains the full set of available config options you can use | 10:42 |
| dhx_m | but don't edit that file directly | 10:42 |
| AndyH | sure | 10:42 |
| AndyH | Going to give that another go, Thanks for all the advice :) | 10:43 |
| mantisbot | New bug: Bug 10386 - Au1 - open - new | 10:55 |
| mantisbot | New bug: Multi-Line string field type is absent - http://www.mantisbt.org/bugs/view.php?id=10386 | 10:55 |
| mantisbot | New bug: Bug 10387 - ruslan - open - new | 10:55 |
| mantisbot | New bug: PRODUCT LINE / GROUP OF PROJECTS - http://www.mantisbt.org/bugs/view.php?id=10387 | 10:55 |
| mantisbot | New bug: Bug 10388 - ruslan - open - new | 10:55 |
| mantisbot | New bug: RoadMap should respect a PRODUCT LINE - http://www.mantisbt.org/bugs/view.php?id=10388 | 10:55 |
| dhx_m | HI I HAVE A CAPS LOCK KEY! :p | 10:56 |
| [KK]Kirill | :) | 10:59 |
| mantisbot | New bug: Bug 10389 - ruslan - open - new | 11:00 |
| mantisbot | New bug: Mantis should be more smart working with VERSIONs. ALPHA, BETA builds integrated together. - http://www.mantisbt.org/bugs/view.php?id=10389 | 11:00 |
| mantisbot | New bug: Bug 10390 - ruslan - open - new | 11:10 |
| mantisbot | New bug: Easy VIEW ISSUES from a person. - http://www.mantisbt.org/bugs/view.php?id=10390 | 11:10 |
| * daryn_away is away: Gone away for now | 13:05 | |
| * daryn is back. | 13:05 | |
| AndyH | I've just updated my evaluation server to 1.2.0a3 to fix an issue I had with logo_image and logo_url, but an issue that was in 1.1.6 is there still there in 1.2, to do with default_bug_view_status, | 13:25 |
| AndyH | when I try and enter in my default_bug_view_status into config_inc.php it complains that it needs a number, whereas default_bug_view_status should be VS_PRIVATE or VS_PUBLIC not a number. I've tried all numbers up to 5, but nothing sets the default bug view. ANY ideas? | 13:26 |
| AndyH | $g_default_bug_view_status = 'VS_PRIVATE'; that's what's in config_inc.php | 13:28 |
| AndyH | and the answer I get is A number was expected for view_state. | 13:28 |
| daryn | AndyH don't put quotes around it | 13:29 |
| daryn | it's a constant | 13:29 |
| daryn | it should be $g_default_bug_view_status = VS_PRIVATE; | 13:29 |
| AndyH | AH! :D | 13:29 |
| AndyH | FANTASTIC .. there and then just solved the issue | 13:30 |
| AndyH | didn't think about variables and constant, I was just reading the manual, and typing in what I saw | 13:30 |
| AndyH | Thank you! :) :) :) | 13:30 |
| daryn | yw | 13:30 |
| mantisbot | New bug: Bug 10391 - cmattmiller - open - new | 14:06 |
| mantisbot | New bug: Upgrading not modifying tables? - http://www.mantisbt.org/bugs/view.php?id=10391 | 14:06 |
| mantisbot | New bug: Bug 10392 - cmattmiller - open - new | 17:12 |
| mantisbot | New bug: Error after upgrade from 1.0.6 to 1.1.1 - http://www.mantisbt.org/bugs/view.php?id=10392 | 17:12 |
| * paul_ moos | 18:16 | |
| twolfy | hi, is the 1.2.0 release using some AJAX improvements? | 18:59 |
| twolfy | or a template system like smarty? | 19:00 |
| twolfy | may be I'm able to help out a bit (with ajax and / or smarty) if that would be welcome (I don't know where mantis likes to go) | 19:06 |
| twolfy | is there a "where we like to go"-paper? | 19:07 |
| paul_ | twolfy: mmm ajax | 19:18 |
| paul_ | you experienced in ajax stuff? :) | 19:18 |
| twolfy | a litle (with jquery and jquery-ui) | 19:19 |
| twolfy | but AJAX is very easy with jquery :) | 19:19 |
| paul_ | jquery = framework right? | 19:21 |
| twolfy | yes, JS-framework | 19:21 |
| paul_ | how/where would you like some ajax improvements? | 19:22 |
| * paul_ isn't a ajax expert | 19:22 | |
| twolfy | submiting bug-reports, get more informations - but only if they would be needed | 19:22 |
| twolfy | page-reloading | 19:23 |
| twolfy | check for new changes | 19:23 |
| w00ter | How do i put the options for status_enum_string in the array field of Configuration Report (which on file looks like; $s_status_enum_string = '10:Gelogd,20:Geprioriteerd,30:Impact Analyse,40:Bouw,50:SRT Test,60:GAT,80:Op Productie,90:Gesloten'; ) | 19:23 |
| twolfy | (so you don't have to reload the whole page) | 19:23 |
| twolfy | cool is, you could use AJAX in a way that all functionality wont be lost if the user hasn't JS enabled | 19:24 |
| daryn | twolfy: not just cool. essential | 19:24 |
| twolfy | but if the user has, AJAX would be used and improved the user-experience | 19:25 |
| paul_ | twolfy: i'd like to make the project dropdown selector thing more ajax'y | 19:25 |
| paul_ | either using the stuff we have in mantis atm | 19:25 |
| paul_ | or doing something more funky | 19:26 |
| twolfy | yes daryn, you're right | 19:26 |
| paul_ | if you fancy a play | 19:26 |
| daryn | regarding templates...some people working on it | 19:26 |
| paul_ | daryn: people should stop caring about templates ;0 | 19:26 |
| twolfy | hmm, how should the drop-down menu work with AJAX? | 19:27 |
| twolfy | with search-capability? | 19:27 |
| paul_ | I dont know really :) | 19:27 |
| paul_ | atm, there's the normal project dropdown | 19:27 |
| paul_ | and also what you get if you turn on extended view (can't recall the config option) | 19:28 |
| paul_ | I guess from one point of view it might need to be a tree type stucture | 19:28 |
| paul_ | to show subprojcts nicely | 19:28 |
| * paul_ doens't really know ;) | 19:28 | |
| giallu | if anyone wants my opinion, I'm ok with jquery | 19:28 |
| daryn | me too | 19:28 |
| daryn | sooner the better | 19:28 |
| twolfy | :) | 19:29 |
| giallu | twolfy, on the other hand | 19:29 |
| paul_ | jquery seems to come up, with got projax in atm (which seems to still be getting updated - /me sync'd the jscript with upstream other day) | 19:29 |
| paul_ | and when I asked my friend who does ajax stuff | 19:30 |
| paul_ | he said mootools? | 19:30 |
| paul_ | or something | 19:30 |
| giallu | if you're serious about contributing some patches (god knows how we need new blood...) I'd hope you'll stay with us also later | 19:30 |
| twolfy | AJAX is only one good point in jquery - it's only about reduce load from the server | 19:30 |
| twolfy | and providing something like "auto-update", the simple way | 19:31 |
| * paul_ reads http://blog.creonfx.com/javascript/dojo-vs-jquery-vs-mootools-vs-prototype-performance-comparison | 19:31 | |
| * nuclear_eclipse is not convinced we need AJAX for much in mantis | 19:31 | |
| * paul_ thinks nuclear_eclipse is webgarbage | 19:32 | |
| paul_ | it's about the web2.0!! | 19:32 |
| nuclear_eclipse | I will agree that we need jQuery, but not AJAX | 19:32 |
| twolfy | nuclear_eclipse, you wont need it, but it can improve some workflow :) | 19:32 |
| paul_ | whats the difference between jquery+ajax? | 19:32 |
| twolfy | also it should be possible to make ajax-template as option | 19:33 |
| giallu | paul_, go RTFM ;) | 19:33 |
| nuclear_eclipse | jquery is a library for manipulating the DOM; AJAX is asynchronous communication with the server outside the standard pageload scope | 19:33 |
| paul_ | twolfy: well, we already have a 'javascript' config option | 19:33 |
| daryn | btw paulr...projax is based on prototype | 19:34 |
| nuclear_eclipse | AJAX would also require that we have an XMLRPC interface, which we don't, and we can barely keep SOAP up to date | 19:34 |
| paul_ | just make it per-user and dont need a template | 19:34 |
| paul_ | daryn: right | 19:34 |
| daryn | which is the worst for performance | 19:34 |
| twolfy | nuclear_eclipse, no - ajax won't require xmlrpc | 19:34 |
| paul_ | nod | 19:34 |
| twolfy | only pain-html | 19:34 |
| twolfy | plain | 19:34 |
| giallu | anyway, projax should die, rather sooner thatn later | 19:34 |
| twolfy | you won't use it the xmlrpc/soap-way | 19:34 |
| nuclear_eclipse | AJAX = Async. JavaScript And XML ... | 19:35 |
| paul_ | giallu: it's still updated - http://script.aculo.us/ | 19:35 |
| giallu | then nuclear_eclipse, please note XMLRPC is _not_ the only transport you can use | 19:35 |
| nuclear_eclipse | then don't call it AJAX :P | 19:35 |
| twolfy | :) you are free to call it, as you like it :) | 19:36 |
| paul_ | (someone remind me why we needed to get rid of what we use atm? | 19:36 |
| giallu | JSON looks like the most widely used replacement | 19:36 |
| * nuclear_eclipse likes JSON | 19:36 | |
| giallu | paul_, because we move away from prototype | 19:36 |
| paul_ | 'why' | 19:37 |
| giallu | becasue we like more jquery | 19:37 |
| nuclear_eclipse | but either way, async javascripting would require a lot more work, and maintenance of even more API systems, and Idon't think it's feasible for us; I'd rather see developers focus on the core and SOAP | 19:37 |
| daryn | it isn't just moving 'away' from projax. | 19:37 |
| giallu | and less code == less bugs | 19:37 |
| daryn | what we have impemented currently is terrible | 19:37 |
| paul_ | is that our fault or frameworks? | 19:38 |
| giallu | daryn, so I'm not the only one with this idea ;) | 19:38 |
| daryn | we need to redesign how we use the js | 19:38 |
| daryn | jquery has very nice syntax | 19:38 |
| paul_ | where i'm at is: | 19:38 |
| paul_ | atm we have a js framework called prototype/projax/script.aculo.us/whatever it's bloody called | 19:38 |
| twolfy | nuclear_eclipse, you don't need to do this 'more' work | 19:39 |
| paul_ | people have thrown around jquery as a framework | 19:39 |
| twolfy | you could start with a simple AJAX-implementation | 19:39 |
| nuclear_eclipse | twolfy: if you want asynchronous communication with the backend for refreshing the content without reloading the page, you have to have an API | 19:39 |
| paul_ | when I asked the only person I know that seems to do ajax stuff (someone who's written an irc client in ajax amongst other things) he came back with mootools | 19:39 |
| twolfy | and then growing slowly | 19:39 |
| twolfy | right | 19:39 |
| paul_ | so i'm trying to work out what differences between these 3 things are :) | 19:40 |
| daryn | most likely mootools because it's faster on firefox | 19:40 |
| nuclear_eclipse | my point is that generating a javascript-powered interface is going to be a lot of effort that I think would be far better spent elsewhere in the codebase | 19:40 |
| daryn | the biggest debate for not using jquery is that it is slower on ff | 19:40 |
| twolfy | but you could wrap your application and provide those functionality | 19:40 |
| twolfy | that won't require a lot of work | 19:41 |
| paul_ | daryn: why do we want to use jquery/mootols over whateveritcallsitself? | 19:41 |
| paul_ | is there a technical reason or | 19:41 |
| twolfy | paul_, jquery provides already an easy way to integrate AJAX in your application | 19:41 |
| daryn | nuclear_eclipse done properly it should not affect the code base except to add id's/classes which is needed anyway | 19:41 |
| daryn | js should not be in the html | 19:41 |
| daryn | over projax? | 19:42 |
| paul_ | http://blog.creonfx.com/javascript/mootools-vs-jquery-vs-prototype-vs-yui-vs-dojo-comparison-revised | 19:43 |
| twolfy | it's not only about "what does the framework support/provide now" - also where does it go in 3 or 5 or more years | 19:46 |
| daryn | paulr yeah? what is your point? | 19:46 |
| twolfy | and jquery seems to be supported by a lot of companies (google, MS and so on :) | 19:46 |
| paul_ | looks like guy started a war :) | 19:46 |
| * paul_ nods | 19:47 | |
| daryn | maybe | 19:47 |
| paul_ | so how easy would it be to dump what we have now for jquery? | 19:47 |
| daryn | i think either mootools or jquery would probably be fine but I like jquery syntax | 19:47 |
| daryn | would take a while...but the js needs to be removed from pages anyway and loaded dynamically. | 19:48 |
| twolfy | jquery-syntax is similar to prototypes one | 19:48 |
| twolfy | in some parts of course :) | 19:48 |
| daryn | maybe. but it is significantly faster in every way | 19:49 |
| twolfy | right | 19:49 |
| * giallu thinks we have relatively few JS stuff, it shouldn't be so hard to switch at this stage | 19:50 | |
| paul_ | http://blog.thinkrelevance.com/2009/1/12/why-i-still-prefer-prototype-to-jquery seems to do some good comparision... anyway... | 19:51 |
| paul_ | from our point of view jquery is probably more popular = good | 19:51 |
| paul_ | i'm not necessarily sure we *need* to move to something different | 19:52 |
| paul_ | however, I think we'd probably benefit from using something that's gaining popularity | 19:52 |
| paul_ | i.e. jquery | 19:52 |
| twolfy | also jquery has an UI part | 19:54 |
| twolfy | which integrates nicely with the core | 19:54 |
| paul_ | twolfy: you could work on a patch to replace current js stuff with jquery | 19:55 |
| twolfy | okay, will start tomorrow at work | 19:56 |
| paul_ | as i'm guessing it's probably worth replacing current code with jquery equiv | 19:56 |
| twolfy | hmm, charset whithin code would be utf8 I guess? | 19:58 |
| paul_ | lang_get('charset') :P | 19:58 |
| paul_ | but yes, I think would normally be utf8 | 19:58 |
| paul_ | not sure it's guaranteed to be :) | 19:58 |
| twolfy | oh, okay :) | 19:59 |
| paul_ | nuclear_eclipse: what about putting project selector on a different page to top right? | 20:01 |
| nuclear_eclipse | huh? | 20:02 |
| paul_ | the project selector | 20:02 |
| paul_ | ;) | 20:02 |
| daryn | how about...removing the project selector | 20:02 |
| * paul_ wants to either move or ajaxify | 20:02 | |
| nuclear_eclipse | I'd rather see if get javascript treatment, but I don't see how that will improve anything... | 20:02 |
| daryn | no...it needs to be rethunk | 20:03 |
| daryn | that thing is the source of much confusion | 20:03 |
| twolfy | hmm how far is the 1.2.0 release? | 20:03 |
| daryn | at the current rate? | 20:04 |
| daryn | 2042 | 20:04 |
| twolfy | is master already open for changes? | 20:04 |
| twolfy | ;) | 20:04 |
| nuclear_eclipse | twolfy: it's been open since 1.1.0rc1 was released :P | 20:04 |
| twolfy | is there an internal release-date? | 20:05 |
| paul_ | sure | 20:05 |
| nuclear_eclipse | whenitsdone | 20:05 |
| paul_ | sunday | 20:05 |
| paul_ | :) | 20:05 |
| twolfy | :) | 20:05 |
| twolfy | okay | 20:05 |
| paul_ | I need at least 48 hours to break trunk before we can do a relase | 20:06 |
| paul_ | can't have a release without breaking something | 20:06 |
| twolfy | :) | 20:06 |
| paul_ | moving to jquery seems like a good thing to do as the last commit before a release! | 20:06 |
| paul_ | oh, and sync in my dates branch | 20:06 |
| twolfy | right, that could help you to break things :) | 20:06 |
| nuclear_eclipse | as unofficial release manager, I'll make sure to revoke your commit access before announcing a release date :P | 20:07 |
| giallu | +1 to removing project selector (sorry, I'm late ) ;) | 20:07 |
| nuclear_eclipse | how do we get rid of the project selector? | 20:07 |
| daryn | delete it | 20:07 |
| daryn | :D | 20:08 |
| nuclear_eclipse | right, but then everything in Mantis breaks for any installation with >1 project.... | 20:08 |
| daryn | it still works....you just have to use the filter | 20:08 |
| giallu | and add it as a field in the bug report page | 20:09 |
| daryn | yeah | 20:09 |
| daryn | that too | 20:09 |
| nuclear_eclipse | that sounds annoying... | 20:09 |
| giallu | nuclear_eclipse, granted | 20:09 |
| giallu | but just the coding part | 20:09 |
| giallu | then it's a lot less bug reports | 20:10 |
| daryn | what's more annogying is spending an hour trying to figure out why your issues aren't showing up in the filter and then realizing the stupid selector has changed | 20:10 |
| daryn | or submitting a bug report and then CRAP wrong project | 20:10 |
| giallu | then suddenly you can also show issues from teo | 20:10 |
| giallu | from two projects | 20:10 |
| giallu | not just one or all | 20:11 |
| paul_ | well could just amke top right be | 20:11 |
| paul_ | '<currentprojectname> [change] | 20:11 |
| paul_ | clicking changes goes to set_proj.php or whatever it is | 20:11 |
| paul_ | that means we dont need to render project dropdown on every page | 20:11 |
| paul_ | speeding up mantis ;) | 20:11 |
| nuclear_eclipse | paul_: I'd rather see that | 20:12 |
| daryn | right...by .0000000000000000000000000001 sec | 20:12 |
| paul_ | what i just said ? | 20:12 |
| paul_ | daryn: not if you have 2000 projects | 20:12 |
| paul_ | :) | 20:12 |
| giallu | daryn, well. the dropdown is a killer for someone | 20:12 |
| giallu | see help list | 20:12 |
| daryn | if we're going to do that can we add some kind of project indicator? like a nice wide border with the project name or something? | 20:12 |
| giallu | but surely, we don't change just for optimizing that use case | 20:13 |
| daryn | no...because it's annoying | 20:13 |
| nuclear_eclipse | I've never actually had any problems with the dropdown doing things wrong, but maybe I'm the weird person who actually keeps track of what project they have selected.... | 20:13 |
| * daryn smacks nuclear_eclipse for his smugness | 20:13 | |
| paul_ | well | 20:13 |
| twolfy | as a user of mantis I like the project-selector - may be it should be configure-able | 20:13 |
| * nuclear_eclipse bans daryn from #mantishelp | 20:13 | |
| giallu | nuclear_eclipse, really. we should stop thinking about just what bogs us, we also have users | 20:13 |
| twolfy | and be disabled on default | 20:13 |
| paul_ | it's a fun one :) | 20:14 |
| giallu | and we have lots of bugreports related to the selector | 20:14 |
| daryn | so...how can we improve it | 20:14 |
| nuclear_eclipse | well, anywho, I need to go eat and work out | 20:14 |
| giallu | I'm +1 for the '<currentprojectname> [change]' type | 20:14 |
| giallu | but | 20:14 |
| nuclear_eclipse | +1 from me as well | 20:15 |
| nuclear_eclipse | cheers all | 20:15 |
| giallu | of bug report page we also add a field for the project | 20:15 |
| daryn | +1 from me with the addition of some kind of notifier...on every page | 20:15 |
| paul_ | for the most part | 20:15 |
| giallu | s/of/on | 20:15 |
| paul_ | people use 1 project right? | 20:15 |
| twolfy | hmm, in our company we are using a lot of projects at the same time :) | 20:16 |
| giallu | and we aslo add it to filters | 20:16 |
| daryn | we are too. i think he means one at a time | 20:16 |
| paul_ | i was going to say | 20:16 |
| paul_ | people use 1 project | 20:17 |
| paul_ | *but* subprojects | 20:17 |
| paul_ | i.e. if we made mantis have subprojects for various areas | 20:17 |
| paul_ | you'd probably want the subprojects on each page | 20:17 |
| twolfy | hmm we have multiple master-projects | 20:22 |
| twolfy | for our it there are 4 with multiple subprojects | 20:22 |
| twolfy | but right - many of us only working in one master-branch | 20:23 |
| twolfy | hmm, what's about using smarty as template-system to split code from the output-format? | 20:30 |
| twolfy | that's something that sould be easly done (as I'm working on the prototype->jquery port - I should be able to also switch the code to smarty) | 20:32 |
| twolfy | if it would be welcome :) | 20:32 |
| daryn | twolfy some people have been working on that | 20:33 |
| daryn | not sure if they are using smarty or not. has been alot of discussion | 20:33 |
| twolfy | do you have any checkout-uri for me? | 20:34 |
| paul_ | tbh, I dont think we'll end up with user-modifiable templates anyway | 20:35 |
| giallu | twolfy, daryn consensus was going to smart was not worth, sticking with a simpler php based template system looked feasible | 20:35 |
| daryn | paul_...we're not talking about user modifiable templates so...get that out of your head! | 20:35 |
| paul_ | ;) | 20:35 |
| twolfy | :) | 20:36 |
| daryn | twolfy i don't see a repo...can't remember who was working on it dhx maybe? | 20:36 |
| twolfy | yes, it's about MVC ^^ | 20:36 |
| daryn | i'm fine with straight php if we can be disciplined and keep business logic out of the html | 20:36 |
| paul_ | daryn: we mainly do that now though? | 20:37 |
| daryn | and if i have freedom to slap anyone who doesn't | 20:37 |
| twolfy | :) | 20:37 |
| daryn | paul_ you are joking, right? | 20:37 |
| twolfy | okay, I'll prepare some thougth tomorrow and pubish them on github, so you're able to check them out | 20:38 |
| paul_ | twolfy: do jquery stuff | 20:39 |
| twolfy | yes, I'll :) | 20:39 |
| paul_ | daryn: well, some pages | 20:39 |
| paul_ | *most* db queries are in api's | 20:39 |
| daryn | right, but we have a ton of html being printed from php pages, functions, and api's | 20:39 |
| twolfy | yes | 20:40 |
| daryn | all of which should be removed and made into nice html templates with php to control the display logic | 20:40 |
| paul_ | I want to get all the sql calls that are left out of the _page.php files | 20:42 |
| daryn | that would be good | 20:42 |
| twolfy | okay, got to go | 20:46 |
| twolfy | bye bye up to tomorrow | 20:46 |
| daryn | bye. welcome aboard | 20:46 |
| twolfy | thx :) | 20:46 |
| harpreet_singh | hi | 21:02 |
| CapitanPolpo | hi! | 21:03 |
| harpreet_singh | hi... I am trying to install mantis 1.1.7 | 21:03 |
| CapitanPolpo | hi! i have installed mantis 1.1.7. .... i have trouble? | 21:04 |
| CapitanPolpo | you have problems? | 21:04 |
| harpreet_singh | but I am not able to find the db_generte.sql file. | 21:04 |
| harpreet_singh | yes... | 21:04 |
| harpreet_singh | this is a fresh installation. | 21:04 |
| CapitanPolpo | you have start with the instant mantis 1_1_1? | 21:05 |
| moto-moi | doesn't the installer create the database for you :? | 21:05 |
| moto-moi | <-- hasn't installed mantis in a few years :P | 21:05 |
| harpreet_singh | no I have downloaded the tar file | 21:06 |
| harpreet_singh | this is on server.... | 21:06 |
| CapitanPolpo | i have started whit version 1.1.1, that contains also the database, and after i have upgrade it with version 1.1.7 and it work well! | 21:07 |
| CapitanPolpo | sorry for my bad english! (-: | 21:08 |
| harpreet_singh | u means I can not directly install Ver 1.1.7 | 21:08 |
| CapitanPolpo | no | 21:08 |
| harpreet_singh | no issue.. same here.. zombe.... | 21:08 |
| harpreet_singh | in night shift... | 21:08 |
| CapitanPolpo | the 1.1.7 as only the php source | 21:09 |
| CapitanPolpo | have only the php source.. but you need also the server, apache, mysql and php | 21:09 |
| CapitanPolpo | is all in the istant_mantis installationù | 21:09 |
| CapitanPolpo | understand? | 21:10 |
| harpreet_singh | I have already install apache 2.2.11, php-5.2.9, mysql 5.1.33-0. | 21:11 |
| harpreet_singh | hi..may I know where I can download mantis 1.1.1 | 21:15 |
| CapitanPolpo | i'm sorry, i can't help you, i have installed the instant_mantis | 21:15 |
| CapitanPolpo | ok... just a moment | 21:15 |
| harpreet_singh | no issue. | 21:17 |
| CapitanPolpo | ok | 21:18 |
| CapitanPolpo | http://sourceforge.net/project/downloading.php?group_id=14963&filename=InstantMantis-1.1.1.zip&a=41619722 | 21:18 |
| CapitanPolpo | here | 21:18 |
| CapitanPolpo | ok? | 21:20 |
| harpreet_singh | ok | 21:23 |
| CapitanPolpo | (-: | 21:23 |
| harpreet_singh | Thanks... | 21:23 |
| CapitanPolpo | (-: | 21:23 |
| harpreet_singh | but this one also dont have db_generate.sql | 21:23 |
| CapitanPolpo | i don't know...... just a minute, i check | 21:24 |
| CapitanPolpo | no not find in my installation | 21:24 |
| harpreet_singh | I have ver 0.17 where I can see the mantis/sql/db_generte.sql file | 21:28 |
| paul_ | 0.17? | 21:40 |
| paul_ | or 1.1.7? | 21:40 |
| CapitanPolpo | i think 1.1.7 | 21:42 |
| harpreet_singh | mantis-0.17.5 | 21:43 |
| paul_ | 0.17.5 is *OLD* | 21:48 |
| harpreet_singh | yah... | 21:52 |
| CapitanPolpo | .... | 21:52 |
| harpreet_singh | so now I am doing a new setup. | 21:53 |
| paul_ | i'm confused | 21:53 |
| paul_ | are you trying to upgrade | 21:53 |
| paul_ | or do a new install? | 21:53 |
| harpreet_singh | no... | 21:53 |
| harpreet_singh | this is a new Install. | 21:53 |
| CapitanPolpo | have you installed instant mantis 1.1.1?? | 21:54 |
| paul_ | harpreet_singh: /admin/install.php creates the db now | 21:54 |
| harpreet_singh | instant mantis is for server ? | 21:54 |
| CapitanPolpo | istant mantis contains the servers, apache, mysqk and php | 21:55 |
| CapitanPolpo | it's ready to run | 21:55 |
| harpreet_singh | oh.. | 21:55 |
| harpreet_singh | I think you are running InstantMantis on your PC | 22:05 |
| harpreet_singh | not a server base | 22:05 |
| harpreet_singh | C:\ABC\manual\manual.installation.html | 22:10 |
| harpreet_singh | Next we will create the necessary database tables and a basic configuration | 22:10 |
| harpreet_singh | :) | 22:23 |
| harpreet_singh | hi | 22:50 |
| harpreet_singh | hi | 23:47 |
Generated by irclog2html.py