Community Meeting 2005-03-18
From World Wind Wiki
Revision as of 22:35, 18 March 2005 (edit) Jessi (Talk | contribs) ← Previous diff |
Current revision (04:44, 22 June 2006) (edit) (undo) F0urtyfive (Talk | contribs) |
||
(11 intermediate revisions not shown.) | |||
Line 1: | Line 1: | ||
On IRC #worldwind-dev, irc.freenode.net, 2300 UTC, 2005-03-18. | On IRC #worldwind-dev, irc.freenode.net, 2300 UTC, 2005-03-18. | ||
- | ==Agenda== | + | Transcript: http://worldwind.arc.nasa.gov/dev/community-meeting-2005-03-18.txt |
- | I would like for the OS team to be kept up to date on what the NLT team is doing (this is fine when jessi is around). (Bull) | + | ==Agenda== |
We need to decide how long the beta testing period should last. (Bull) | We need to decide how long the beta testing period should last. (Bull) | ||
- | |||
Critical items to be fixed. (Spacechicken) | Critical items to be fixed. (Spacechicken) | ||
Line 25: | Line 24: | ||
Edu - External trigger for driving scripts from external programs (worldwind://) (ah) | Edu - External trigger for driving scripts from external programs (worldwind://) (ah) | ||
+ | |||
+ | Tech - Get the CPU usage down | ||
+ | |||
+ | dpatton: | ||
+ | <ol> | ||
+ | <li>Introduction | ||
+ | <ul> | ||
+ | <li>identify "moderator"(jessi?), who | ||
+ | decides when to move on to next Agenda topic</li> | ||
+ | <li>provide URL to Agenda on Wiki</li> | ||
+ | <li>update Agenda with last-minute ideas</li> | ||
+ | </ul></li> | ||
+ | |||
+ | <li>1.3.1 release | ||
+ | <ul> | ||
+ | <li>how/when to release it</li> | ||
+ | </ul></li> | ||
+ | |||
+ | <li>NLT servers | ||
+ | <ul> | ||
+ | <li>status update</li> | ||
+ | <li>timing of "complete data" re next | ||
+ | release after 1.3.1</li> | ||
+ | </ul></li> | ||
+ | |||
+ | <li>1.3.2+ release | ||
+ | <ul> | ||
+ | <li>when/what</li> | ||
+ | </ul></li> | ||
+ | |||
+ | <li>roadmap | ||
+ | <ul> | ||
+ | <li>for future WW releases / ports</li> | ||
+ | <li>for data updates</li> | ||
+ | <li>generally: communication between NLT and community - I would like for the OS team to be kept up to date on what the NLT team is doing (this is fine when jessi is around). (Bull) - Schedule regular meetings. (Bull)</li> | ||
+ | </ul></li> | ||
+ | </ol> | ||
+ | |||
+ | ==ShockFire's Comments== | ||
+ | |||
+ | Excerpts of 2005-03-19 discussion | ||
+ | |||
+ | 04:20 < ShockFire> I'll give my comments on the meeting which I missed yesterday in a few minutes, for which I am very sorry | ||
+ | 04:21 < ShockFire> I read the full log | ||
+ | 04:26 < ShockFire> ok, here goes, I'll start with your comments nhv, after which I'll address the topics discussed yesterday | ||
+ | 04:27 < ShockFire> "< nhv> 3) me thinks that DirectX is here to stay and NLT is not interested in using OpenGL" | ||
+ | 04:27 < ShockFire> I think that's the main point behind the whole porting story | ||
+ | 04:27 < ShockFire> NLT has limited funds, and feel comfortable with C#/DX, and will thus stick with it | ||
+ | 04:28 < ShockFire> I'm not really into the whole porting thing, but here's what I think would be best for both sides (NLT and porters (since NLT | ||
+ | will support porting, but unlikely help code the port themselves)) | ||
+ | 04:29 < ShockFire> we have base code, in C#, that will be used for all platforms | ||
+ | 04:29 < ShockFire> this base code will call a rendering engine | ||
+ | 04:30 < ShockFire> this engine will be platform specific: DX for windows, (maybe) OGL for linux or even mac | ||
+ | 04:30 < ShockFire> the porters would be coding the rendering engine, not recoding the entire app | ||
+ | 04:31 < ShockFire> also I think it's very unlikely NLT will switch to OGL, even when it's proven to work for WW | ||
+ | 04:31 < ShockFire> maybe we'll use OGL for all the platforms in a far future, but I don't see it coming soon | ||
+ | 04:31 < ShockFire> "< nhv> 4) That WWs stated target audience is school age students" | ||
+ | 04:32 < ShockFire> I've mainly kept this in mind whenever I have to make WW decisions | ||
+ | 04:32 < ShockFire> when mashi asks me "do we want that black or white?" I don't think "I want it black" but "the users (kids) would probably like | ||
+ | white" | ||
+ | 04:33 < ShockFire> I know, but since NLT will stick with DX for now, it's less work than porting DX to linux :) | ||
+ | 04:33 < nhv> mashi not to bad if there is a high level published API that is adhered to by all | ||
+ | 04:33 < ShockFire> and this is just what I think and suspect | ||
+ | 04:34 < ShockFire> this is in no way a -rule- that anyone should follow | ||
+ | 04:34 < ShockFire> ok, any questions before I move onto the main meeting stuff? | ||
+ | 04:36 < ShockFire> I'm going to skip the funding part because I don't think I have anything to say about that (however I do think that we will be | ||
+ | doing crazy things from time to time simply to keep going) | ||
+ | 04:37 < ShockFire> -- 1.3.1 release -- | ||
+ | 04:37 < ShockFire> what I missed from the meeting was an actual release date | ||
+ | 04:37 < ShockFire> it seems however that we need to get our stuff together by monday | ||
+ | 04:38 < ShockFire> patch/full is fine | ||
+ | 04:38 < ShockFire> don't label it as a beta, because I don't think it's a beta | ||
+ | 04:38 < ShockFire> which brings us to the naming convention stuff:) | ||
+ | 04:39 < ShockFire> yep, that's mainly what I meant by "crazy things" in "(however I do think that we will be doing crazy things from time to time | ||
+ | simply to keep going)" | ||
+ | 04:39 < ShockFire> it's bad, but I see why we do it this way | ||
+ | 04:40 < nhv> would be *very* nice if these *crazy* things were talked about a bit not in details but we *need* a release by XXX | ||
+ | 04:40 < nhv> could make things much smoother | ||
+ | 04:41 < ShockFire> yeah I'd like a to have a deadline for every releae | ||
+ | 04:41 < ShockFire> it doesn't have to be perfect, but it WILL help | ||
+ | 04:41 < ShockFire> I don't nescesarily need/want a list of change we need for that specific version though, just a date will do | ||
+ | 04:42 < nhv> exactly maybe NLT should have a web accessable project management timeline page | ||
+ | 04:43 < nhv> maybe WW should .... | ||
+ | 04:44 < ShockFire> my vision on the naming convention is this: first we had the 1.3 release, then people will do commits to CVS, which is when we | ||
+ | have 1.3.1 in alpha state, then the deadline-day will come which means we do not add more features - call it a beta - and do | ||
+ | incremental releases to IRC (1.3.1 beta 1, 1.3.1 beta 2, etc) | ||
+ | 04:45 < nhv> that works | ||
+ | 04:45 < ShockFire> after the 1.3.1 release, we'll start the same thing, but this time call it 1.3.2 | ||
+ | 04:45 < nhv> or 1.2.1a1 a2 b1 b2 .... | ||
+ | 04:46 < ShockFire> yeah but when you have alphas it's hard to keep a numbering scheme because people will commit when they like to | ||
+ | 04:46 < nhv> whatever works is fine | ||
+ | 04:46 < ShockFire> also we don't want to go making a new installer for a new alpha each day | ||
+ | 04:47 < nhv> it would be nice to have a mechanism in place for bug fixes to releases | ||
+ | 04:47 < ShockFire> of course when you need to send the compiled source during alpha state to someone, you are free to give it a number you can come | ||
+ | up with | ||
+ | 04:48 < ShockFire> -- NLT<>community communication -- | ||
+ | 04:49 < ShockFire> the main problem is that we want to decrease the chance that two people are working on the same thing, because this is/will be | ||
+ | our main productivity killer | ||
+ | 04:50 < nhv> or ... want to insure that when several people are working on the same thing that they communicate with eachother | ||
+ | 04:50 < ShockFire> I think Chris needs to give some more details about which parts of the code he's working on, even if he can't fully explain | ||
+ | what's going to change | ||
+ | 04:50 < ShockFire> also the community needs to do the same by organising their work in a central place | ||
+ | 04:51 < ShockFire> about the way we communicate: | ||
+ | 04:51 < nhv> this is where working in a CVS branch that gets merged in later *really* helps | ||
+ | 04:51 < ShockFire> - discussions and meetings are nice for IRC (and maybe some other form of IM) | ||
+ | 04:52 < ShockFire> - I do not care whether we submit bugs to the wiki/SF/custom page/write on chicken eggs and send by airmail | ||
+ | 04:52 < ShockFire> though the eggs method has proven to be problematic :P | ||
+ | 04:53 < ShockFire> - I think we need to seperate different 'stages' to get things organized | ||
+ | 04:54 < ShockFire> - for each stage we need a clear, simple and public document that describes what to do | ||
+ | 04:54 < ShockFire> here are some examples: | ||
+ | 04:54 < ShockFire> 1. a user finds a bug | ||
+ | 04:54 < ShockFire> this user will go the a document for input | ||
+ | 04:55 < ShockFire> the user will go to the part that reads "What should I do when I find a bug in NWW?" | ||
+ | 04:55 < ShockFire> the user will then follow the simple instructions below that question | ||
+ | 04:55 < ShockFire> 2. a developer will try to fix a bug | ||
+ | 04:56 < ShockFire> this developer will go the a document for code-changes | ||
+ | 04:56 < ShockFire> the developer will go to the part that reads "What should I do when I want to fix a user-reported bug in NWW?" | ||
+ | 04:56 < ShockFire> (follow instructions) | ||
+ | 04:57 < ShockFire> I do not care whether these instructions say you have to use the SF bug list or the wiki, either one should work | ||
+ | 04:57 < nhv> bug history needs to be in *one* place | ||
+ | 04:58 < nhv> collective bug histories | ||
+ | 04:58 < ShockFire> of course there should also be guides like this for requesting features and stuff like that | ||
+ | 04:58 < ShockFire> yep, whichever we choose, we pick one and stick with that (don't go posting bugs on the wiki when the guide tells you to use SF) | ||
+ | 04:59 < ShockFire> my explanation is a bit simplified and stupidified, but I think this is what we need in general, a list of guides that tell you | ||
+ | what to do to automagically get things organized | ||
+ | 05:02 < mashi> I agree.. keep them in one place. SourceForge worked pretty good imho, the wiki a bit more chaotic? | ||
+ | 05:02 < ShockFire> yeah I think SF has a slight advantage | ||
+ | 05:03 < ShockFire> -- 1.3.2 -- | ||
+ | 05:03 < ShockFire> I don't really have special wishes for 1.3.2 | ||
+ | 05:03 < ShockFire> I'll try to do some good 1.3.1 testing on the school PCs, and translate that into possible changes we need in 1.3.2 | ||
+ | 05:04 < nhv> or if we move off of SF to ues SVN there are some other tools available such as http://projects.edgewall.com/trac/ | ||
+ | 05:04 < ShockFire> SF will support SVN someday | ||
+ | 05:04 < ShockFire> they're working on it | ||
+ | 05:05 < ShockFire> just don't have a date set for it, but it'll be there | ||
+ | 05:05 < ShockFire> I already did naming convention and ports | ||
+ | 05:06 < ShockFire> I wouldn't mind a roadmap, but I know this can literally change on the NLT side within a day | ||
+ | |||
+ | 05:47 < TheBean> UShockFireU Simple communication was one of the points of the meeting last night.....the concensus being a single source was needed | ||
+ | for people to check | ||
+ | 05:48 < TheBean> It seemed to be agreed that a Wiki page with tables etc would be the best way.....the Wiki has RSS feeds....easy to check....blah | ||
+ | blah | ||
+ | 05:51 < ShockFire> yeah but nobody made any definitive decision | ||
+ | [[Category:Dev Documentation]] | ||
+ | [[Category:Meetings]] |
Current revision
On IRC #worldwind-dev, irc.freenode.net, 2300 UTC, 2005-03-18.
Transcript: http://worldwind.arc.nasa.gov/dev/community-meeting-2005-03-18.txt
[edit] Agenda
We need to decide how long the beta testing period should last. (Bull)
Critical items to be fixed. (Spacechicken)
Critical items to be added. (SC)
Non-critical items to be added. (SC)
User docs (SC)
Developer docs. (SC)
Buzz- Scraping RSS feeds for geocodes, displaying as icons, clickable. (ah)
Edu -Playback of video/pictures on billboard(s) for narration, supplemental materials. Audio playback as well. (ah)
Edu - Use above feature to build some educational content. (ah)
Edu - External trigger for driving scripts from external programs (worldwind://) (ah)
Tech - Get the CPU usage down
dpatton:
- Introduction
- identify "moderator"(jessi?), who decides when to move on to next Agenda topic
- provide URL to Agenda on Wiki
- update Agenda with last-minute ideas
- 1.3.1 release
- how/when to release it
- NLT servers
- status update
- timing of "complete data" re next release after 1.3.1
- 1.3.2+ release
- when/what
- roadmap
- for future WW releases / ports
- for data updates
- generally: communication between NLT and community - I would like for the OS team to be kept up to date on what the NLT team is doing (this is fine when jessi is around). (Bull) - Schedule regular meetings. (Bull)
[edit] ShockFire's Comments
Excerpts of 2005-03-19 discussion
04:20 < ShockFire> I'll give my comments on the meeting which I missed yesterday in a few minutes, for which I am very sorry 04:21 < ShockFire> I read the full log 04:26 < ShockFire> ok, here goes, I'll start with your comments nhv, after which I'll address the topics discussed yesterday 04:27 < ShockFire> "< nhv> 3) me thinks that DirectX is here to stay and NLT is not interested in using OpenGL" 04:27 < ShockFire> I think that's the main point behind the whole porting story 04:27 < ShockFire> NLT has limited funds, and feel comfortable with C#/DX, and will thus stick with it 04:28 < ShockFire> I'm not really into the whole porting thing, but here's what I think would be best for both sides (NLT and porters (since NLT will support porting, but unlikely help code the port themselves)) 04:29 < ShockFire> we have base code, in C#, that will be used for all platforms 04:29 < ShockFire> this base code will call a rendering engine 04:30 < ShockFire> this engine will be platform specific: DX for windows, (maybe) OGL for linux or even mac 04:30 < ShockFire> the porters would be coding the rendering engine, not recoding the entire app 04:31 < ShockFire> also I think it's very unlikely NLT will switch to OGL, even when it's proven to work for WW 04:31 < ShockFire> maybe we'll use OGL for all the platforms in a far future, but I don't see it coming soon 04:31 < ShockFire> "< nhv> 4) That WWs stated target audience is school age students" 04:32 < ShockFire> I've mainly kept this in mind whenever I have to make WW decisions 04:32 < ShockFire> when mashi asks me "do we want that black or white?" I don't think "I want it black" but "the users (kids) would probably like white" 04:33 < ShockFire> I know, but since NLT will stick with DX for now, it's less work than porting DX to linux :) 04:33 < nhv> mashi not to bad if there is a high level published API that is adhered to by all 04:33 < ShockFire> and this is just what I think and suspect 04:34 < ShockFire> this is in no way a -rule- that anyone should follow 04:34 < ShockFire> ok, any questions before I move onto the main meeting stuff? 04:36 < ShockFire> I'm going to skip the funding part because I don't think I have anything to say about that (however I do think that we will be doing crazy things from time to time simply to keep going) 04:37 < ShockFire> -- 1.3.1 release -- 04:37 < ShockFire> what I missed from the meeting was an actual release date 04:37 < ShockFire> it seems however that we need to get our stuff together by monday 04:38 < ShockFire> patch/full is fine 04:38 < ShockFire> don't label it as a beta, because I don't think it's a beta 04:38 < ShockFire> which brings us to the naming convention stuff:) 04:39 < ShockFire> yep, that's mainly what I meant by "crazy things" in "(however I do think that we will be doing crazy things from time to time simply to keep going)" 04:39 < ShockFire> it's bad, but I see why we do it this way 04:40 < nhv> would be *very* nice if these *crazy* things were talked about a bit not in details but we *need* a release by XXX 04:40 < nhv> could make things much smoother 04:41 < ShockFire> yeah I'd like a to have a deadline for every releae 04:41 < ShockFire> it doesn't have to be perfect, but it WILL help 04:41 < ShockFire> I don't nescesarily need/want a list of change we need for that specific version though, just a date will do 04:42 < nhv> exactly maybe NLT should have a web accessable project management timeline page 04:43 < nhv> maybe WW should .... 04:44 < ShockFire> my vision on the naming convention is this: first we had the 1.3 release, then people will do commits to CVS, which is when we have 1.3.1 in alpha state, then the deadline-day will come which means we do not add more features - call it a beta - and do incremental releases to IRC (1.3.1 beta 1, 1.3.1 beta 2, etc) 04:45 < nhv> that works 04:45 < ShockFire> after the 1.3.1 release, we'll start the same thing, but this time call it 1.3.2 04:45 < nhv> or 1.2.1a1 a2 b1 b2 .... 04:46 < ShockFire> yeah but when you have alphas it's hard to keep a numbering scheme because people will commit when they like to 04:46 < nhv> whatever works is fine 04:46 < ShockFire> also we don't want to go making a new installer for a new alpha each day 04:47 < nhv> it would be nice to have a mechanism in place for bug fixes to releases 04:47 < ShockFire> of course when you need to send the compiled source during alpha state to someone, you are free to give it a number you can come up with 04:48 < ShockFire> -- NLT<>community communication -- 04:49 < ShockFire> the main problem is that we want to decrease the chance that two people are working on the same thing, because this is/will be our main productivity killer 04:50 < nhv> or ... want to insure that when several people are working on the same thing that they communicate with eachother 04:50 < ShockFire> I think Chris needs to give some more details about which parts of the code he's working on, even if he can't fully explain what's going to change 04:50 < ShockFire> also the community needs to do the same by organising their work in a central place 04:51 < ShockFire> about the way we communicate: 04:51 < nhv> this is where working in a CVS branch that gets merged in later *really* helps 04:51 < ShockFire> - discussions and meetings are nice for IRC (and maybe some other form of IM) 04:52 < ShockFire> - I do not care whether we submit bugs to the wiki/SF/custom page/write on chicken eggs and send by airmail 04:52 < ShockFire> though the eggs method has proven to be problematic :P 04:53 < ShockFire> - I think we need to seperate different 'stages' to get things organized 04:54 < ShockFire> - for each stage we need a clear, simple and public document that describes what to do 04:54 < ShockFire> here are some examples: 04:54 < ShockFire> 1. a user finds a bug 04:54 < ShockFire> this user will go the a document for input 04:55 < ShockFire> the user will go to the part that reads "What should I do when I find a bug in NWW?" 04:55 < ShockFire> the user will then follow the simple instructions below that question 04:55 < ShockFire> 2. a developer will try to fix a bug 04:56 < ShockFire> this developer will go the a document for code-changes 04:56 < ShockFire> the developer will go to the part that reads "What should I do when I want to fix a user-reported bug in NWW?" 04:56 < ShockFire> (follow instructions) 04:57 < ShockFire> I do not care whether these instructions say you have to use the SF bug list or the wiki, either one should work 04:57 < nhv> bug history needs to be in *one* place 04:58 < nhv> collective bug histories 04:58 < ShockFire> of course there should also be guides like this for requesting features and stuff like that 04:58 < ShockFire> yep, whichever we choose, we pick one and stick with that (don't go posting bugs on the wiki when the guide tells you to use SF) 04:59 < ShockFire> my explanation is a bit simplified and stupidified, but I think this is what we need in general, a list of guides that tell you what to do to automagically get things organized 05:02 < mashi> I agree.. keep them in one place. SourceForge worked pretty good imho, the wiki a bit more chaotic? 05:02 < ShockFire> yeah I think SF has a slight advantage 05:03 < ShockFire> -- 1.3.2 -- 05:03 < ShockFire> I don't really have special wishes for 1.3.2 05:03 < ShockFire> I'll try to do some good 1.3.1 testing on the school PCs, and translate that into possible changes we need in 1.3.2 05:04 < nhv> or if we move off of SF to ues SVN there are some other tools available such as http://projects.edgewall.com/trac/ 05:04 < ShockFire> SF will support SVN someday 05:04 < ShockFire> they're working on it 05:05 < ShockFire> just don't have a date set for it, but it'll be there 05:05 < ShockFire> I already did naming convention and ports 05:06 < ShockFire> I wouldn't mind a roadmap, but I know this can literally change on the NLT side within a day
05:47 < TheBean> UShockFireU Simple communication was one of the points of the meeting last night.....the concensus being a single source was needed for people to check 05:48 < TheBean> It seemed to be agreed that a Wiki page with tables etc would be the best way.....the Wiki has RSS feeds....easy to check....blah blah 05:51 < ShockFire> yeah but nobody made any definitive decision