[08:51:53 CDT(-0500)] <heidi_> Justin_o i can help with UIO testing today. i'll grab some tasks
[08:53:15 CDT(-0500)] <Justin_o> heidi_: thanks a lot
[08:53:27 CDT(-0500)] <Justin_o> i'm still updating the Full No Preview test plan
[08:53:38 CDT(-0500)] <Justin_o> but the Fat Panel and with preview should be ready to use
[08:53:51 CDT(-0500)] <Justin_o> please let me know if you see any problems with the test plan
[08:54:01 CDT(-0500)] <heidi_> Justin_o cool i'm going to start with full w preview on mac
[08:54:19 CDT(-0500)] <Justin_o> heidi_: great, thanks
[09:26:39 CDT(-0500)] <Justin_o> jameswy: do you have time to do some UIO testing.. i'm hoping that you can also look over the test plans to make sure they are accurate
[09:27:16 CDT(-0500)] <jameswy> Justin_o: Yep, I'll do at least a couple, in modern browsers.
[09:27:27 CDT(-0500)] <jameswy> I should grab a couple now before someone steals 'em.
[09:28:36 CDT(-0500)] <Justin_o> jameswy: good idea
[09:28:50 CDT(-0500)] <Justin_o> you can do the FF 6 Win 7 ones if you like
[09:28:54 CDT(-0500)] <Justin_o> I think they are still around
[09:29:02 CDT(-0500)] <jameswy> Justin_o: Are there no 10.7 tasks?
[09:30:15 CDT(-0500)] <Justin_o> jameswy: nope
[09:30:23 CDT(-0500)] <Justin_o> not for this release
[09:30:34 CDT(-0500)] <Justin_o> you're welcome to test in it if you like, but there are no specific tasks for it
[09:46:32 CDT(-0500)] <michelled> Justin_o: do you want me to look at Bosmon2's pull request?
[09:46:56 CDT(-0500)] <Justin_o> michelled: yes please
[10:00:45 CDT(-0500)] <Justin_o> michelled, cindyli: just noticed this issue, any ideas http://issues.fluidproject.org/browse/FLUID-4473
[10:01:11 CDT(-0500)] <Justin_o> it does work properly in the UIO Demo with IE 9, and the sakai mock-up demo works properly in FF
[10:01:46 CDT(-0500)] <michelled> maybe another calculation issues?
[10:02:58 CDT(-0500)] <cindyli> Justin_o, michelled, debugging
[10:03:13 CDT(-0500)] <Justin_o> cindyli: thanks
[10:03:17 CDT(-0500)] <cindyli> np
[10:16:43 CDT(-0500)] <jameswy> Justin_o: Are we aware that the line spacing affects checkbox alignment with text in UIO?
[10:17:36 CDT(-0500)] <Justin_o> i'm not sure
[10:17:44 CDT(-0500)] <colinclark> jameswy: When you've got time and it's not a distraction from real work, I'm curious about your new Kindle opinions
[10:18:13 CDT(-0500)] <jameswy> colinclark: in a nutshell - I was excited for all of 30 minutes.
[10:18:43 CDT(-0500)] <colinclark> lol
[10:18:53 CDT(-0500)] <colinclark> not typical jameswy-ian enthusiasm
[10:19:10 CDT(-0500)] <jameswy> Justin_o: To replicate - in fat panel, maximize line spacing, close and reopen, and change tabs to something that has checkboxes.
[10:19:52 CDT(-0500)] <jameswy> colinclark: I wanted to be excited. I really did.
[10:22:35 CDT(-0500)] <cindyli> Justin_o, michelled, a pull request has been sent out for 4473
[10:23:07 CDT(-0500)] <michelled> Justin_o: is that a blocker?
[10:23:33 CDT(-0500)] <cindyli> no, critical, michelled
[10:23:58 CDT(-0500)] <michelled> Justin_o: are we putting it into 1.4? would it mean restarting testing?
[10:33:29 CDT(-0500)] <Justin_o> jameswy: i don't think that's been filed, but just double check the suggestions
[10:44:51 CDT(-0500)] <Justin_o> michelled: i'm going to take a quick look at the pull request
[10:47:15 CDT(-0500)] <Justin_o> cindyli, michelled: looks like a pretty small change.. how did this work anywhere though?
[10:47:27 CDT(-0500)] <Justin_o> if the initialSize wasn't being set
[10:47:28 CDT(-0500)] <Justin_o> ?
[10:48:00 CDT(-0500)] <cindyli> this "if" is only hit when browser returns "normal" at requesting "line-height", Justin_o
[10:48:14 CDT(-0500)] <cindyli> which likely only happens with IE
[10:48:18 CDT(-0500)] <cindyli> at initial
[10:48:38 CDT(-0500)] <Justin_o> cindyli: okay.. but oddly it worked in the other demo
[10:48:52 CDT(-0500)] <michelled> looks like we should write a test to go with the fix
[10:48:54 CDT(-0500)] <Justin_o> i guess IE is just strange
[10:48:59 CDT(-0500)] <Justin_o> michelled: sounds like a good idea
[10:49:00 CDT(-0500)] <michelled> is feels like something that might regress
[10:49:05 CDT(-0500)] <cindyli> that's probably your line hight has been pre-set
[10:49:11 CDT(-0500)] <cindyli> try remove the cookie
[10:49:15 CDT(-0500)] <michelled> good catch cindyli!
[10:49:31 CDT(-0500)] <cindyli> np, i wish i caught it earlier
[10:49:43 CDT(-0500)] <cindyli> so we don't have to re-start the testing. :-P
[10:49:46 CDT(-0500)] <Justin_o> cindyli: np, thanks for fixing it so quickly
[10:49:58 CDT(-0500)] <cindyli> npnp
[10:50:03 CDT(-0500)] <Justin_o> cindyli, michelled: if it goes it we'll have to restart testing
[10:50:09 CDT(-0500)] <Justin_o> i think it should probably go in
[10:50:16 CDT(-0500)] <cindyli> i think so too
[10:50:54 CDT(-0500)] <anastasiac> michelled, Bosmon2, Justin_o: I'd like to propose that we remove the current Renderer demo from the portal on the grounds that it's so out-of-date that is goes beyond unhelpful into confusing and harmful. I've got several small Renderer demos on the wiki (with more coming today) that are current (i.e. use prototrees, expanders, etc). I'm hoping Bosmon2 can comment on whether or not I'm wrong: maybe the old demo is still useful? But I believe we don't
[10:50:54 CDT(-0500)] <anastasiac> want/expect people to use "the old way."
[10:51:13 CDT(-0500)] <anastasiac> old renderer demo: http://build.fluidproject.org/infusion/demos/renderer/demo.html
[10:51:37 CDT(-0500)] <anastasiac> new instructional demos: http://wiki.fluidproject.org/display/docs/Renderer+-+Radio+Buttons (with many more coming later today)
[10:51:39 CDT(-0500)] <michelled> Justin_o: no argument from me regarding g4473
[10:52:08 CDT(-0500)] <Justin_o> michelled, cindyli: okay so we just need a unit test for that and the pull request can go in?
[10:52:20 CDT(-0500)] <michelled> sounds good
[10:52:33 CDT(-0500)] <michelled> cindyli: could you write the test?
[10:52:38 CDT(-0500)] <cindyli> sure
[10:52:41 CDT(-0500)] <michelled> thanks!
[10:52:43 CDT(-0500)] <cindyli> np
[10:53:05 CDT(-0500)] <michelled> anastasiac: I agree that it's better to remove the demo if it's only going to lead people in the wrong direction
[10:53:10 CDT(-0500)] <michelled> Justin_o: what would that mean to testing?
[10:53:34 CDT(-0500)] <Justin_o> michelled: nothing really… just less testing to do i guess.. since the whole demo will be removed
[10:53:54 CDT(-0500)] <Justin_o> i guess a quick look at the demo page to make sure it's all okay
[10:53:57 CDT(-0500)] <anastasiac> I think it will, michelled. Bosmon2 can confirm whether or not it's true that we don't want to instruct people to use the old way. I think the new way is ready enough for it
[10:53:59 CDT(-0500)] <michelled> anastasiac: do we need to wait for Bosmon2 to make a decision?
[10:54:18 CDT(-0500)] <michelled> sounds like we should
[10:54:34 CDT(-0500)] <anastasiac> well, I'd feel more confident if he commented.
[10:54:36 CDT(-0500)] <Justin_o> michelled, anastasiac: I'm a bit curious about what he would say.. he didn't want me to use the new style for the ToC
[10:54:45 CDT(-0500)] <anastasiac> I know jameswy will be happy if it's removed
[10:54:59 CDT(-0500)] <michelled> Justin_o: I think that was because of existing bugs and the complexity of TOC
[10:55:12 CDT(-0500)] <michelled> we love to make jameswy happy
[10:55:15 CDT(-0500)] <Justin_o> michelled: that's true
[10:55:40 CDT(-0500)] <michelled> Justin_o: I just pushed Bosmon2's pull request so uploader testing should be able to be opened up
[10:55:40 CDT(-0500)] <jameswy> I like being happy.
[10:55:54 CDT(-0500)] <michelled> I guess we should stop uio testing and wait for 4473?
[10:59:31 CDT(-0500)] <Justin_o> michelled: yep.. i'll send out another e-mail about that if you like
[11:00:50 CDT(-0500)] <michelled> thx Justin_o
[11:01:27 CDT(-0500)] <Justin_o> michelled: i'm going to be missing the dev meeting today
[11:01:37 CDT(-0500)] <michelled> ok Justin_o
[11:01:44 CDT(-0500)] <Justin_o> thanks
[11:01:45 CDT(-0500)] <michelled> I'm guessing it'll be a short one
[11:02:12 CDT(-0500)] <Justin_o> michelled: yah.. probably.. not much besides release going on i'd figure
[11:09:09 CDT(-0500)] <Justin_o> cindyli, michelled: i sent out a testing update and upgraded FLUID-4437 to a blocker
[11:09:27 CDT(-0500)] <cindyli> ok, Justin_o
[11:12:27 CDT(-0500)] <michelled> Justin_o: you'll kick the build when appropriate, right?
[11:27:30 CDT(-0500)] <michelled> fluid-everyone: please hold on uploader testing
[11:27:36 CDT(-0500)] <michelled> we need to rebuild before you can test
[11:37:44 CDT(-0500)] <michelled> fluid-everyone: uploader testing is back on
[13:39:39 CDT(-0500)] <michelled> fluid-everyone: it's that time of week again
[13:39:47 CDT(-0500)] <michelled> how about we have dev meeting in here
[13:39:56 CDT(-0500)] <michelled> anyone opposed?
[13:41:24 CDT(-0500)] <michelled> shall we give updates now? anastasiac, would you like to start?
[13:42:24 CDT(-0500)] <anastasiac> sure. I've been reviewing docs-related JIRAs for the release; creating Renderer Instructional Demos (http://wiki.fluidproject.org/display/docs/Renderer+Instructional+Demos) and generally trying to make sure all the docs ducks are in a row. Will also help with testing.
[13:45:45 CDT(-0500)] <michelled> anastasiac: any idea on a timeline for doc ducks?
[13:46:33 CDT(-0500)] <anastasiac> I think we're in good shape. If yura has time to finish reviewing the IoC docs, that would be nice, but I don't think there are any holes significant enough to stop the release.
[13:46:43 CDT(-0500)] <anastasiac> though I do still recommend we retire the renderer demo
[13:49:40 CDT(-0500)] <michelled> cool - we'll check in with Bosmon2 when he's around about that
[13:50:01 CDT(-0500)] <michelled> cindyli: I guess we'll go in alpha order - do you want to give us an update?
[13:51:45 CDT(-0500)] <cindyli> working on the UIO blocker 4473, writing unit test for the modified function.
[13:56:39 CDT(-0500)] <Bosmon2> Hi - I am here
[13:56:41 CDT(-0500)] <Bosmon2> And so is my CATTT
[13:57:46 CDT(-0500)] <jameswy> Bosmon2: we're drinking CATTT coffee right now
[13:59:26 CDT(-0500)] <Bosmon2> anastasiac - I would tend to vote in favour of keeping the unexpanded renderer trees demo
[13:59:50 CDT(-0500)] <Bosmon2> Bearing in mind that colinclark has voted that the renderer be burned to the ground
[14:00:09 CDT(-0500)] <Bosmon2> All I could say in my defence was that "prototree expanders were never designed to be used" : P
[14:00:38 CDT(-0500)] <anastasiac> Bosmon2, so you vote to keep the demo that's in the portal now? That we continue to instruct people to use that technique, and discourage use of the expanders?
[14:00:47 CDT(-0500)] <Bosmon2> No, just to keep the demo
[14:01:05 CDT(-0500)] <Bosmon2> We don't really want to "instruct people to use unexpanded trees"
[14:01:13 CDT(-0500)] <Bosmon2> Just to indicate that they are available, and show how they work
[14:01:21 CDT(-0500)] <Bosmon2> And explain the cases they may prefer to use them
[14:01:33 CDT(-0500)] <anastasiac> Bosmon2, what would those cases be?
[14:01:40 CDT(-0500)] <Bosmon2> That is, in complex situations, and situations where they expect to be modifying trees in a processing pipelines
[14:01:49 CDT(-0500)] <anastasiac> ah, gotcha
[14:01:49 CDT(-0500)] <Bosmon2> For example, if the tree you generate is not the final tree you want to render
[14:02:00 CDT(-0500)] <Bosmon2> But you want there to be further stages of processing before it becomes final
[14:02:29 CDT(-0500)] <Bosmon2> The "hydrated trees" are more suitable for that case, since their layout is more stable and predictable
[14:02:40 CDT(-0500)] <anastasiac> so keep the demo, but add some explanatory text explaining that it demonstrates "full" trees, when you'd use those, and that there is the alternative of expanded prototrees
[14:02:42 CDT(-0500)] <anastasiac> right?
[14:02:56 CDT(-0500)] <Bosmon2> Prototrees are more suitable if you are pretty confident in the tree you are writing, and just want to write the shortest thing that will achieve a particular effect
[14:03:13 CDT(-0500)] <Bosmon2> Also, if you are 100% desperate to have a 100% declarative solution, as we are in CSpace
[14:03:39 CDT(-0500)] <Bosmon2> And are willing to pay all the costs that that involves - that is, the difficulty of debugging and understanding what they are doing
[14:04:09 CDT(-0500)] <Bosmon2> UNfortunately as we see in CSpace, it sort of falls into both camps at once - without the heroic efforts of JURA it would be sort of untenable
[14:04:34 CDT(-0500)] <Bosmon2> That is, i) CSpace is 100% desperate to have a 100% declarative solution, but also ii) needs sometimes to have trees processed further
[14:06:16 CDT(-0500)] <anastasiac> ok, this all makes sense to me
[14:06:32 CDT(-0500)] <colinclark> I want to jump in here for a quick sec
[14:06:36 CDT(-0500)] <colinclark> Apologies, since I'm multitasking
[14:06:45 CDT(-0500)] <Bosmon2> The difficulties raised by these kinds of tradeoffs lead to the conclusion that the "renderer should be burned to the ground"
[14:06:48 CDT(-0500)] <colinclark> Is there a demo that does include instructions on how to use prototrees and the like?
[14:07:03 CDT(-0500)] <Bosmon2> Since its impossible with the current tradeoffs to make a clear recommendation to people for a usage that will "certainly turn out well"
[14:07:12 CDT(-0500)] <colinclark> I'm sort of wondering if what we should be considering is a new, improved demo, which provides a variety of examples of use of the Renderer
[14:07:18 CDT(-0500)] <Bosmon2> But all we can do is explain the merits and demerits of the various approaches we can support right now
[14:08:37 CDT(-0500)] <colinclark> So, I think I need some more background information...
[14:08:50 CDT(-0500)] <colinclark> 1. What renderer demos do we currently offer our users?
[14:08:56 CDT(-0500)] <anastasiac> colinclark, we do have a number of small demos for prototrees: http://wiki.fluidproject.org/display/docs/Renderer+Instructional+Demos and I'm all for adding a nice "showcase" demo as well
[14:09:07 CDT(-0500)] <colinclark> 2. What sort of documentation do we have to cover a) prototrees and b) full-fledged trees
[14:09:23 CDT(-0500)] <colinclark> anastasiac: You were suggesting getting rid of the current demo portal renderer demo?
[14:10:31 CDT(-0500)] <colinclark> These instructional demos for prototrees are quite nice
[14:10:37 CDT(-0500)] <anastasiac> I was suggesting it based on a couple of things: 1) my apparently not-quite-correct understanding that we prefer people use prototrees, and B) the fact that anyone I've spoken to who's tried to look at it has become quite confused, and not found it helpful
[14:11:02 CDT(-0500)] <colinclark> anastasiac: Do you have any proposals for what to replace it with?
[14:11:06 CDT(-0500)] <colinclark> Something? Or nothing?
[14:11:35 CDT(-0500)] <Bosmon2> I guess we prefer people use prototrees in those cases where people are in the kind of regime where they would find demos that "do something a bit like they want to do already, and just need to tweak them a bit"
[14:11:46 CDT(-0500)] <anastasiac> I definitely think we should replace it with something, but a proper replacement would take time: thought to good use case, good design, implementation. not for 1.4
[14:11:46 CDT(-0500)] <Bosmon2> So in that case demos for them are particularly valuable
[14:12:27 CDT(-0500)] <colinclark> anastasiac, Bosmon2: So, perhaps I'll try to propose something
[14:12:37 CDT(-0500)] <colinclark> 1. We leave the current Renderer demo as-is for 1.4
[14:12:58 CDT(-0500)] <colinclark> 2. When users have questions, we point them to anastasiac's excellent prototree demos
[14:13:05 CDT(-0500)] <colinclark> 3. For a future release, we make a hot Renderer demo
[14:13:08 CDT(-0500)] <Bosmon2> anastasiac - we hope that by the next release cycle, the use of the renderer in its current form will be removed in any case
[14:13:28 CDT(-0500)] <Bosmon2> So we shouldn't plan too much investment in demos which illustrate current approaches
[14:13:33 CDT(-0500)] <Bosmon2> And should preserve whatever demos we have
[14:14:28 CDT(-0500)] <anastasiac> colinclark, your proposal looks good, but I'd recommend we add some text to the demo (or the portal surround?) explaining that the demo uses "technique A" which is good for use cases A, and that there is also "technique B" which is good for use cases B, with a link to the instructional demos
[14:14:51 CDT(-0500)] <colinclark> I think that's a decision for our "King"
[14:15:06 CDT(-0500)] <colinclark> michelled: What's your call on the idea of modifications to a demo for 1.4?
[14:15:53 CDT(-0500)] <anastasiac> if we add the text to the demo portal surround, we would avoid the risk of breakage of the demo itself
[14:16:00 CDT(-0500)] <michelled> that's a good question colinclark
[14:16:31 CDT(-0500)] <michelled> if the only thing we modify is the text in the demo portal then I'm ok with the change
[14:16:44 CDT(-0500)] <michelled> it will just be a quick sniff test and won't require restarting testing
[14:16:57 CDT(-0500)] <colinclark> What will the text actually say?
[14:17:24 CDT(-0500)] <colinclark> What are these abstract "technique B" and "use case A," practically speaking?
[14:17:55 CDT(-0500)] <anastasiac> don't know yet. I'll have to draft something, but it will be a version of what Bosmon2 has explained above. Technique A is the fully-hydrated tree, tech. B is a prototree with optional expanders
[14:18:24 CDT(-0500)] <michelled> anastasiac: when do you think you'd be able to get us text?
[14:18:39 CDT(-0500)] <anastasiac> I could work on it as soon as the dev meeting is over. shouldn't take too long
[14:26:55 CDT(-0500)] <michelled> given that we still have a couple final tasks to do like turning off debug mode which will require some sniff testing I'm willing to put in the text only change.
[14:27:07 CDT(-0500)] <michelled> any disagreements?
[14:30:35 CDT(-0500)] <michelled> colinclark: did you want to give a dev meeting update?
[14:30:39 CDT(-0500)] <colinclark> oh hi
[14:30:41 CDT(-0500)] <colinclark> yes
[14:30:53 CDT(-0500)] <colinclark> I think I don't have much from the Infusion end of things
[14:31:03 CDT(-0500)] <colinclark> Longer term strategy, mostly
[14:31:14 CDT(-0500)] <colinclark> Bosmon2 and I have been chatting about the future of Infusion on a couple of fronts
[14:32:02 CDT(-0500)] <michelled> that sounds interesting
[14:32:08 CDT(-0500)] <colinclark> Including the prospect of starting to spec out some subset of Infusion's context resolution rules so that we can have some measure of consistency across very different implementations for context-aware UIs.
[14:32:46 CDT(-0500)] <colinclark> We also talked, on the "micro level" about how we might manage a very simple kernel of Infusion for simple use cases
[14:33:10 CDT(-0500)] <colinclark> One can imagine our build system could support this in a number of ways
[14:33:23 CDT(-0500)] <colinclark> But nothing concrete will come of this in the short term, I expect
[14:33:43 CDT(-0500)] <colinclark> After 1.4, we're going to focus our energies as a community in two key areas:
[14:34:01 CDT(-0500)] <colinclark> 1. A video delivery and authoring prototype led by jameswy
[14:34:43 CDT(-0500)] <colinclark> 2. Framework and infrastructure improvements that will lead to a working preferences server for GPII and Cloud4all as well as, before too long, the replacement of the Renderer API with something more amazing
[14:35:09 CDT(-0500)] <colinclark> Common to both #1 and #2, of course, will be incremental improvements to UI Options
[14:35:19 CDT(-0500)] <colinclark> We likely won't put out a formal new Infusion release for awhile
[14:35:33 CDT(-0500)] <colinclark> but I'd like to, once we've shipped, have a community discussion about how to streamline our release process
[14:36:06 CDT(-0500)] <colinclark> On the Decapod, Justin and jhung are moving on new features. In particular, new designs for both import and export
[14:36:46 CDT(-0500)] <colinclark> They're going to sprint on these two features over the next month in order to produce a very simple, minimalist, working application that they can bring with them to Nigeria and start to use for capturing some very interesting material there.
[14:37:16 CDT(-0500)] <colinclark> For Decapod, we'd hoped we might make a move to Git and Github, but I don't think that's practical. We can handle continuing to work in Mercurial, I think.
[14:37:40 CDT(-0500)] <colinclark> I'd prefer we just focus entirely on adding to the capabilities and usefulness of Decapod right now.
[14:38:02 CDT(-0500)] <colinclark> A little bit further out on my radar is a series of community proposals:
[14:38:16 CDT(-0500)] <colinclark> 1. Formal introduction of the Fluid Community Studios
[14:38:53 CDT(-0500)] <colinclark> 2. A new application build and deploy environment driven by Git, which will help simplify Fluid's build servers as well as the IDRC's production web site development and deployment workflow
[14:40:02 CDT(-0500)] <colinclark> 3. A set of recommended techniques for building open source inclusive software, which will include suggestions about how to work transparently, write unit tests, etc.
[14:40:32 CDT(-0500)] <michelled> perhaps it can take the place of the laser eye checklist
[14:40:43 CDT(-0500)] <colinclark> Yes, that's exactly what I was about to say
[14:40:56 CDT(-0500)] <colinclark> I think that's probably all I've got on my mind at the moment
[14:41:05 CDT(-0500)] <colinclark> I think it's going to be very exciting for us to ship Infusion 1.4
[14:41:23 CDT(-0500)] <colinclark> and jameswy has some really exciting early ideas for how we can build genuinely useful video-related components
[14:41:25 CDT(-0500)] <Bosmon2> It will be
[14:41:29 CDT(-0500)] <Bosmon2> Not only, a relief
[14:41:30 CDT(-0500)] <colinclark> i'm quite stoked
[14:41:34 CDT(-0500)] <colinclark> that, too, Bosmon2
[14:41:40 CDT(-0500)] <colinclark> We've done a lot of really great work in this release
[14:41:48 CDT(-0500)] <colinclark> and it's been all part of a much larger, longer transition
[14:42:07 CDT(-0500)] <colinclark> to OCAD, to a larger team, a new style of architecture, etc.
[14:42:20 CDT(-0500)] <colinclark> As Johnny Taylor would say, "these things take time."
[14:42:21 CDT(-0500)] <colinclark>
[14:42:30 CDT(-0500)] <michelled>
[14:42:59 CDT(-0500)] <colinclark> I'm done
[14:43:05 CDT(-0500)] <colinclark> Unless anyone has any questions
[14:43:09 CDT(-0500)] <michelled> harriswong: do you want to give us an update?
[14:44:12 CDT(-0500)] <michelled> oh, harriswong isn't at his desk
[14:44:20 CDT(-0500)] <michelled> huslage: anything you want to let us all know about?
[14:44:34 CDT(-0500)] <huslage> nope. thanks
[14:44:48 CDT(-0500)] <huslage> i'm working with colin on some stuff
[14:44:49 CDT(-0500)] <michelled> I think that means me
[14:44:56 CDT(-0500)] <colinclark> huslage: we're working on such cool stuff
[14:45:01 CDT(-0500)] <huslage> bwhaha
[14:45:08 CDT(-0500)] <colinclark> don't you want to give a super quick summary of your amazing architecture for servers?
[14:45:19 CDT(-0500)] <colinclark> and how we talked with a very interesting open source hardware vendor today?
[14:45:24 CDT(-0500)] <huslage> ok
[14:45:37 CDT(-0500)] <huslage> we spoke with the founder of Nebula today.
[14:45:40 CDT(-0500)] <colinclark> just one or two sentences; I know you're busy with lots of other things
[14:45:59 CDT(-0500)] <huslage> they recently spun out of NASA to commercialize an open source Cloud orchestration software called OpenStack
[14:46:27 CDT(-0500)] <huslage> they have some awesome new hardware and they are interested in partnering with us (taking our money and giving us none) on their pilot deployments
[14:46:44 CDT(-0500)] <huslage> so that's awesome
[14:47:01 CDT(-0500)] <huslage> we're working on architecture now and hope to have the RFP pretty quickly
[14:47:05 CDT(-0500)] <Bosmon2> Sounds like the plot of a new web-based TV show
[14:47:15 CDT(-0500)] <huslage> NEBULA.TV
[14:47:45 CDT(-0500)] <Bosmon2> "Escaped from a maximum security stockade ... "
[14:48:03 CDT(-0500)] <huslage> lol
[14:48:11 CDT(-0500)] <huslage> they're really great it seems.
[14:48:21 CDT(-0500)] <huslage> i'm running openstack on a couple of our servers now
[14:48:32 CDT(-0500)] <Bosmon2> Bizarre
[14:48:34 CDT(-0500)] <Bosmon2> What is it good for?
[14:48:48 CDT(-0500)] <huslage> our new infrastructure will operate similarly to amazon EC2
[14:49:13 CDT(-0500)] <huslage> in that you'll be able to provision a server, play with stuff on it, kill it, run production code on it, etc…without a sysadmin for a lot of it
[14:49:31 CDT(-0500)] <colinclark> and it removes the need for expensive, specialized, central solutions
[14:49:33 CDT(-0500)] <huslage> i'll generate a "standard build" and you guys will be able to get work done
[14:49:39 CDT(-0500)] <huslage> yeah. no central storage
[14:49:45 CDT(-0500)] <huslage> all distributed
[14:49:45 CDT(-0500)] <colinclark> allowing us to use commodity server hardware for storage, serving, etc.
[14:49:51 CDT(-0500)] <Bosmon2> Interesting
[14:49:59 CDT(-0500)] <Bosmon2> I guess it can provision new VMs on the same machine too
[14:50:04 CDT(-0500)] <colinclark> yep
[14:50:44 CDT(-0500)] <Bosmon2> Does it work with a machine format that is in any way compatible with AMIs?
[14:50:49 CDT(-0500)] <Bosmon2> Or with conversino tools?
[14:50:53 CDT(-0500)] <Bosmon2> conversion
[14:54:03 CDT(-0500)] <colinclark> Bosmon2: I don't know, but we're probably using KVM for virtualization, so it's quite likely there's a conversion path
[14:54:08 CDT(-0500)] <colinclark> michelled: carry on
[14:54:41 CDT(-0500)] <michelled> ok, so I've stolen the crown from Justin_o for the final push on 1.4
[14:54:56 CDT(-0500)] <michelled> we are really close now (I feel like a broken record but this time it's true)
[14:55:11 CDT(-0500)] <michelled> we've got a single pull request we are waiting on - some tests that cindyli is working on
[14:55:26 CDT(-0500)] <michelled> then there are a few clean up tasks which I need to check in with the old KING on
[14:55:48 CDT(-0500)] <michelled> testing is just about done - uploader testing is part way through
[14:55:57 CDT(-0500)] <michelled> uio testing is waiting on that pull request I mentioned
[14:56:12 CDT(-0500)] <michelled> I feel like we are in a good position to be making bundles to test tomorrow
[14:56:26 CDT(-0500)] <michelled> I'll keep you all updated as we continue
[14:56:31 CDT(-0500)] <colinclark> that's great news, michelled !
[14:56:43 CDT(-0500)] <michelled> anastasiac: that means I need your pull request by tomorrow morning
[14:57:06 CDT(-0500)] <anastasiac> michelled, will do. I'll try to get it in today.
[14:57:11 CDT(-0500)] <michelled> thx
[14:57:36 CDT(-0500)] <michelled> I did a little continuum clean up today and delete 40 spam accounts
[14:57:57 CDT(-0500)] <michelled> if I accidentally deleted your account I'm sorry - let me know who you are and I won't do that again
[14:58:29 CDT(-0500)] <michelled> I think that's all I've got to say
[14:58:35 CDT(-0500)] <michelled> yura: do you have an update for us?
[14:58:57 CDT(-0500)] <yura> working on enhancing number validation for cspace at the moment, that's about it
[14:59:23 CDT(-0500)] <michelled> Bosmon2: not sure if you know that yura has also made the autocomplete component permission aware
[14:59:36 CDT(-0500)] <michelled> you might want to take a peek since you originally wrote it
[14:59:39 CDT(-0500)] <yura> but it is only a pluggable functionality
[14:59:59 CDT(-0500)] <yura> so it should not affect the original design of the component
[15:00:10 CDT(-0500)] <yura> it's been refactored previously as well
[15:00:35 CDT(-0500)] <michelled> fluid-everyone: does anyone else want to give us an update?
[15:01:03 CDT(-0500)] <michelled> Bosmon2: I think I missed you because I was going alphabetically and started before you joined in
[15:02:33 CDT(-0500)] <jhung> michelled: just wrapping up import and export designs for decapod. Looking to start development / implementation soon.
[15:06:21 CDT(-0500)] <michelled> thx jhung
[15:06:50 CDT(-0500)] <Bosmon2> I have been working on constructing damnable testcases for codebases that should have had them for years!
[15:06:54 CDT(-0500)] <Bosmon2> This is my update : P
[15:07:08 CDT(-0500)] <colinclark> Bosmon2: ouch, dude
[15:07:20 CDT(-0500)] <colinclark> I wrote as many as I could, given the circumstances
[15:11:02 CDT(-0500)] <michelled> jameswy: do you know lucian's status?
[15:11:13 CDT(-0500)] <michelled> he's got a couple testing tasks that aren't checked off
[15:11:19 CDT(-0500)] <jameswy> michelled: He's still testing them, afaik.
[15:11:35 CDT(-0500)] <michelled> do you know when he's working next?
[15:12:07 CDT(-0500)] <jameswy> michelled: He's been working on and off pretty much the length of the week.
[15:12:22 CDT(-0500)] <michelled> thx
[15:23:10 CDT(-0500)] <michelled> cindyli: can you explain the issue with the tests that you are currently working on?
[15:23:24 CDT(-0500)] <michelled> I know you are working on this JIRA: http://issues.fluidproject.org/browse/FLUID-4473
[15:23:33 CDT(-0500)] <michelled> and have a fix: https://github.com/fluid-project/infusion/pull/174/files
[15:24:02 CDT(-0500)] <cindyli> sure, michelled, let me dig out the lines that i'm writing the unit test for
[15:24:36 CDT(-0500)] <cindyli> https://github.com/cindyli/infusion/blob/FLUID-4473/src/webapp/components/uiOptions/js/UIEnhancer.js#L465-488
[15:24:59 CDT(-0500)] <cindyli> in particularly, line 469 − 472:
[15:25:01 CDT(-0500)] <cindyli>         if (lineHeight === "normal") {
[15:25:01 CDT(-0500)] <cindyli>             that.initialSize = 1;
[15:25:01 CDT(-0500)] <cindyli>             return;
[15:25:01 CDT(-0500)] <cindyli>         }
[15:27:03 CDT(-0500)] <cindyli> "normal" is a valid "line-height" css value, if the div is explicitly set to this value, when we use "that.container.css("lineHeight")" to retrieve it, all browsers except firefox return back "normal" string value, but firefox returns back the exact px
[15:27:46 CDT(-0500)] <cindyli> btw, the pixel value from ff is usually around 1.2em
[15:28:21 CDT(-0500)] <cindyli> so, i run into a dilemma how to write a browser-independent unit test
[15:29:07 CDT(-0500)] <cindyli> the unit test i'm having now:
[15:29:10 CDT(-0500)] <cindyli> if (!$.browser.mozilla) {
[15:29:10 CDT(-0500)] <cindyli> lineHeightInitCalc(uiEnhancer, "normal", "1");
[15:29:10 CDT(-0500)] <cindyli> };
[15:29:30 CDT(-0500)] <cindyli> meaning, if not firefox, we expect "normal" string value being converted to 1em
[15:29:41 CDT(-0500)] <cindyli> with firefox, we don't know
[15:29:59 CDT(-0500)] <Bosmon2> cindyli - is it us in the first place who would set the lineHeight to "normal"?
[15:30:01 CDT(-0500)] <Bosmon2> Or is it someone else
[15:30:01 CDT(-0500)] <cindyli> Bosmon2: i know you won't be happy with what i'm writing. any suggestion
[15:30:10 CDT(-0500)] <cindyli> someone else
[15:30:21 CDT(-0500)] <Bosmon2> I see
[15:31:37 CDT(-0500)] <Bosmon2> Aren't there other textual line-height values than "normal"?
[15:31:44 CDT(-0500)] <Bosmon2> It's a little suspicious that we are checking only for one
[15:32:29 CDT(-0500)] <cindyli> http://www.w3schools.com/cssref/pr_dim_line-height.asp
[15:32:44 CDT(-0500)] <cindyli> another string might be "inherit" but i haven't tried yet
[15:33:10 CDT(-0500)] <cindyli> the rest of number or % etc, would be returned back in px
[15:33:19 CDT(-0500)] <cindyli> trying with "inherit"
[15:34:55 CDT(-0500)] <Bosmon2> StackOverflow answers indicate that this is fundamentally problematic
[15:35:26 CDT(-0500)] <Bosmon2> And it looks like this function is going to become just more and more of a mess
[15:35:33 CDT(-0500)] <Bosmon2> Do we actually require to read the line-height at all?
[15:35:39 CDT(-0500)] <Bosmon2> Wouldn't it be good enough just to be able to write it?
[15:39:15 CDT(-0500)] <Bosmon2> cindyli^
[15:39:48 CDT(-0500)] <cindyli> Bosmon2: we need to know the initial line height for the line spacing multiplier
[15:40:01 CDT(-0500)] <Bosmon2> cindyli - should the setting even be a multiplier at all?
[15:40:07 CDT(-0500)] <Bosmon2> Are we actually convinced that makes sense?
[15:40:29 CDT(-0500)] <cindyli> oh, that's part of the design i think
[15:40:41 CDT(-0500)] <Bosmon2> jameswy - are you around for us to question this part of the design?
[15:40:48 CDT(-0500)] <Bosmon2> My current feeling is that it is effectively unimplementable
[15:42:49 CDT(-0500)] <cindyli> btw, Bosmon2, just tried with "inherit", ie and ff return actual px while safari and chrome return "normal", which i supposed is from its parent element
[15:43:25 CDT(-0500)] <cindyli> well, didn't try with all the supported versions, only the latest, needs more experiments
[15:44:12 CDT(-0500)] <cindyli> jameswy is in another chat with michelled
[15:44:31 CDT(-0500)] <anastasiac> michelled, I've issued a pull request for the renderer demo text update: https://github.com/fluid-project/infusion/pull/175
[15:55:55 CDT(-0500)] <jameswy> Bosmon2: What's the question?
[15:56:41 CDT(-0500)] <Bosmon2> jameswy - would it be acceptable for us to change the interpretation of the "line-height" setting to being an absolute expansion relative to the current font baseline, rather than a setting relative to whatever we can decode the current CSS state of the page calculates it to be
[15:57:18 CDT(-0500)] <michelled> thanks anastasiac
[16:06:32 CDT(-0500)] <jameswy> Bosmon2: just chatted with cindyli.
[16:06:43 CDT(-0500)] <jameswy> It's not acceptable, for the end product.
[16:06:49 CDT(-0500)] <jameswy> But I don't consider it a blocker for 1.4
[16:07:34 CDT(-0500)] <jameswy> The multiplied line height needs to be relative to the content's default line height, not some absolute line height. We can't go mucking around with the content's defaults.
[16:08:05 CDT(-0500)] <Bosmon2> jameswy - can you explain why?
[16:09:39 CDT(-0500)] <jameswy> Bosmon2: Because the user would be given a design that's been altered… and that's just… evil.
[16:10:07 CDT(-0500)] <Bosmon2> jameswy - can you unpack that sentiment?
[16:10:23 CDT(-0500)] <Bosmon2> I am always challenged when I make judgements of that form
[16:12:01 CDT(-0500)] <Bosmon2> Surely the entire premise of UIOptions is that they are given a design that is altered
[16:12:03 CDT(-0500)] <colinclark> indeed, Bosmon2 is the king of evil-based arguments
[16:12:04 CDT(-0500)] <jameswy> Bosmon2: UIO's default/reseted state should be that of the designer's original, pure intent. It should be as though UIO hadn't been integrated at all.
[16:12:59 CDT(-0500)] <Bosmon2> So - perhaps we could accommodate that possibility by making the space of values for line-height discontinuous
[16:13:07 CDT(-0500)] <Bosmon2> It has a single, identified "do-nothing" setting
[16:13:21 CDT(-0500)] <Bosmon2> And then all the other settings accessible via the slider are "do-something" settings
[16:14:40 CDT(-0500)] <michelled> I need to run in order to make it to yoga tonight but I'm strongly feeling like I'm not going to let this into 1.4 if we change the meaning of a setting
[16:14:42 CDT(-0500)] <jameswy> Bosmon2: How would that work? If the user selects the lowest "do-something" setting, wouldn't you be at risk of decreasing the line-height when the user's intention was to increase it?
[16:14:44 CDT(-0500)] <michelled> it feels too big
[16:14:51 CDT(-0500)] <jameswy> (depending on the browser)
[16:14:59 CDT(-0500)] * michelled hasn't kept up so sorry if I've missed some important development
[16:15:00 CDT(-0500)] <jameswy> (and its internal default line-heights)
[16:15:06 CDT(-0500)] <Bosmon2> jameswy - that's perfectly possible, yes
[16:15:16 CDT(-0500)] <jameswy> Bosmon2: Then, unacceptable.
[16:15:16 CDT(-0500)] <colinclark> michelled: If I can make a kingly recommendation, I'd say let jameswy and Bosmon2 brainstorm together about it
[16:15:19 CDT(-0500)] <colinclark> they're very smart
[16:15:27 CDT(-0500)] <colinclark> and we can reserve decisions for tomorrow
[16:15:30 CDT(-0500)] <michelled> colinclark: that is very true
[16:15:36 CDT(-0500)] <michelled> sounds good
[16:20:17 CDT(-0500)] <Bosmon2> jameswy - will you be around for a while, or should we talk tomorrow?
[16:20:34 CDT(-0500)] <jameswy> Bosmon2: Let's talk tomorrow.
[16:20:39 CDT(-0500)] <Bosmon2> Sounds good
[16:20:44 CDT(-0500)] <jameswy> Ping me when you're in?
[16:20:55 CDT(-0500)] <Bosmon2> will do
[16:21:10 CDT(-0500)] <jameswy> Great

Browser not supported