| 02:24.53 | *** join/#brlcad polyspin (~polyspin@pcp0011463358pcs.chrchv01.md.comcast.net) | |
| 02:26.57 | polyspin | yodel ley hei hoo! |
| 02:27.35 | brlcad | riiicola |
| 02:29.12 | polyspin | Is there any description of the "task" system on sourceforge that I could quote for the CMP? |
| 02:30.13 | brlcad | i don't think so, but lesse. |
| 02:32.01 | brlcad | http://sourceforge.net/docman/display_doc.php?docid=24202&group_id=1 |
| 02:33.39 | polyspin | The word "task" does not seem to appear on the page |
| 02:33.53 | brlcad | no, that's for the tracker system |
| 02:34.01 | brlcad | the task tracker is a separate system |
| 02:34.28 | brlcad | task was the first one we looked at that has the simple TODO list for now |
| 02:34.56 | brlcad | the bug reporting, feature requests, support requests, patches are all part of the tracker system |
| 02:35.21 | brlcad | that's a simple manual of how to use it -- not exactly recommended usage, but seomthing |
| 02:35.56 | polyspin | I was going to "play" with it, so I could see what we wanted to claim in our "process" about it. Didn't want to create anything I couldn't delete. |
| 02:39.07 | brlcad | hrm |
| 02:46.30 | brlcad | the only really configurable part is the categories and groups |
| 02:47.33 | brlcad | the categories are fairly well defined already .. the groups are unused for the most part though |
| 02:48.18 | brlcad | sf support uses groups internal to their project to group requests into first/second/third tier support levels |
| 02:48.33 | brlcad | we don't have that kind of grouping |
| 02:49.07 | brlcad | the rest of the fields are fairly standardized for the tracker types -- topic, submitter, assignee, priority, .. |
| 02:51.21 | polyspin | categories and groups are wrt trackers, not tasks right? |
| 02:52.33 | brlcad | right |
| 02:52.35 | polyspin | I've played with the tracker enough now that I like, and we'll use it. |
| 02:53.05 | brlcad | it might be easier to actually use the tracker system for tasks too, depending on the need |
| 02:53.06 | polyspin | If there is any value in the "task" system, I wanted to know. It's ok for us to ignore it for now. |
| 02:53.16 | polyspin | Yes. I agree |
| 02:53.24 | polyspin | I like the traceability the tracker provides. |
| 02:53.25 | brlcad | what the task system gives you that the tracker system doesn't is dependencies |
| 02:54.25 | polyspin | s in "this task depends on that one" and "that one starts when this one finishes" kind of stuff? |
| 02:54.36 | brlcad | most projects actually don't use the task tracker on sf as that generally get's into a project's "business", which gets into a degree of planning that most open source projects don't have |
| 02:55.13 | brlcad | hmm.. I gotta stop saying "task tracker".. it's the "task system", not a tracker really -- at least not part of the tracker system |
| 02:55.40 | brlcad | the few that I have seen using it are for short term and long term planning |
| 02:56.23 | brlcad | e.g. one task category will be the next two minor revisions, another may be the next major protocol-breaking revision |
| 02:56.30 | polyspin | might be of value to us then. Though we might not want THAT kind of thing publicly available (as in, on an outside server) |
| 02:56.36 | brlcad | the task items will be a feature list or todo list of sorts |
| 02:56.55 | polyspin | got it. |
| 02:57.20 | brlcad | there can be private task lists too |
| 02:57.27 | brlcad | only visible to devs, for example |
| 02:57.59 | polyspin | and not mgmt? ;-) |
| 02:58.43 | brlcad | could even create an "ARL Management" user identifier that could be granted access |
| 02:58.54 | brlcad | you can create arbitrary user classifications |
| 02:59.19 | brlcad | but they would have to at least have an sf account, be logged in, and be in the appropriate group, of course |
| 02:59.37 | polyspin | Since they want to do everything through a "CR" type structure, I guess it's not important. |
| 02:59.39 | brlcad | not exactly something I'd recommend :) |
| 03:00.06 | polyspin | we'll stick to the tracker. |
| 03:00.16 | brlcad | change requests are effectively the RFE tracker |
| 03:00.25 | polyspin | yup |
| 03:00.31 | polyspin | or the bug tracker. |
| 03:00.43 | brlcad | yeah |
| 03:01.35 | polyspin | beep beep beep beep (as the truck backs up to the loading dock) |
| 03:04.00 | polyspin | Have you tried the "Camino" browser? |
| 03:04.08 | brlcad | interesting read: http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=240 |
| 03:04.15 | brlcad | yeah, I've tried camino |
| 03:04.22 | brlcad | too buggy last I checked |
| 03:04.38 | brlcad | but that was a while ago |
| 03:04.41 | polyspin | I've used it since the weekend. Pretty cool. |
| 03:05.37 | polyspin | Found a good paper on OSS Config Mgmt. |
| 03:05.57 | brlcad | per that article, we don't seem to fit any of the potential negatives but do all the positives |
| 03:06.08 | brlcad | yeah, I want to read that sometime |
| 03:06.12 | brlcad | is it posted somewhere? |
| 03:06.25 | polyspin | Hang on, I'll try to send you a copy |
| 03:07.32 | polyspin | on its way |
| 03:07.43 | brlcad | cool |
| 03:09.20 | polyspin | Hmmm. DCC still says "connecting" |
| 03:10.32 | brlcad | try again |
| 03:10.55 | brlcad | i usually ignore dcc's |
| 03:11.18 | brlcad | says I can't connect to you |
| 03:11.25 | brlcad | oh, you're on cable yes? |
| 03:11.41 | polyspin | still seems to be stuck at "Connecting". Oh, probably because I'm behind a router/firewall |
| 03:11.44 | brlcad | you can't negotiate dccs there |
| 03:11.59 | polyspin | Hang on, I'll find the URL |
| 03:12.02 | brlcad | can scp up to .bz into /tmp |
| 03:13.01 | polyspin | http://opensource.ucc.ie/icse2001/asklundbendix.pdf |
| 03:27.07 | polyspin | I am postulating that every bug fix should result in a "Release", and that the nightly regression test should "package" the release. |
| 03:27.36 | polyspin | this makes it trivial to create a release, and upload binaries. |
| 03:28.50 | brlcad | easy enough to post that to the website, but would be more problematic to get it into the file release system |
| 03:29.19 | brlcad | since that requires creation of release revision numbers through the web interface after authentication, upload of ftp, selection, etc |
| 03:29.29 | polyspin | I don't care about automating the uploads. I expect that can be done by hand. Given that we're talking about a 1/week activity |
| 03:29.57 | brlcad | I've seen dozens of bugs get fixed in a day or two |
| 03:30.05 | brlcad | one a day every day for a month .. |
| 03:30.12 | polyspin | OK, so we limit it to 1/day |
| 03:31.07 | polyspin | I am trying to get people to think in terms different from the "when should we get around to releasing" ones they historically have. |
| 03:32.37 | brlcad | i agree that's a good thing .. release new patch updates after every fix -- perhaps push those automatically up to the website, though |
| 03:32.50 | polyspin | What metric would YOU suggest for making a "release" binary kit? |
| 03:33.03 | brlcad | and then periodically (e.g. 1/month) upload the latest up to the tracker |
| 03:33.23 | polyspin | A good idea. |
| 03:33.43 | polyspin | Tracker? File Release System |
| 03:33.48 | brlcad | er, yeah :) |
| 03:33.54 | polyspin | VersionTracker ;-) |
| 03:34.00 | brlcad | that too |
| 03:34.22 | polyspin | That would make CCB happy: They could exercise their "Release decision" |
| 03:34.58 | brlcad | a "full release" will normally take days after everything's in place - news channels to notify, sites to update, places like versiontracker/freshmeat/etc to update, dozens of e-mail notifications |
| 03:35.17 | brlcad | hence 1/month would be good for that |
| 03:36.42 | polyspin | Who are the e-mail notifications? |
| 03:36.53 | polyspin | Could that be automated? |
| 03:37.15 | brlcad | should be automateable |
| 03:37.24 | brlcad | i've listed some in HACKING |
| 03:37.37 | brlcad | some I've discovered since by following the on-line CAD sites |
| 03:37.58 | brlcad | already e-mailed a few to update their information, though I'm sure there are lots out there |
| 03:38.35 | polyspin | 'k |
| 03:41.27 | brlcad | some of them will not be every time, like /. submissions |
| 03:41.59 | brlcad | some are web forms, some are e-mail -- some specify format requirements for news postings, some don't |
| 03:42.24 | brlcad | for the static web forms and e-mailers, though, it should be possible to automate it to at least some extent |
| 03:45.08 | polyspin | I love Pareto's Law at the bottom of that ACM paper |
| 03:48.36 | brlcad | btw, our version control doc is in doc/cvs.txt iirc might be useful |
| 03:49.54 | polyspin | Yes, I've got that. |
| 03:55.58 | brlcad | second paragraph on the second page pretty much sums it up correctly |
| 03:57.44 | polyspin | Third para on third page is the one I plan to point out most |
| 03:58.27 | polyspin | This is going to be a part of my CMP hand-outs |
| 04:00.03 | brlcad | oh that is a good bullet |
| 04:01.08 | brlcad | at least the first two sentences |
| 04:02.34 | polyspin | yes, those first two sentences |
| 04:03.07 | brlcad | second bullet of lessons learned is interesting (and quite true) |
| 04:03.28 | brlcad | self-assigned tasks |
| 04:04.00 | polyspin | And users of the system. I'm going to propose we become more active users. |
| 04:04.16 | polyspin | Things like: Should Keith be on our team? |
| 04:04.49 | brlcad | unless/except where there is money backing the development, development improvements will be rather across the board |
| 04:05.01 | brlcad | hmm.. keith.. what would he "do"? |
| 04:05.10 | polyspin | model |
| 04:05.25 | polyspin | We would model some too. |
| 04:05.34 | polyspin | That way, the changes we make benefit US |
| 04:05.39 | brlcad | i figured the later a given |
| 04:05.46 | polyspin | WE see what needs to be done, and do it becuase WE need it. |
| 04:06.11 | brlcad | yes, quite -- so long as there's someone letting us fix the things we find need fixing :) |
| 04:06.12 | polyspin | Self interest, self motivation. |
| 04:06.21 | polyspin | Precisely. |
| 04:06.31 | brlcad | it's easy to point out deficiencies |
| 04:06.43 | brlcad | could pick pretty much any tool, and file and find a way to improve it |
| 04:06.55 | brlcad | only a handful will impact the bottom line, though |
| 04:07.03 | polyspin | Sure. But which ones would contribute to you being able to model faster/better |
| 04:07.15 | polyspin | Which ones make the analysis easier? |
| 04:07.15 | brlcad | yes, quite |
| 04:07.31 | polyspin | Which ones result in less human work in the end. |
| 04:08.07 | polyspin | What I've learned from blender ... sigh |
| 04:08.57 | polyspin | Bottom line: I think we need to be more tightly tied to the analysis being done. |
| 04:08.59 | brlcad | hehe.. quote from another fella that read the paper: "more likely oss succeeds because there is no marketing/sales or management types involved :)" |
| 04:09.05 | polyspin | It server our Vis purposes too. |
| 04:09.31 | brlcad | it does |
| 04:11.03 | brlcad | the ability to model the full details of practically anything efficiently is something I'm hoping we'll have soon |
| 04:11.31 | brlcad | and to be able to introspect any of that data, and apply basic physics interactions for the purpose of modeling |
| 04:11.47 | brlcad | introspection also for visualization, of course too |
| 04:11.58 | polyspin | Yee Ha! |
| 04:13.06 | polyspin | Proprioception being the latest buzzword for all that |
| 04:13.22 | brlcad | do things like model a fully contrained tank and a building -- drive the tank into the building and have basic physics take over for the interactions |
| 04:13.56 | brlcad | analyses could rather esaily intercept the "basic physics" and apply real dynamics simulations |
| 04:14.14 | brlcad | if not, you get a quick and dirty for the purpose of modeling |
| 04:14.37 | brlcad | perpahs all you wanted is a model of a building that looks like a tank rammed into it |
| 04:15.02 | brlcad | perhaps you wanted to see how the turret structure holds |
| 04:15.31 | brlcad | add the hooks in for a modeler, and the coupling to analyses becomes pretty clear |
| 04:17.08 | brlcad | the third bullet of transfer of lessons learned in the paper is interesting, though I think we can get by that by simply referencing sf tracker id's in the commit messages for commits that fulfill some tracker item |
| 04:17.31 | brlcad | that should give the traceability he says often isn't there |
| 04:18.11 | brlcad | setting priority (fourth bullet) can be a problem |
| 04:18.24 | polyspin | Yes, I can spit that third bullet back at them. |
| 04:18.25 | brlcad | since there's a conflict between what's paid for, what's not -- who's doing what |
| 04:19.00 | brlcad | for those "self-assigning" tasks -- they will work regardless of any priorities we set on items to some extent |
| 04:19.08 | polyspin | Except for us, we are not entirely self-assigned. We have a specific mission. |
| 04:19.14 | polyspin | So we dodge that bullet too. |
| 04:23.24 | polyspin | If the mission is OURS. I think that pretty much drops that argument into the wastebasket |
| 04:23.24 | brlcad | example: bzflag's maintainer has had "high priority" on a karma system that none of the other devs really like or think will work well as least without major changes |
| 04:23.24 | polyspin | Key: He's not putting MONEY behind it. |
| 04:23.24 | brlcad | so it's been 3 or more years and progress on it pretty much crawls just at the rate of what he can implement himself which loads of time is invested by others into other tasks |
| 04:23.24 | brlcad | yes, and he knows that so he can only "encourage" or complain so much |
| 04:23.24 | brlcad | it is a beautiful thing when all the devs agree and work on some feature though.. that I have to admit |
| 04:23.24 | brlcad | akin to working off-site for a week on some goal |
| 04:23.24 | polyspin | Yeap. I miss those days. |
| 04:24.55 | brlcad | getting started on the new modeler interface would be a nice offsite |
| 04:25.24 | polyspin | I may have an angle on getting that funded. I'll talk to you in private about that sometime. |
| 04:25.45 | brlcad | what're your thoughts on the application interface for that? |
| 04:26.24 | polyspin | I don't want to record that in this forum. |
| 04:26.25 | brlcad | i've been leaning towards doing the whole thing in open gl, and just picking some library to provide the context |
| 04:27.05 | brlcad | pm's work too :) |
| 04:27.55 | polyspin | True, but I think we'll want to spend an hour if I start, and I need to get some sleep soon. |
| 04:28.21 | brlcad | fair enough |
| 04:31.57 | polyspin | cya tmrw? |
| 04:32.03 | brlcad | yeah |
| 04:32.09 | brlcad | it is about that time |
| 04:32.14 | polyspin | pasta la vida |
| 04:32.31 | brlcad | hasta tamale |
| 04:40.29 | jano | como frijoles? |
| 04:42.21 | brlcad | no gracias.. me da farts |
| 04:48.33 | jano | como frijoles: mexican for "how have you bean" :P |
| 06:19.29 | *** join/#brlcad Pimpi (~frank@p50820149.dip0.t-ipconnect.de) | |
| 10:51.12 | *** join/#brlcad DarkMaster (~Matthew@resnet-253-237.resnet.umbc.edu) | |
| 13:31.56 | *** join/#brlcad cad843 (~a8a650ca@bz.bzflag.bz) | |
| 13:49.20 | *** part/#brlcad cad843 (~a8a650ca@bz.bzflag.bz) | |
| 15:14.39 | CIA-3 | BRL-CAD: 03brlcad * 10brlcad/src/iges/iges.c: removed erroneous trailing comma on stdout header output case. (fix from manfreds, sf bug 1123436) |
| 15:40.13 | CIA-3 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed g-iges stdout header bug (sf bug 1123436) |
| 19:45.34 | *** join/#brlcad guu (guu@myth.gibbscam.com) | |
| 21:21.22 | *** join/#brlcad EricWilhelm (~ewilhelm@adsl-65-64-190-51.dsl.tpkaks.swbell.net) | |
| 21:37.09 | *** join/#brlcad ibot (ibot@apt.bot.TimRiker.active.supporter.pdpc) | |
| 21:37.09 | *** topic/#brlcad is http://brlcad.org/ || BRL-CAD is now Open Source! || Screenshots: http://sourceforge.net/project/screenshots.php?group_id=105292 || http://brlcad.org/images/mged.jpg || Release 7.2.0 is under way today (20050211)... | |
| 23:08.14 | *** part/#brlcad brlcad (~brlcad@brlcad.bronze.supporter.pdpc) | |
| 23:08.43 | *** join/#brlcad brlcad (~brlcad@brlcad.bronze.supporter.pdpc) | |
| 23:08.43 | *** mode/#brlcad [+o brlcad] by ChanServ | |
