[14:01] <Mitchell> Well, it's just about 2pm, so it's time to get started on the official session
[14:01] <Mitchell> Ilan:  it was both.  
[14:01] <Mitchell> The change of mindset from a "traditional" management structure to a hybrid is not automatic
[14:01] <Mitchell> And giving up control is hard for almost all of us, so it's not surprising that a management structure would have trouble doing so
[14:02] <luther> Has mozilla become less bureaucratic over the years?
[14:02] <Mitchell> Well, I'm not sure how to answer "bureaucratic"
[14:03] <luther> Highly hierarchical.
[14:03] <Mitchell> It's definitely less controlled by a management change. Key decisions are made by mozilla.org staff for the project, not by an employer
[14:03] <Mitchell> But since there are so many people and there are numerous companies involved, mozilla does have more "process" than many projects
[14:03] <Mitchell> Hierarchical:  can you be more specific?
[14:04] <Mitchell> (I'm figuring this related to OSAF community, which is part of the Status Update, and so can fit into the official discussion)
[14:04] <luther> Orders come down from highest level. Feedback goes only to the next level up.
[14:05] <Mitchell> Hmm, I'd like to discuss.  But perhaps we should talk about the Update first, and come back to this?
[14:05] <luther> Okay.
[14:05] <Ilan> Isn't it only 1pm over there?
[14:06] <Mitchell> It's 2:07.  For me at least.
[14:06] <ducky> Ilan -- where are you?  (Just curious about how well distributed our fan base is)
[14:06] <Mitchell> The update talks a bit about the plan to do "milestones."  These will be very low overhead, meaning OSAF won't plan on documents, or much information about the milestones
[14:06] <Ilan> I'm in Durham, North Carolina.
[14:07] <Mitchell> I'm not even sure what we'll do about bugs for these.
[14:07] <Mitchell> I'm wondering what people think of this.
[14:07] <ducky> (low overhead = low overhead checkpoints/releases)
[14:07] <Mitchell> Our current thinking is that we wouldn't provide any docs, release notes, or what's new.
[14:08] jonathan (~jprusky@12-236-204-253.client.attbi.com) joined #chandler.
[14:08] <mdubinko> what's the difference between a milestone and a snapshot?
[14:08] <Mitchell> If you are interested you can query the bugzilla bug for the milestone and find out what tasks were associated with it
[14:08] <Ilan> So, what stuff will break our parcels in 0.2? :)
[14:08] <jed> mdubinko:  There is not much of a difference.  Just a renaming and clarifying of what we are trying to achieve
[14:08] <mdubinko> good
[14:08] Topic changed on #chandler by Mitchell!~chatzill@cpe-24-221-171-140.ca.sprintbbd.net: "Status Update 6"
[14:09] <Mitchell> mdubinko:  right now we are using snapshot to describe the builds morgen makes when *non-Chandler* code has changed
[14:09] <chao> Ilan: the viewer parcel framework functionality will be greatly expanded. 
[14:09] <Mitchell> The snapshots pick up whatever changes in chandler code have occured, but this is not the trigger point.
[14:10] <chao> you can assume 0.1 parcels will not work in 0.2 without extra coding work
[14:10] <Mitchell> Morgen's thinking was that this would let developers keep up with changes in the non-chandler code (wxWindows, wxPython) easily
[14:10] <Ilan> Will the XRC formats be changed for 0.2 as well?
[14:11] <Mitchell> I like the term snapshots and think it might be better for the milestones.  That's because the "milestones" are calendar based.  The builds happen on a certain day, and what's there is there.
[14:11] <Mitchell> But snapshot has been used for something different, so there we are.
[14:11] <morgen> snapshots are just builds I do whenever interesting changes happen to the C code, and they don't go through any real testing
[14:12] <chao> Ilan: will XRC itself change? I'm not sure. It too is evolving but is more stable than Chandler :)
[14:12] <morgen> I am moving toward a tinderbox-based continuous build cycle, with automated unit tests; milestones will also go through smoketests 
[14:13] <Mitchell> Morgen:  I'm guessing the smoketests will be very basic?  
[14:14] <morgen> yeah, probably a minute of user-level tasks including "add a contact", "add an event", ...
[14:14] <morgen> We could even have the smoke test script built-in to a menu ?
[14:15] <luther> morgen: like mozilla test builds?
[14:15] <morgen> yep
[14:15] <Mitchell> do we have a goal for how long it would take for a user to go through the smoketests? 15 minues? 30?
[14:15] <morgen> oh no, not that long, because we want to get developers in the habit of doing smoke tests before checkins
[14:15] <Mitchell> I think the Mozilla world has 2 level of user tests:  smoketests to see if the tree is ready to open for more checkins, and a much fuller set of functional tests
[14:16] <morgen> Ok
[14:16] <Mitchell> ah, so smoketests are very brief
[14:16] <morgen> That makes sense
[14:16] <morgen> You want to make the pre-checkin process as short as possible so that engineers don't put off checking in code
[14:17] <Mitchell> I think the standard for Mozilla smoketests is that if something is either completely broken, or blocks the testing of other major functionality it must be fixed
[14:17] <dh> how are smoketests different than unit tests?
[14:18] <morgen> unit tests are automated and look at the functionality of a specific code module
[14:18] <luther> Unit tests are programmatic; smoketests are scripts of user actions.
[14:18] <morgen> right
[14:19] <morgen> does mozilla have a different term for the more in-depth, user-run tests?
[14:19] <dh> so, checkins require both unit- and smoke- tests to pass?
[14:19] <morgen> ideally
[14:19] <Mitchell> I think the Mozilla world uses something like "full functional tests."  I'll go poke around
[14:21] <Mitchell> If anyone has questions to ask, now is a good time
[14:22] <Ilan> What specific changes are planned viewer parcel framework?
[14:22] <Mitchell> chao?
[14:23] <chao> The candidates are listed on a spreadsheet on the wiki. 
[14:23] <chao> They include 1) gathering feedback from community to improve on the current framework
[14:24] <chao> 2) allow end-user creation of a 'project' view, listing mix-items of says, events, email and contacts using what we are formerly calling the "super widget", but now referring to as a "document architecture"
[14:24] <chao> 3) item detail view
[14:24] <chao> 4) support for multiple views
[14:25] <chao> Jed adds 5) action (aka short-cut bar) bar and associated hooks for view parcels to access it
[14:26] <Ilan> How is the action-bar different from a toolbar?
[14:26] <jonathan> Chao - how about multiple windows in addition to multiple views?
[14:26] <mdubinko> Does the action bar include "agents"?
[14:26] <chao> jonathan: multiple windows will probably be supported, esp. for detail views
[14:27] <chao> Ilan: action bar is a tool bar that stores user or default shortcuts
[14:27] <Ilan> ok
[14:27] <chao> mdubinko: agents will have their own toolbar, but could also have shortcuts on the action bar
[14:28] <chao> The spreadsheet I referred to is attached to this wiki page: http://wiki.osafoundation.org/bin/view/Jungle/DotTwoReleaseIssueSummary
[14:29] <Mitchell> what's the timeframe for prioritizing candidates?
[14:29] <chao> we should have a list of fine-grained tasks associated to these features by next week. Michael gets back the following week and we hope to thresh out a first draft schedule in that week
[14:30] <chao> The first draft schedule will make a serious effort in pruning the candidates listed on the spreadsheet
[14:31] <chao> ...based on the goals you higlighted in the status update
[14:32] <Mitchell> Are the candidates all viewed as important enough that if they are not 0.2 material, then they will be 0.3?  or might some be pushed further out?
[14:33] Action: nick checks in 
[14:33] <chao> at this point, we think they are important enough. We will need to reevaluate 0.3 candidates, probably 4-6 weeks before we ship 0.2...
[14:33] <Mitchell> Nick:  as in code, or as in saying hello?
[14:33] <nick> saying hello.. :-) 
[14:33] <mdubinko> Are there any parcels that OSAF would like to include in the "hub", but don't forsee having the resources to do it themselves?
[14:34] <chao> ... we are trying to plan for the next release ahead of releasing the current release, unlike 0.1
[14:34] <chao> mdubinko: what do you mean by "hub"?
[14:34] <mdubinko> basically 'ships with a milestone or release'
[14:35] <Mitchell> chao:  this is my wording from the community docs I posted
[14:35] Pito (~junk@h0001032b70d7.ne.client2.attbi.com) left irc: 
[14:35] <Mitchell> now i feel better, knowing that even 
[14:35] <nick> there was something on the wiki about wanting to ship a third-party parcel... 
[14:35] <Mitchell> Chao can't keep up with everything
[14:35] <Mitchell> I defined "hub" as part of what OSAF ships as the foundation
[14:36] <Mitchell> and "spoke" as development build on top of OSAF releases
[14:36] <Mitchell> not the best terms, but i needed something
[14:36] <chao> mdubinko: there is a parcel we are debating internally as to how much effort to put in: that is Instant Message
[14:36] <chao> Messaging, I mean. IM
[14:36] <ducky> mdubinko: I am concerned about the email parcel not having adequate resources.
[14:36] <nick> I think messaging is a component that should be part of a more-mature Chandler 
[14:36] <Mitchell> mdubinko:  it's also possible that someone will develop a parcel that we hadn't thought of but is so great we know we should ship it
[14:37] <Mitchell> like Chao's RSS reader.  Another example could be a spell-checker
[14:37] <ducky> mdubinko: I'm starting (along with a volunteer) to evaluate various protocol libraries (e.g. POP, IMAP) so we have to do less work on email.
[14:37] Action: nick wishes the outliner worked 
[14:37] <chao> the universities are going to be one of our first core audience, so learning or course ware parcels will be very useful
[14:38] Action: Mitchell wishes all of chandler was here already
[14:38] <ducky> Email protocols are a solved problem, we shouldn't have to solve them again.
[14:38] Action: ducky laughs
[14:38] <Mitchell> mdubinko:  since you seem to have read the community docs, did they make sense to you?
[14:38] Empty (~MichaelT@63.90.156.153) left irc: Client Exit: i'm history
[14:39] <Mitchell> the URL for the community info is http://wiki.osafoundation.org/bin/view/Chandler/TopicOutline20030604
[14:39] <ducky> mdubinko: echoing Chao, it would be cool if there were a parcel for keeping track of grades >> and sharing the grades with the student that the grades belong to <<
[14:39] <ducky> (though that of course depends heavily on security)
[14:40] <nick> once again...how are you handling the client/server problem?  Is there going to be a chandler server? 
[14:40] <mdubinko> the community docs are very readable
[14:40] <Mitchell> mdubinko.  Glad to hear it :-)  I'm especially interested in the docs on what developers need to be effective
[14:41] <mdubinko> now, pre-chandler, a 'keep track of grades' application would be good material to implement in say, Ecco Pro, or Zoot (or Agenda, though I haven't used it)
[14:41] Action: nick thinks there needs to be more doc on data serialization 
[14:41] <nick> and not to get off on real development issues, but... 
[14:41] <nick> can anybody explain to me why parcel's are initialized each time the user chooses it, and not just once? 
[14:42] <nick> s/parcel\'s/parcels 
[14:42] <ducky> nick: that sounds like a Jed question
[14:42] <mdubinko> I'd like for there to be a more, well, EccoPro-like (or Zoot, Agenda, ...) parcel
[14:42] <Mitchell> Jed?
[14:43] <ducky> mdubinko: the SuperWidget will start to enable EccoPro-ish features.
[14:43] <ducky> as for the client/server problem, it's a hard problem that has a LOT of thought and energy that has gone into it.  Are you sure you want to hear it all right now?
[14:44] <ducky> (Chao, Pieter, is there a doc on the Web that would cover the client/server issue?)
[14:44] <jed> nick:  That is something that may change
[14:45] <nick> jed: that would be nice...it's really expensive for the outliner to keep getting initialized 
[14:45] <jed> I agree
[14:45] <nick> and makes extra work for me, since if it just hung around, I wouldn't have to worry about temporary data storage 
[14:46] <jed> Things will have to be reinstantiated on each run of the app, but hopefully they won't have to be with each navigation
[14:46] <nick> and the OnInitData method that I think ducky mentioned on the wiki doesn't exist in 0.1 
[14:46] <nick> jed: yeah, that's what I'm looking for 
[14:46] <nick> also, what do people generally think about parcels written in C++? 
[14:47] <jed> There may be certain parcels that would want that behavior (if, for example, the memory of keeping them around is too high and they aren't expected to be revisited often), but I expect that to be the exception rather than the rule
[14:47] <ducky> hmmmm John changed some things and maybe I didn't update the docs to reflect the change... either that or you're using an old version... lemme go look
[14:47] <chao> A big unsolved problem with c++ code, is the multi-platform code sharing aspect. 
[14:47] <jed> ducky:  I believe it is the latter
[14:48] <Ilan> ducky: what mail protocol libraries are you evaluating besides the standard python IMAP & POP?
[14:48] <jed> 0.1 does not have OnInitData, it only exists in the head of CVS
[14:48] <nick> chao: where's the problem? 
[14:48] <nick> ok, I should move to CVS then, I suppose 
[14:48] <chao> nick: We envision that Chandler will be used to share parcels on a peer-to-peer basis with other chandler clients
[14:48] <nick> ah...interesting.. 
[14:48] <jed> nick:  Or perhaps to a snapshot
[14:48] <nick> jed: well, but something more recent than 0.1.. :-0 
[14:49] <nick> s/0/\) 
[14:49] <ducky> Ilan -- I've got a page at http://wiki.osafoundation.org/bin/view/Jungle/ExternalEmailLibraries
[14:49] <nick> hrmm 
[14:49] <jed> Yes.  I can get the exact date if you wish, but you might as well go with the most recent
[14:49] <jed> Hopefully we haven't broken anything lately :)
[14:49] <nick> chao: well...hrmm 
[14:49] <Mitchell> nick:  our first milestone is due on June 10, this is another possibility
[14:49] <nick> I'm implementing a part of the outliner in C++ 
[14:50] <ducky> Ilan, that's just a very primitive start.  There are lots more, some of which I even know about but haven't gotten onto the page.  If you know of more, please add them.
[14:50] <nick> the parcel itself is in python, but I needed to create a new wx widget, and I had to do that in C++ 
[14:50] <jed> Mitchell:  just a small correction, the first milestone is June 17th
[14:51] <chao> nick: I would suggest you contribute the code to the wxWindows effort or maybe the wxPython effort (whichever makes sense). c++ code there wouldn't be the problem ...
[14:51] <jed> We shifted dates so that Michael would be around for the first milestone
[14:51] <chao> because it'll be in every chandler client (at least the latest ones)
[14:51] <morgen> Snapshots are currently here...   http://downloads.osafoundation.org/chandler/snapshots/
[14:51] <ducky> Ilan -- I don't have details, but I think I remember reading somebody mumbling something on the spambayes list about how the core python email libs weren't very good.  (<- That is the extent of my memory, but why I think we should look at other libs as well.)
[14:51] <nick> chao: yeah, I just didn't want to wait that long before shipping a working parcel... 
[14:51] <Mitchell> oh, that's changed then.  I should update the Status report.  I'll go do that now.
[14:52] dh (~chatzill@193.120.94.82) left #chandler.
[14:52] <jed> The current dates for milestones are found at http://wiki.osafoundation.org/bin/view/Jungle/DevProcessProposal
[14:53] <ducky> Ilan -- do you know anything useful about email libs that you could share with me?
[14:53] <chao> nick: what kind of outliner are you working on?
[14:54] <nick> chao: like OmniOutliner, if you've seen it 
[14:54] <nick> you know, an Outliner.. :-) 
[14:54] <nick> items, child items, checkboxes, hoisting, etc. 
[14:55] <Ilan> ducky: I was more curious as to what could be of use in other POP/IMAP libraries that weren't already in the python libraries. 
[14:56] <ducky> Ilan.  Ah.  The biggies are POP, SMTP, IMAP, MIME, message parsers, authentication libs, encryption libs.  There are also some aux libs like spellcheckers that would be useful.
[14:57] <chao> nick: John Anderson may be working on something similar, which has names like the Super Widget, Tree Control Widget.
[14:57] <chao> Maybe you two can collaborate?
[14:58] <Ilan> Sure.
[14:58] <nick> ok...superwidget as explained to me yesterday didn't really sound similar, but I could be wrong 
[14:59] <nick> my wxGenericOutlineCtrl isn't tied to chandler in the sense that it does not handle data serialization, etc. 
[14:59] <Mitchell> as I understand it, the superwidget is still being conceptually developed.  I don't think John believes he could implement it yet
[14:59] <Mitchell> that may be why it sounded different before. 
[14:59] <chao> nick: superwidget is evolving... it's bifurcated to a document layout architecture and a set of widgets to populate the document. The outline widget is a key widget in this new thinking.
[14:59] <ducky> *laugh*  I have a sense that everybody has a slightly different idea of the superwidget -- so you might have been feeling the legs of the elephant while someone else was feeling the tail...
[15:00] <mdubinko> is there any way, maybe on the mail list, we could help flesh out the super widget?
[15:00] <Mitchell> Also, it's about 3pm.  So last call for questions before I end the "official" session
[15:00] <nick> things would be clearer to me if someone had like a UML diagram of the superwidget.... 
[15:00] <luther> And I thought the super widget was for shredding salad...
[15:00] <ducky> luther: and a desert topping... ;-)
[15:00] <nick> hrmm...almost 6 then 
[15:00] Action: nick looks at the clock 
[15:00] <Mitchell> yes, buy it on late night TV
[15:00] <chao> nick: we too want to havae a generic outline widget but to make sure it works and plays well in our emerging document architecture world view
[15:02] <jonathan> mitchell - do you plan to have (or do you have) a page on the wiki that will contain transcripts of IRC sessions?
[15:02] <nick> that would be a good idea as well... 
[15:02] <Mitchell> Yes, we do.  Jurgen has a bug for this.  He has two transcripts up now.  I don't know why he's behind on the others.  I will bug him.
[15:02] <Ilan> I haven't checked this out yet, but has anyone made a Jungle.WxWindows columned-tree widget? Sort of like a threaded listview?
[15:02] <jonathan> URL?
[15:03] <Mitchell> http://wiki.osafoundation.org/bin/view/Main/PastIRCSesssions
[15:03] <nick> Ilan: the outline view will support that 
[15:03] <jonathan> thanks
[15:03] <luther> The osafoundation server is currently inaccesible from my corner of the net.
[15:03] <amblin> same here
[15:03] <Mitchell> There's also a bug in bugzilla for jurgen on this.  I'll go add a comment that we need thiws
[15:03] <nick> not sure entirely what you mean by threaded listview, but the outline control will have columns 
[15:04] <DaniGro> same here
[15:04] <nick> not here.. :-) 
[15:04] <Mitchell> interesting about the server.  
[15:04] <Ilan> Basically, something you can use to represent threaded e-mail messages.
[15:04] <nick> ilan: so, a treeview with columns.. ;-)  Yeah, that's it... 
[15:04] <Ilan> Do you have a url for it?
[15:04] <jed> Ilan:  There is such a widget in the works
[15:04] <Ilan> jed: in the standard Jungle.WxWindows distro?
[15:05] <jed> It has been entered into the 2.5 wxWIndows branch
[15:05] <nick> hrmm 
[15:05] <ducky> Hmmm, must be a DNS problem w/the wiki.
[15:05] <nick> maybe I should look at that first then 
[15:05] <jed> It's still considered part of the contrib tree
[15:05] <nick> jed: what's it called? 
[15:05] amblin (~youwish@cosmo.itlab.musc.edu) left irc: Remote host closed the connection
[15:05] <nick> because I'm implementing something like it... 
[15:05] <nick> although it's probably still a tree and not an outline, but worth investigating 
[15:05] <Mitchell> OK, past 3pm, so I'm ending the official session.  Everyone welcome to remain.
[15:05] Action: Ilan so that's why the wiki wasn't coming up...
[15:06] <jed> wxTreeListCtrl
[15:06] Nick change: ducky -> ducky_postoffice
[15:06] <Mitchell> Also, note our new "Office Hour" on Tuesdays at 2pm.  We'll try to have a bunch of people around, including Andy and Mitch, to kibbitz