Community Meeting 2005-03-18

From World Wind Wiki

(Difference between revisions)
Jump to: navigation, search
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:

  1. 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
  2. 1.3.1 release
    • how/when to release it
  3. NLT servers
    • status update
    • timing of "complete data" re next release after 1.3.1
  4. 1.3.2+ release
    • when/what
  5. 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
Personal tools