fluid-work IRC Logs-2011-01-20

Owned by Fluid IRC Log Bot
Last updated: Jan 20, 2011Version comment
41 min read

[08:04:35 CST(-0600)] <justin_o> anastasiac: hello, could you please review the following jiras
[08:04:37 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-2423
[08:04:37 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-2970
[08:04:37 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-877
[08:04:38 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-531'
[08:04:52 CST(-0600)] <anastasiac> Justin_o, will do
[08:04:59 CST(-0600)] <justin_o> thanks
[08:06:26 CST(-0600)] <justin_o> jhung: hello, could you please review the following jiras
[08:06:27 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-2414
[08:06:28 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-787
[08:06:43 CST(-0600)] <justin_o> also when you have time for some jira gardening could you look at the OSDPL ones
[08:09:33 CST(-0600)] <jhung> justin_o: Sure. I closed FLUID-787 and kept 2414.
[08:09:52 CST(-0600)] <justin_o> jhung: thanks
[08:12:24 CST(-0600)] <colinclark> anastasiac: Hey, I was just checking out the new Pager tutorial
[08:13:00 CST(-0600)] <colinclark> How come you decided to show the Renderer using rsf:ids?
[08:16:39 CST(-0600)] <anastasiac> well, now I'm confused, colinclark
[08:17:03 CST(-0600)] <colinclark> (smile)
[08:17:04 CST(-0600)] <colinclark> ok
[08:17:05 CST(-0600)] <colinclark> how come?
[08:18:01 CST(-0600)] <anastasiac> the pager demo uses rsf:ids, and the tut uses the pager demo code. my recollection was that the pager demo used rsf:ids because of a bug in the pager that still required rsf:ids for sortable columns, but now I can find to reference to that bug, or indication of its existence in the pager code, which would mean it's a bug in the demo (and hence the tutorial). I will need to investigate further...
[08:19:13 CST(-0600)] <colinclark> ok, that all makes sense
[08:19:42 CST(-0600)] <colinclark> If there really is a bug that requires us to use rsf:ids, I'm quite motivate to schedule that as a significant bug
[08:20:00 CST(-0600)] <colinclark> Our users should never need to know that such things exist
[08:20:52 CST(-0600)] <anastasiac> yes, I was going to put it on my 'top 5' list when I found it, but now I can't find it (wink)
[08:21:03 CST(-0600)] <anastasiac> if it is a bug, I'll file it
[08:21:10 CST(-0600)] <anastasiac> otherwise, I'll fix the demo and tutorial
[08:23:57 CST(-0600)] <justin_o> colinclark: could you please review the following jiras:
[08:23:58 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-231
[08:23:59 CST(-0600)] <justin_o> http://issues.fluidproject.org/browse/FLUID-141
[08:24:04 CST(-0600)] <colinclark> for sure
[08:24:08 CST(-0600)] <colinclark> nice historical JIRAs
[08:24:11 CST(-0600)] <colinclark> always a pleasure (smile)
[08:24:22 CST(-0600)] <justin_o> (smile)
[08:24:38 CST(-0600)] <colinclark> Wowza, I don't even know what the first one means
[08:25:43 CST(-0600)] <justin_o> (smile) i wonder if that should have said svn or something like that
[08:29:37 CST(-0600)] <colinclark> justin_o: I think that's probably the case, yes
[08:29:49 CST(-0600)] <colinclark> So, justin_o, your email about Date Picker to jessm and I
[08:30:07 CST(-0600)] <colinclark> On first glance, I thought
[08:30:29 CST(-0600)] <colinclark> "oh, maybe we should keep Date Picker things around in JIRA, just in case it's something we or someone else wants to pick up"
[08:30:48 CST(-0600)] <colinclark> But after looking at the tickets in JIRA, they're all pretty dated
[08:30:58 CST(-0600)] <colinclark> they're the kind of JIRAs that have an expiration date--iteration-specific planning tasks
[08:31:25 CST(-0600)] <colinclark> So, assuming jessm agrees, I agree with you that we should just close 'em all.
[08:32:29 CST(-0600)] <justin_o> colinclark: thanks... okay... I'll wait and make sure i get the thumbs up from jessm and if so close them all out
[08:32:36 CST(-0600)] <colinclark> k
[08:33:31 CST(-0600)] <justin_o> colinclark: by the way, the website was put into scratchpad at some point
[08:33:32 CST(-0600)] <justin_o> http://source.fluidproject.org/svn/scratchpad/fluidproject-website/
[08:34:02 CST(-0600)] <jessm> colinclark: +1 re: datepicker – didn't want to respond first. i think if we were to take on datepicker again in earnest, we'd have to pretty much do-over
[08:34:16 CST(-0600)] <colinclark> jessm: so true
[08:34:25 CST(-0600)] <colinclark> justin_o: Yes, that's right
[08:34:30 CST(-0600)] <jessm> dates r hard
[08:34:40 CST(-0600)] <colinclark> This was part of our ill-fated (I believe) attempt to move to a flat HTML web site
[08:34:57 CST(-0600)] <anastasiac> Justin_o, I've reviewed those 4 JIRA: resolved 2, updated 2
[08:35:00 CST(-0600)] <colinclark> jessm: Any thoughts on what we should do with that?
[08:35:20 CST(-0600)] <colinclark> Given that we haven't kept it updated, it perhaps is worse to keep an old version lying around in SVN?
[08:35:45 CST(-0600)] <jessm> colinclark: i still dream of simplicity, but i'm not sure we'll be going to flat HTML. yes, agreed, not great to have crust and dust. it encourages mites.
[08:36:05 CST(-0600)] <justin_o> anastasiac: thanks...
[08:36:11 CST(-0600)] <colinclark> BTW, justin_o and yura_, I noticed that CouchDB hit 1.0 recently, and they're still churning out new releases
[08:36:16 CST(-0600)] <justin_o> jessm: thanks i'll close those jiras out now
[08:36:18 CST(-0600)] <jessm> justin_o: colinclark: the website work doesn't come up again until 1.5 and i imagine at that point we can revisit the landscape of web issues
[08:36:23 CST(-0600)] <colinclark> So with Node Kettle, that's a kill combination
[08:36:43 CST(-0600)] <colinclark> jessm and justin_o: Okay, so I vote for just tossing the website from SVN
[08:36:51 CST(-0600)] <jessm> +1
[08:37:01 CST(-0600)] <justin_o> colinclark: that's good to hear about couchdb...
[08:37:46 CST(-0600)] <justin_o> colinclark, jessm: speaking of tossing things.. we should talk with jamon about what we can ditch from during our git conversion
[08:37:50 CST(-0600)] <colinclark> jessm: I guess the dream of simplicity doesn't ultimately go terribly well with flat HTML in the end... we just need contentn management systems that are both simple and well-suited to the job. Hard to come by.
[08:38:09 CST(-0600)] <colinclark> justin_o: That makes sense. I will catch up on your list and do a tour through SVN
[08:38:17 CST(-0600)] <colinclark> I think there's something interesting here...
[08:38:23 CST(-0600)] <jessm> justin_o: colinclark and i talked to jamon about this very thing yesterday. i think he's getting colinclark an output of folders n' such to toss or keep
[08:38:31 CST(-0600)] <colinclark> We may well want to keep a backup of our old SVN just prior to the migration
[08:38:44 CST(-0600)] <jessm> +1 on backup
[08:38:48 CST(-0600)] <colinclark> and then I am actually in favour of tossing things from SVN that won't be in git
[08:38:51 CST(-0600)] <colinclark> This seems odd
[08:38:54 CST(-0600)] <jessm> reverting is a lovely option is things go badly
[08:39:10 CST(-0600)] <colinclark> but I guess what I'm getting at is that I'd like SVN not to contain old, crusty, confusing things
[08:39:17 CST(-0600)] <colinclark> In other words, SVN is going to sort of sit from here on in
[08:39:28 CST(-0600)] <colinclark> So, it will be a living repository for design
[08:39:32 CST(-0600)] <colinclark> and for any other big binaries
[08:39:48 CST(-0600)] <colinclark> Everything else, I guess we're arguing should be historically intact in our migration to git
[08:39:51 CST(-0600)] <justin_o> colinclark: that's not a bad idea.. less confusing for people
[08:39:58 CST(-0600)] <jessm> colinclark: yes, re: content mgmt.
[08:40:05 CST(-0600)] <colinclark> In which case, as long as we've got a suitable backup, we should toss old stuff from SVN altogether
[08:40:24 CST(-0600)] <justin_o> colinclark: okay, makes sense...
[08:40:34 CST(-0600)] <colinclark> I guess there's a question of how well suited we are, infrastructurally, to maintain legacy backups for the long term
[08:40:41 CST(-0600)] <colinclark> jessm: You're sort of awesome with this sort of thing
[08:40:44 CST(-0600)] <colinclark> any thoughts?
[08:41:19 CST(-0600)] <justin_o> colinclark: something else to think about... are you okay with losing history of branches and other thing (e.g. incubator, scratchpad, sandbox, etc.) that didn't make it into trunk
[08:41:32 CST(-0600)] <colinclark> not entirely, no (smile)
[08:41:48 CST(-0600)] <colinclark> I am, in principle, pretty uncomfortable to losing history at all
[08:41:51 CST(-0600)] <colinclark> as an open source project
[08:41:53 CST(-0600)] <justin_o> the thing with git is that if you delete a branch, it will eventually get garbage collected
[08:42:11 CST(-0600)] <jessm> colinclark: thoughts re: backup?
[08:42:51 CST(-0600)] <jessm> i trend toward pack rat in my backup strategy
[08:42:53 CST(-0600)] <colinclark> jessm: yep
[08:43:11 CST(-0600)] <colinclark> justin_o, jessm: I guess there's another way to do this, but it's perhaps more confusing and less efficient
[08:43:31 CST(-0600)] <colinclark> We retain a complete, frozen view of our world in SVN as of the moment we switch to git
[08:43:42 CST(-0600)] <colinclark> Make it read-only, then forget about it
[08:43:51 CST(-0600)] <colinclark> essentially that is just the backup I'm talking about (smile)
[08:44:15 CST(-0600)] <colinclark> 2. We establish a "living" space for those parts of the project that will continue to live in SVN
[08:44:24 CST(-0600)] <colinclark> i.e. the design repo, most prominently
[08:44:33 CST(-0600)] <colinclark> As well as a live SVN mirror of git
[08:44:42 CST(-0600)] <colinclark> It's sort of all the same, if you see what I mean
[08:44:50 CST(-0600)] <jessm> i think we would need to go read-only or risk someone stumbling in there and treating it as active space
[08:44:53 CST(-0600)] <colinclark> yes
[08:45:03 CST(-0600)] <colinclark> Point being that we retain a complete history of the world
[08:45:10 CST(-0600)] <jessm> if possible yes
[08:45:18 CST(-0600)] <colinclark> but we ensure that the old world is frozen
[08:45:26 CST(-0600)] <jessm> a frozen pack rat
[08:45:31 CST(-0600)] <colinclark> jessm: I'm curious about your "if possible" qualifier
[08:45:33 CST(-0600)] <colinclark> (smile)
[08:45:48 CST(-0600)] <jessm> well, i'm sure it is possible, so not sure why i typed that (wink)
[08:45:51 CST(-0600)] <colinclark> lol
[08:45:52 CST(-0600)] <colinclark> fair enough
[08:46:05 CST(-0600)] <colinclark> It seems to me that, as an open source community, we're fairly obligated to retain a complete history of changes and check-ins
[08:46:16 CST(-0600)] <colinclark> It'll be essential if we ever moved the IP to a foundation
[08:46:25 CST(-0600)] <colinclark> and even more essential in case of legal challenges or patent cases
[08:46:43 CST(-0600)] <jessm> roger that
[08:46:59 CST(-0600)] <colinclark> Okay, so I think I'm getting clearer on this
[08:47:21 CST(-0600)] <colinclark> So, do we feel it is important to keep a frozen, visible instance of our SVN repo past the move to git?
[08:47:34 CST(-0600)] <colinclark> Or can we tolerate knowing that it lives in a tarball somewhere?
[08:47:40 CST(-0600)] <jessm> yes, i think so – as you said, it can play a role in future design work
[08:47:56 CST(-0600)] <jessm> didn't you say that?
[08:48:04 CST(-0600)] <colinclark> the design work?
[08:48:29 CST(-0600)] <colinclark> i'm confused (smile)
[08:48:39 CST(-0600)] <jessm> colinclark: In other words, SVN is going to sort of sit from here on in
[08:48:39 CST(-0600)] <jessm> [09:39am] colinclark: So, it will be a living repository for design
[08:49:03 CST(-0600)] <colinclark> right
[08:49:04 CST(-0600)] <colinclark> yes
[08:49:11 CST(-0600)] <colinclark> Okay, so clarify...
[08:49:21 CST(-0600)] <colinclark> I think we'll need SVN for two things, going forward
[08:49:38 CST(-0600)] <colinclark> 1. Our design repository
[08:49:50 CST(-0600)] <colinclark> 2. A mirror of git in SVN
[08:49:54 CST(-0600)] <colinclark> #2 is actually debatable
[08:50:05 CST(-0600)] <colinclark> justin_o, jessm: Do you agree with either 1 or 2 or both?
[08:50:15 CST(-0600)] <justin_o> yes
[08:50:22 CST(-0600)] <colinclark> justin_o: Both?
[08:50:46 CST(-0600)] <jessm> 1. y i think 2. no i think
[08:50:49 CST(-0600)] <justin_o> i agree that #2 is debatable... it's probably only useful for people who want to use svn externals to pull our code in
[08:50:54 CST(-0600)] <colinclark> Okay, cool
[08:50:58 CST(-0600)] <colinclark> so let's unpack #2
[08:51:20 CST(-0600)] <colinclark> justin_o: You just gave one reason--svn externals as a convenience
[08:51:28 CST(-0600)] <colinclark> Any other reasons you can think of for #2?
[08:51:41 CST(-0600)] <colinclark> An escape hatch if git gets messy for some reason, I guess?
[08:52:34 CST(-0600)] <justin_o> colinclark: you mean if we want to revert back to svn?
[08:52:51 CST(-0600)] <colinclark> Well, that's a possibility, though I was more thinking if there are any quirks along the way
[08:53:00 CST(-0600)] <colinclark> I think I feel pretty committed to making the move
[08:53:09 CST(-0600)] <colinclark> although I guess we still haven't tested sub repositories?
[08:54:09 CST(-0600)] <justin_o> not really... i did some more research on them... i don't think they quite work like externals... there are a couple of ways to do it, but they are pretty much only viable as readonly solutions...
[08:54:15 CST(-0600)] <colinclark> ok
[08:54:20 CST(-0600)] <colinclark> interesting
[08:54:47 CST(-0600)] <colinclark> i guess we might have to pursue the argument that these are things we don't need as much as we think
[08:55:09 CST(-0600)] <justin_o> yes.. that's true
[08:55:51 CST(-0600)] <colinclark> Okay, so
[08:56:01 CST(-0600)] <colinclark> Any other arguments for #2 that you can think of, jessm or justin_o?
[08:56:07 CST(-0600)] <colinclark> I feel some consensus will rock
[08:57:29 CST(-0600)] <justin_o> colinclark: as an arguement against.. i don't know how the link back to svn from git works.. so i'm not sure how it will handle multiple git repositories pushing to a single svn repo
[08:59:48 CST(-0600)] <colinclark> right
[08:59:53 CST(-0600)] <colinclark> that would be complex
[09:00:00 CST(-0600)] <colinclark> okay, so let me attempt a vote
[09:00:08 CST(-0600)] <colinclark> We're going dive into this fully
[09:00:22 CST(-0600)] <colinclark> So we need to retain a live SVN for design work
[09:00:23 CST(-0600)] <colinclark> and that's it
[09:00:30 CST(-0600)] <colinclark> No mirror back to SVN
[09:00:42 CST(-0600)] <colinclark> Our users will have to quickly adapt to a fairly abrupt change to git
[09:00:46 CST(-0600)] <colinclark> just as we are
[09:02:30 CST(-0600)] <justin_o> colinclark: will the frozen version of svn be webaccessible?
[09:02:45 CST(-0600)] <colinclark> I guess that's something we can debate
[09:02:59 CST(-0600)] <colinclark> there are advantages and disadvantages to it
[09:03:05 CST(-0600)] <colinclark> but presumably we'd want to keep it around for a little bit
[09:03:14 CST(-0600)] <colinclark> it's just that we can't leave it around as-is, or it'll be confusing
[09:05:40 CST(-0600)] <justin_o> colinclark: yep
[09:05:55 CST(-0600)] <colinclark> Well, I guess this is sort of lazy consensus in action
[09:06:03 CST(-0600)] <justin_o> so for keeping design alive, we'd just delete all the other directories?
[09:06:19 CST(-0600)] <colinclark> justin_o: I guess we have two approaches
[09:06:41 CST(-0600)] <colinclark> a) Make a big fat backup and store it really safe, and then just keep going (i.e. delete everything but design)
[09:07:33 CST(-0600)] <colinclark> b) make a new repository specifically for design and keep the other one around, visible, frozen, and extremely prominently labeled
[09:07:51 CST(-0600)] <colinclark> The advantage to b) is that it keeps everything visible and convenient
[09:08:08 CST(-0600)] <colinclark> the disadvantage, I guess, is that it keep it visible and thus raises the potential for confusion
[09:08:16 CST(-0600)] <colinclark> justin_o: Any thoughts about that?
[09:09:35 CST(-0600)] <justin_o> hmm... in a way i think a) is nice because you can still get access to all the history and just have one repo live
[09:10:05 CST(-0600)] <colinclark> jessm: any thoughts, as a non-SVN user (mostly)?
[09:10:14 CST(-0600)] <colinclark> in terms of confusion vs. transparency, i guess
[09:10:20 CST(-0600)] <jessm> (tongue)
[09:10:29 CST(-0600)] <justin_o> we could even provide a link to the prior version of the source, before the move to make it easier for people
[09:10:31 CST(-0600)] <colinclark> The downside to a) is that we have to get an admin to dig up a backup if we ever need it
[09:11:09 CST(-0600)] <justin_o> colinclark: here's an example of pointing at an old revision through the web
[09:11:09 CST(-0600)] <justin_o> http://source.fluidproject.org/svn/!svn/bc/1/
[09:11:15 CST(-0600)] <jessm> i'd like to hear from some designers re: how much they reference SVN as they're moving forward with design thinking
[09:11:22 CST(-0600)] <colinclark> justin_o: !!!
[09:11:25 CST(-0600)] <colinclark> It's revision 1!
[09:11:27 CST(-0600)] <colinclark> (smile)
[09:11:39 CST(-0600)] <justin_o> (smile)
[09:11:53 CST(-0600)] <colinclark> So, I guess you're really saying that a) and b) are sort of the same
[09:11:53 CST(-0600)] <justin_o> you can just change the number in the url to see the repo at any given revision
[09:11:59 CST(-0600)] <justin_o> colinclark: yep
[09:12:06 CST(-0600)] <colinclark> I can sign on to that
[09:12:14 CST(-0600)] <colinclark> Okay, so I'm +1 for a)
[09:12:35 CST(-0600)] <justin_o> me too, +1
[09:12:42 CST(-0600)] <colinclark> justin_o: My SVN wizardry stops at this point, so perhaps you know...
[09:12:57 CST(-0600)] <colinclark> is there an easy way, given a repository, to find out what "used to be here?"
[09:13:06 CST(-0600)] <colinclark> You can't run log on a remote repo, right?
[09:13:23 CST(-0600)] <colinclark> Would I just check out the root and then run a log there?
[09:13:24 CST(-0600)] <jessm> justin_o: what are folks putting on JIRAs they're just closing in clean-up?
[09:13:50 CST(-0600)] <colinclark> What I'm getting at is, in 5 years, once I've forgotten the names of everything that used to be in SVN, how would I know where to go to dig up some history?
[09:13:51 CST(-0600)] <justin_o> colinclark: you can run log on a remote repo
[09:13:56 CST(-0600)] <colinclark> really?
[09:13:57 CST(-0600)] <colinclark> wowza
[09:14:00 CST(-0600)] <colinclark> lemme try that
[09:14:07 CST(-0600)] <justin_o> that's how i made my history file
[09:14:13 CST(-0600)] <justin_o> svn log url
[09:14:21 CST(-0600)] <colinclark> dude, you rule
[09:14:25 CST(-0600)] <colinclark> even if SVN does not
[09:14:29 CST(-0600)] <colinclark> okay
[09:14:37 CST(-0600)] <colinclark> So I'm wholeheartedly a +1 on a)
[09:15:06 CST(-0600)] <justin_o> jessm: depends on the jira i guess... i think jhung was putting incomplete on old tasks that wouldn't be done any more
[09:15:08 CST(-0600)] <colinclark> Okay, so I think we've made some progress. We are now saying:
[09:15:25 CST(-0600)] <colinclark> 1. We're not going to do a live mirror from git to SVN
[09:15:36 CST(-0600)] <jessm> justin_o: "incomplete" and then closing them?
[09:15:49 CST(-0600)] <justin_o> jessm: yes, i believe so
[09:15:57 CST(-0600)] <colinclark> 2. We're going to, once we've made the move, prune down the entire current SVN repository down to just the design space (and anything else we need, which is so far probably nothing)
[09:16:02 CST(-0600)] <colinclark> justin_o: Did I get that right?
[09:16:24 CST(-0600)] <justin_o> colinclark: looks right
[09:16:55 CST(-0600)] <jhung> jessm, and justin_o: yes. Old tasks that weren't going to get done were closed with "incomplete". In the comment I would say something to the effect of: "Orphaned work - closing."
[09:17:20 CST(-0600)] <colinclark> Poor, sad JIRA orphans
[09:17:39 CST(-0600)] <colinclark> Okay, justin_o, can I bother you for a few more questions?
[09:17:52 CST(-0600)] <justin_o> colinclark: sure
[09:17:57 CST(-0600)] <colinclark> This is a more general one
[09:17:59 CST(-0600)] <jhung> colinclark: it's okay, they have a lot of company. (smile)
[09:18:14 CST(-0600)] <colinclark> Can you summarize what's left on our plate for git?
[09:18:17 CST(-0600)] <colinclark> justin_o: ^
[09:19:04 CST(-0600)] <justin_o> okay..
[09:19:27 CST(-0600)] <justin_o> 1) determine what can be pruned during our move to git (what we won't move there)
[09:19:35 CST(-0600)] <justin_o> 2) determine how to separate the repos
[09:19:37 CST(-0600)] <jessm> anastasiac: can you take a look at the filter for "Wiki" jiras – i think a lot of these can be closed and/or merged into doc work you're taking on. perhaps you and i can garden together?
[09:19:57 CST(-0600)] <anastasiac> jessm, I'll have a look and ping you if I need a hand
[09:19:59 CST(-0600)] <justin_o> 3) finish mapping out all the directory moves in our current repo, to help move history to git
[09:20:21 CST(-0600)] <colinclark> I'm pretty excited about #3
[09:20:25 CST(-0600)] <colinclark> I know it's been a bit of a pain
[09:20:29 CST(-0600)] <justin_o> 4) freeze svn, export to git and post to github
[09:20:34 CST(-0600)] <colinclark> but it should mean that we'll get 100% history, right?
[09:20:50 CST(-0600)] <colinclark> 5) Wait a certain amount of time, then delete stuff from SVN?
[09:20:56 CST(-0600)] <justin_o> 5) update infrastructre, build site, builder, testswarm etc to use git
[09:20:58 CST(-0600)] <colinclark> 6) Offer a workshop in how to use git?
[09:21:04 CST(-0600)] <colinclark> ok
[09:21:20 CST(-0600)] <justin_o> yep i think that's it
[09:21:22 CST(-0600)] <colinclark> Does continuum support git okay?
[09:21:41 CST(-0600)] <justin_o> i think so.. but let me do a quick double check.. we may have to move over to the latest version
[09:21:46 CST(-0600)] <colinclark> ok
[09:22:10 CST(-0600)] <colinclark> this might push us to finally tidy up our build infrastructure and move more things over to forge
[09:22:21 CST(-0600)] <jessm> anastasiac: refresh (smile) i think i'm plucking weeds
[09:22:22 CST(-0600)] <colinclark> which is not a bad thing at all, but might take us longer
[09:22:32 CST(-0600)] <anastasiac> will do, jessm
[09:23:35 CST(-0600)] <justin_o> colinclark: doesn't look like it works with git
[09:23:42 CST(-0600)] <colinclark> ok
[09:23:43 CST(-0600)] <justin_o> http://continuum.apache.org/features.html
[09:23:49 CST(-0600)] <justin_o> http://old.nabble.com/git-in-continuum-td17631457.html
[09:23:56 CST(-0600)] <colinclark> So this suggests either:
[09:24:05 CST(-0600)] <colinclark> i) An SVN mirror of git
[09:24:13 CST(-0600)] <colinclark> ii) Moving from Continuum to Something Else
[09:24:20 CST(-0600)] <justin_o> oh actually
[09:24:22 CST(-0600)] <justin_o> http://apache-continuum.blogspot.com/
[09:24:35 CST(-0600)] <justin_o> looks like it has git support as of Continuum 1.2
[09:24:40 CST(-0600)] <jessm> jamon: i'm going to assign a tiny jira to you re: the favicon in the wiki
[09:24:57 CST(-0600)] <colinclark> cool, justin_o
[09:25:01 CST(-0600)] <colinclark> scratch my roman numerals (smile)
[09:25:09 CST(-0600)] <colinclark> they are irrelevant
[09:25:42 CST(-0600)] <justin_o> (smile)
[09:26:27 CST(-0600)] <justin_o> So we will have to move over to forge, but that will be good, we can keep the other one running off of the frozen svn till we get the git build working
[09:26:33 CST(-0600)] <justin_o> so there doesn't appear to be down time
[09:26:50 CST(-0600)] <colinclark> makes sense
[09:26:53 CST(-0600)] <colinclark> Have y'all seen the new HTML5 logo yet? It was getting a lot of buzz... and mocking... on Twitter a few days ago. http://www.w3.org/html/logo/
[09:28:13 CST(-0600)] <colinclark> jessm: Are you impressed with my tendency towards "y'all" recently?
[09:28:35 CST(-0600)] <justin_o> colinclark: yes.. i saw it.. i didn't really like it myself
[09:28:37 CST(-0600)] <justin_o> what do you think
[09:28:43 CST(-0600)] <jessm> colinclark: i'm most proud that you get the punctuation right!
[09:28:48 CST(-0600)] <colinclark> (smile)
[09:28:52 CST(-0600)] <colinclark> Grammar is everything
[09:29:07 CST(-0600)] <colinclark> justin_o: I don't think it's super awesome, myself
[09:29:47 CST(-0600)] <colinclark> Here's a link to a whole whack of parodies: http://www.businessinsider.com/html5-logo-funny-2011-1#first-the-official-logo-1
[09:30:08 CST(-0600)] <colinclark> people are really nerdy
[09:32:06 CST(-0600)] <justin_o> (smile) i like the autobot one
[09:32:12 CST(-0600)] <justin_o> they should totally switch to that
[09:32:30 CST(-0600)] <justin_o> http://www.businessinsider.com/html5-logo-funny-2011-1#pretty-obvious-transformers-parody-2
[09:33:42 CST(-0600)] <colinclark> (smile)
[09:34:18 CST(-0600)] <colinclark> So, justin_o, from your git list, are there any specific to-dos that you'd like to put on my plate?
[09:34:27 CST(-0600)] <colinclark> I'm just taking a look at my own to-do list and trying to make it sane
[09:35:27 CST(-0600)] <justin_o> colinclark: i think 1 and 2... if you can talk to jamon and or I about it... i'm trying to finish up mapping out all the changes and moves and stuff
[09:35:36 CST(-0600)] <colinclark> ok
[09:35:53 CST(-0600)] <justin_o> i think once that's done we should have a good idea of what code came from where
[09:35:55 CST(-0600)] <heidi_> colinclark i'm streamlining the uploader css this morning, then was thinking of getting deeper into fss to-do listing. does that sound good? justin_o unless you need more ppl on jira gardening/code fixing
[09:36:15 CST(-0600)] <colinclark> heidi_: That sounds great to me
[09:36:22 CST(-0600)] <heidi_> okee doke
[09:36:41 CST(-0600)] <justin_o> heidi_: for jira gardening stuff... michelled had a good idea of only spending about 10min or so on it a day
[09:37:00 CST(-0600)] <heidi_> that is a good idea, i can do that too
[09:37:33 CST(-0600)] <heidi_> btw justin_o , hope you're ankle heals quickly
[09:37:37 CST(-0600)] <heidi_> *your
[09:38:45 CST(-0600)] <justin_o> heidi_: thanks... i hope to be in decent shape by the weekend.. really hoping I can play sports again next week
[09:39:01 CST(-0600)] <heidi_> yeah, just take it easy!
[09:39:05 CST(-0600)] <colinclark> Everyone here might be interested in the fact that NVDA is struggling a bit at the moment. They have a blog post up about it: http://www.nvda-project.org/blog/NVDANeedsYou
[09:41:28 CST(-0600)] <justin_o> heidi_: thanks
[09:41:59 CST(-0600)] <justin_o> colinclark: those guys are doing a lot of work for minimum wage... that's pretty dedicated
[09:42:08 CST(-0600)] <colinclark> It's pretty amazing, yes
[09:45:02 CST(-0600)] <jamon> jessm: i see the jira, will do
[09:45:40 CST(-0600)] <heidi_> hey colinclark in Uploader.css there are some "Deprecated: fl-ProgEnhanced-" styles - is there a reason to keep them?
[09:50:39 CST(-0600)] <Bosmon2> TRIA!
[09:50:40 CST(-0600)] <Bosmon2> MAZI!
[09:50:42 CST(-0600)] <Bosmon2> KAMNO!
[10:02:31 CST(-0600)] <colinclark> heidi_: Can you check if the are defined elsewhere in the FSS?
[10:02:41 CST(-0600)] <mlam> Bosmon2: colinclark suggested I talk to you about your "async each" function. i tried finding it in the framework, but no luck. could you point me to where i could find it and maybe give me a brief run down of it?
[10:02:54 CST(-0600)] <Bosmon2> Hi there mlam
[10:02:59 CST(-0600)] <Bosmon2> It is only in kettle for now
[10:03:05 CST(-0600)] <Bosmon2> Where it was initially needed
[10:03:21 CST(-0600)] <mlam> It sounds like something I may need in the uploader
[10:03:35 CST(-0600)] <Bosmon2> http://source.fluidproject.org/svn/fluid/engage/fluid-engage-kettle/branches/kettle-node/src/main/webapp/kettle/js/V8LoaderMain.js
[10:03:42 CST(-0600)] <Bosmon2> Interesting
[10:04:02 CST(-0600)] <Bosmon2> We almost needed it in Fluid Engage, to deal with what looked like a script load timing issue on the iPad
[10:04:13 CST(-0600)] <Bosmon2> But as it turned out, the issue was even less regular than we feared...
[10:04:25 CST(-0600)] <heidi_> colinclark just looks like .fl-ProgEnhance-basic has been changed to .fl-progEnhance-basic (small p) ... not sure why old styles were kept. they're also present/deprecated in fss-layout.css but i'll double check they're no longer used
[10:04:27 CST(-0600)] <mlam> The HTML5 uploader currently uploads files asynchronously, but we want it to upload synchronously
[10:04:38 CST(-0600)] <Bosmon2> Ah of course
[10:04:51 CST(-0600)] <Bosmon2> So yes, you would want a set of chained asynchronous events, one after the other....
[10:04:59 CST(-0600)] <Bosmon2> How interesting (tongue)
[10:05:01 CST(-0600)] <mlam> so if we had a function that would allow us to wait for an asynchronous process to complete, then we'd be in business
[10:05:18 CST(-0600)] <mlam> Does the async each do this?
[10:05:24 CST(-0600)] <Bosmon2> Beware that this "iterator" requires you to convert all the code above and below it to a certain distance to the "continuation passing style"
[10:05:25 CST(-0600)] <Bosmon2> yes, it does
[10:06:07 CST(-0600)] <mlam> what do you mean by "certain distance to the "continuation passing style""
[10:06:09 CST(-0600)] <mlam> ?
[10:06:29 CST(-0600)] <Bosmon2> Did you do a CS degree? I wonder if they still teach the "continuation passing style" any more (tongue)
[10:06:55 CST(-0600)] <mlam> No CS degree
[10:07:00 CST(-0600)] <Bosmon2> http://en.wikipedia.org/wiki/Continuation-passing_style
[10:07:12 CST(-0600)] <Bosmon2> http://marijnhaverbeke.nl/cps/
[10:07:16 CST(-0600)] <Bosmon2> Here are a couple of references
[10:07:31 CST(-0600)] <Bosmon2> You can see some of the code near the bottom of the file I referenced in SVN has been induced to be in this style (tongue)
[10:07:56 CST(-0600)] <Bosmon2> Once you get far enough away from the stack frame where the craziness happens, you can start writing normal code again (tongue)
[10:10:02 CST(-0600)] <mlam> Thanks for the links. Do you think this function is something that will be added to framework?
[10:12:17 CST(-0600)] <colinclark> heidi_: The reason the old styles were kept was for backwards compatibility. Remember, after 1.0 we committed to not breaking people's code, and the progressive enhancement styles were FSS-wide
[10:12:32 CST(-0600)] <colinclark> but given that, I'm somewhat confused as to why Uploader.css overrides them
[10:12:41 CST(-0600)] <colinclark> Looking at the styles, heidi_, is it clear to you?
[10:12:46 CST(-0600)] <Bosmon2> mlam - if you use it in uploader, it will be
[10:13:04 CST(-0600)] <Bosmon2> Our rule is that things end up in Fluid.js if they are used in 2 or more distinct places (tongue)
[10:13:05 CST(-0600)] <heidi_> colinclark i think they can go in uploader.css, since they're no longer used in uploader
[10:13:23 CST(-0600)] <colinclark> michelled: Did they teach you about Continuations when you learned Scheme programming at Ryerson?
[10:13:45 CST(-0600)] <colinclark> They certainly didn't teach continuations in my music composition classes (tongue)
[10:13:59 CST(-0600)] <colinclark> heidi_: Cool, go for it
[10:14:05 CST(-0600)] <Bosmon2> I guess Michael Haydn didn't feature in your composition classes (smile)
[10:14:09 CST(-0600)] <michelled> colinclark: no they didn't. I think one of the profs may have mentioned them in passing
[10:14:13 CST(-0600)] <Bosmon2> I always feel he uses the musical equivalent of continuations (tongue)
[10:15:27 CST(-0600)] <colinclark> I think the oldest music we actively studied in composition was Schoenberg
[10:16:03 CST(-0600)] <colinclark> I guess my first class with Tenney involved him playing a Bach piece on the piano and expecting us to transcribe it by ear
[10:16:17 CST(-0600)] <Bosmon2> Interesting
[10:16:39 CST(-0600)] <colinclark> He was actually teaching us calligraphy, not Bach
[10:16:45 CST(-0600)] <Bosmon2> (smile)
[10:16:52 CST(-0600)] <colinclark> mlam: What did you do your degree in, anyway?
[10:17:03 CST(-0600)] <colinclark> I figured you were a CS type
[10:17:41 CST(-0600)] <mlam> Biology (smile)
[10:17:45 CST(-0600)] <colinclark> ahh
[10:17:47 CST(-0600)] <colinclark> I had no idea!
[10:17:54 CST(-0600)] <colinclark> heidi_, you did CS at Guelph, right?
[10:17:59 CST(-0600)] <heidi_> yep
[10:18:06 CST(-0600)] <mlam> I think I took a total of 3 CS courses?
[10:18:29 CST(-0600)] <colinclark> Did they teach functional programming, like in Scheme or Lisp, at Guelph?
[10:18:58 CST(-0600)] <Bosmon2> It's odd, since all I took away from my functional programming courses was that it seemed totally impractical and that I hated it
[10:19:19 CST(-0600)] <colinclark> ha!
[10:19:42 CST(-0600)] <Bosmon2> But I guess it was perfectly clear that none of that community approved of functional programming because it helped anyone to achieve any practical effect (tongue)
[10:19:49 CST(-0600)] <Bosmon2> But, regardless of their attitude, it actually does (tongue)
[10:20:06 CST(-0600)] <heidi_> colinclark i thinkkk we did lisp
[10:20:17 CST(-0600)] <heidi_> i might have an oreilly book for it
[10:20:29 CST(-0600)] <heidi_> oh no i'm thinking lex & yacc
[10:20:40 CST(-0600)] <Bosmon2> This Dutch guy makes the important point about the CPS - "A function in continuation-passing style can call regular functions with no ill effects."
[10:20:45 CST(-0600)] <Bosmon2> But the reverse is not true
[10:21:22 CST(-0600)] <Bosmon2> Once we start moving over to Node, expect to be seeing this style more and more in your code....
[10:21:26 CST(-0600)] <colinclark> I was saying mlam yesterday, after the Node.js chat, that concurrency is really pushing the practical value of functional programming
[10:21:29 CST(-0600)] <Bosmon2> At least, so far as we actually write any code at all (tongue)
[10:21:40 CST(-0600)] <Bosmon2> Our big advantage in Fluid is that we oppose the writing of code
[10:22:02 CST(-0600)] <Bosmon2> So if there is not code, whether or not it is in the CPS is irrelevant (tongue)
[10:22:22 CST(-0600)] <colinclark> (smile)
[10:22:34 CST(-0600)] <colinclark> I was sort of admiring the Pager tutorial today
[10:22:43 CST(-0600)] <Bosmon2> Really...
[10:22:50 CST(-0600)] <colinclark> realizing that despite making reference to "the code," it was actually just all configuration
[10:23:00 CST(-0600)] <Bosmon2> aha
[10:23:09 CST(-0600)] <michelled> anastasiac: I'm looking at the escalated tests right now and there is one in there relating to the jquery tabs example and tabbing in opera. I can't seem to find a JIRA about the actual issue - do you know if there is one?
[10:23:28 CST(-0600)] <colinclark> So heidi_, something occurred to me recently
[10:23:40 CST(-0600)] <colinclark> One more thing to add to your to do list, indirectly related to the Uploader work
[10:23:42 CST(-0600)] <anastasiac> michelled, not offhand, I'd have to search
[10:23:49 CST(-0600)] <colinclark> So we've added two new classes to the FSS for scrolling tables
[10:23:57 CST(-0600)] <heidi_> yes
[10:23:59 CST(-0600)] <colinclark> We should take a bit of time to review the styles, make sure they're nicely general-purpose
[10:24:06 CST(-0600)] <colinclark> that they match the naming conventions
[10:24:12 CST(-0600)] <heidi_> yeah
[10:24:17 CST(-0600)] <Bosmon2> "So, we've created code that does exactly the same as the earlier version, but is twice as confusing."
[10:24:17 CST(-0600)] <colinclark> and then add an example of their use to the FSS demo
[10:24:23 CST(-0600)] <Bosmon2> This Dutch guy has good style (tongue)
[10:24:28 CST(-0600)] <heidi_> good idea
[10:24:33 CST(-0600)] <colinclark> Cool
[10:25:00 CST(-0600)] <heidi_> colinclark i'll make a jira for that
[10:25:05 CST(-0600)] <colinclark> Thanks, heidi_
[10:25:10 CST(-0600)] <mlam> so, Bosmon2, colinclark: do you both think that the asyncEach is something we should be using for the uploader?
[10:25:24 CST(-0600)] <colinclark> Well, I guess we can ask the obvious question...
[10:25:50 CST(-0600)] <colinclark> Will asyncEach allow you to "chain" successive Ajax calls so that when one completes (successfully or not), the next starts up?
[10:25:59 CST(-0600)] <Bosmon2> Well Mike - try it out, and see (tongue)
[10:26:01 CST(-0600)] <colinclark> If the answer is yes, then I don't seen any obvious reason why not
[10:26:05 CST(-0600)] <colinclark> That makes sense
[10:26:07 CST(-0600)] <Bosmon2> "I can see no reason why it shouldn't work" (tongue)
[10:26:20 CST(-0600)] <colinclark> This is one of those cases where your tongues seem sort of ambiguous, Bosmon2
[10:26:29 CST(-0600)] <Bosmon2> ah, sorry
[10:26:31 CST(-0600)] <colinclark> But I guess this are the genuine interpretation
[10:26:31 CST(-0600)] <colinclark> no no
[10:26:48 CST(-0600)] <colinclark> I'm actually realizing that your tongue is sort of "go for it" rather than "duh"
[10:26:51 CST(-0600)] <colinclark> If that makes sense
[10:26:52 CST(-0600)] <colinclark> (smile)
[10:26:53 CST(-0600)] <Bosmon2> Yes
[10:27:04 CST(-0600)] <Bosmon2> Yes, it is (tongue)
[10:27:07 CST(-0600)] <colinclark> In that case..
[10:27:09 CST(-0600)] <colinclark> mlam: (tongue)
[10:27:34 CST(-0600)] <Bosmon2> You can never quite anticipate all the results when applying some piece of code to a problem...
[10:27:42 CST(-0600)] <Bosmon2> But all the evidence suggests that this might be an appropriate strategy (tongue)
[10:27:57 CST(-0600)] <mlam> Ok, I'll give it a shot (smile)
[10:28:06 CST(-0600)] <mlam> or should i say, (tongue) ?
[10:28:09 CST(-0600)] <colinclark> (tongue)
[10:29:26 CST(-0600)] <Bosmon2> (smile)
[11:04:46 CST(-0600)] <colinclark> harriswong: What's the JIRA number for the Uploader error messages issue you're working on?
[11:05:02 CST(-0600)] <harriswong> colinclark: i believe it's #3878
[11:05:24 CST(-0600)] <colinclark> thanks
[11:06:09 CST(-0600)] <harriswong> colinclark: np~
[11:15:15 CST(-0600)] <colinclark> hey mlam, what's the JIRA number you filed for the dorky issue athena pointed out?
[11:15:27 CST(-0600)] <colinclark> i.e. the fact that specifying a fileUploadLimit throws an exception?
[11:15:35 CST(-0600)] <mlam> colinclark: i believe it's FLUID-4033
[11:15:57 CST(-0600)] <colinclark> cool, thanks
[11:16:53 CST(-0600)] <mlam> np
[11:24:45 CST(-0600)] <colinclark> justin_o: I bounced the fix version of http://issues.fluidproject.org/browse/FLUID-3725 from 1.3.1 to 1.4
[11:24:52 CST(-0600)] <colinclark> It's something we might sneak in
[11:25:10 CST(-0600)] <colinclark> but I think it's probably best not to distract ourselves with it in terms of our solid list of to dos for 1.3.1
[11:26:03 CST(-0600)] <justin_o> colinclark: okay... that makes sense
[11:26:18 CST(-0600)] <colinclark> I'm just filing one for renderizing the Uploader and will do the same
[11:26:35 CST(-0600)] <colinclark> File it for 1.4 but we can look at our progress and decide whether or not to sneak it in at some point
[11:26:48 CST(-0600)] <colinclark> I'll relate the two since one is a dependency of the other
[11:28:57 CST(-0600)] <justin_o> colinclark: okay.. thanks
[11:38:40 CST(-0600)] <colinclark> justin_o: Okay, I just sent along my Top 5 list
[11:38:45 CST(-0600)] <colinclark> I totally broke all the rules, I suck
[11:39:01 CST(-0600)] <colinclark> But I can probably almost get back within the five item limit by committing some patches from mlam and heidi_
[11:39:16 CST(-0600)] <colinclark> Hey Heidi, any chance you could make me a patch with your code and markup changes?
[11:39:22 CST(-0600)] <heidi_> hey mlam, when initialising the uploader demo, it uses var templateURLSelector = "../../../components/uploader/html/Uploader.html .fl-uploader"; ... which means everything inbetween fl-uploader is the template. is that right?
[11:39:25 CST(-0600)] <justin_o> colinclark: thanks
[11:39:29 CST(-0600)] <colinclark> separate from the CSS cleanup, I mean
[11:39:40 CST(-0600)] <heidi_> colinclark yep i posted it yesterday
[11:39:43 CST(-0600)] <colinclark> thanks!
[11:39:44 CST(-0600)] <heidi_> on the jira
[11:39:48 CST(-0600)] <colinclark> awesome
[11:40:03 CST(-0600)] <heidi_> colinclark am i right about what i just asked mlam?
[11:40:10 CST(-0600)] <colinclark> heidi_: Yep
[11:40:30 CST(-0600)] <colinclark> jQuery.load() takes a string with two "sub-arguments." It's a horrible syntax.
[11:40:35 CST(-0600)] <colinclark> The first is the URL to load the markup from
[11:40:49 CST(-0600)] <heidi_> okay, so the div with id="uploader-contents" in Uploader.html doesn't matter
[11:40:59 CST(-0600)] <colinclark> oh, wait, sorry
[11:41:02 CST(-0600)] <heidi_> it's for showing Uploader.html on it's own
[11:41:02 CST(-0600)] <colinclark> I am being confusing
[11:41:40 CST(-0600)] <colinclark> Okay, so the code looks like this:
[11:41:52 CST(-0600)] <colinclark> $("#uploader-contents").load("../../../components/uploader/html/Uploader.html .fl-uploader")
[11:41:59 CST(-0600)] <colinclark> So, the first bit...
[11:42:10 CST(-0600)] <heidi_> is the div to dump the contents into
[11:42:13 CST(-0600)] <colinclark> $("#uploader-contents") is where we want to load the markup into
[11:42:14 CST(-0600)] <colinclark> yep
[11:42:25 CST(-0600)] <colinclark> The second bit is the horrible syntax part. I have no idea what jQuery was thinking
[11:42:34 CST(-0600)] <colinclark> but anyway, that second bit of the argument to .load()
[11:42:46 CST(-0600)] <colinclark> That's the selector from which to pull markup from the source document
[11:43:00 CST(-0600)] <colinclark> So we're saying here:
[11:43:31 CST(-0600)] <colinclark> "Grab .fl-uploader and everything inside it from the source URL, and inject it into #uploader-contents in this document"
[11:43:34 CST(-0600)] <colinclark> Does that make sense?
[11:43:54 CST(-0600)] <colinclark> In short, we're grabbing that whole Uploader form from the "template" and jamming into the demo's page.
[11:44:07 CST(-0600)] <heidi_> yep, thanks. just confirming that the "uploader-contents" div in Uploader.html isn't being used outside of ... Uploader.html
[11:44:14 CST(-0600)] <heidi_> er wait
[11:45:05 CST(-0600)] <heidi_> i think that's true
[11:45:55 CST(-0600)] <heidi_> basically "uploader-contents" in Uploader.html is purely for styling. and in the demo "uploader-contents" is the thing to load uploader into.
[11:47:05 CST(-0600)] <colinclark> I guess that's roughly true
[11:47:18 CST(-0600)] <colinclark> In the demo, presumably it's not only the thing to load uploader into, but also used for styling
[11:47:24 CST(-0600)] <colinclark> But I don't know that for sure
[11:47:37 CST(-0600)] <colinclark> All if this dorkiness will go away if we fix http://issues.fluidproject.org/browse/FLUID-4038
[11:47:41 CST(-0600)] <heidi_> it might be using the styling from Uploader.css but it's kinda weird
[11:47:52 CST(-0600)] <colinclark> Weird how?
[11:48:19 CST(-0600)] <heidi_> for the demo to depend on a style for a div that doesn't get used in uploader itself
[11:48:47 CST(-0600)] <heidi_> .fl-uploader excludes its parent div, uploader-contents
[11:49:27 CST(-0600)] <colinclark> yeah
[11:50:07 CST(-0600)] <colinclark> What we're saying, implicitly, is that if you aren't cutting and pasting the whole template into your page, you have to Ajax it into a container called #uploader-contents in order for all the styling to work nicely
[11:50:10 CST(-0600)] <colinclark> It's not ideal
[11:50:17 CST(-0600)] <colinclark> again, FLUID-4038 is the real solution
[11:50:32 CST(-0600)] <colinclark> we should not be asking people to load templates ad-hoc like this at all
[11:50:38 CST(-0600)] <colinclark> and cut and paste sucks even worse
[11:51:07 CST(-0600)] <colinclark> mlam: Can you do me a super quick favour?
[11:51:23 CST(-0600)] <heidi_> yeah. i think what i will do is replace uploader-contents in Uploader.html with fl-container class, and move the uploader-contents style into the demo css.. tho there isn't a css file in demo for uploader.
[11:51:31 CST(-0600)] <colinclark> Can you set any JIRAs you've got a patch for, or that you're currently working on, as "in progress"?
[11:52:14 CST(-0600)] <colinclark> heidi_: I don't fully understand. Will this help everyone who is using Uploader in the way the demo shows?
[11:52:28 CST(-0600)] <colinclark> Or will it then mean that they'll have to link to the demo's style sheet? (Which seems like a drag)
[11:54:16 CST(-0600)] <colinclark> justin_o: Do you know if there is a way to search for JIRAs that have attachments?
[11:55:17 CST(-0600)] <justin_o> not off hand, but i'll take a quick look
[11:56:39 CST(-0600)] <heidi_> hm, i was just trying to clarify the significance of "uploader-contents" in Uploader.html, and demo uploader.html. They do two diff things... but are weirdly dependent on each other.
[11:57:14 CST(-0600)] <heidi_> 1) Uploader.html by using that div name as a container is abstractedly demonstrating the final product , but also for styling and 2) using it as the actual container to dump uploader into
[11:57:53 CST(-0600)] <heidi_> i initially just wanted to get rid of "uploader-contents" in Uploader.html and replace with an fss container style
[11:58:32 CST(-0600)] <heidi_> i'm not sure i'm explaining this well
[11:59:43 CST(-0600)] <colinclark> I think I see what you're getting at
[11:59:55 CST(-0600)] <colinclark> The key is that our demos are instructive
[12:00:06 CST(-0600)] <colinclark> We're telling our users, "this is the way to use Uploader"
[12:00:12 CST(-0600)] <colinclark> So whatever it does, should work for them
[12:00:22 CST(-0600)] <colinclark> without them actually having to link to the demo itself
[12:00:39 CST(-0600)] <colinclark> So if you want to get rid of uploader-contents in Uploader.html, that's probably fine
[12:00:59 CST(-0600)] <heidi_> phew, will do
[12:01:05 CST(-0600)] <colinclark> We're going to have to show in the demo how they will need to put a .fl-container class on whatever the Uploader's container will be in their markup
[12:01:08 CST(-0600)] <colinclark> Do you see what I mean?
[12:01:22 CST(-0600)] <heidi_> it just confused me cos i wondered if something was getting dumped into Uploader.html the same way it was in uploader.html
[12:01:34 CST(-0600)] <colinclark> nope
[12:01:50 CST(-0600)] <colinclark> All of this is a dorky workaround to the fact that Uploader.html isn't a real template
[12:01:59 CST(-0600)] <heidi_> it actually doesn't have styles assoc with it so i'll just get rid of it
[12:02:03 CST(-0600)] <colinclark> cool
[12:02:03 CST(-0600)] <colinclark> great
[12:02:28 CST(-0600)] <colinclark> mlam: I've reopened http://issues.fluidproject.org/browse/FLUID-4033. I reviewed it and the fix looks good. I think we should have some unit tests to check this behaviour before we commit the fix.
[12:02:34 CST(-0600)] <justin_o> colinclark: it doesn't look like you can search for issues that have attachments
[12:02:41 CST(-0600)] <colinclark> ok, no worries
[12:02:43 CST(-0600)] <justin_o> there are plugins that might help, but nothing out of the box
[12:02:54 CST(-0600)] <colinclark> justin_o: We have a "needs commit" resolution status, right?
[12:03:38 CST(-0600)] <justin_o> colinclark: sorry... i dropped the one we had added in before... because it didn't work so well, basically you would have to reopen the issue before you could mark it as resolved or closed
[12:03:48 CST(-0600)] <justin_o> colinclark: michelled would know more about that
[12:04:22 CST(-0600)] <justin_o> i set up a different work flow for us, but i think it will restart jira and not sure if it will break things.. i have to coordinate with jamon about making a back up and then doing the switch
[12:04:48 CST(-0600)] <justin_o> the new work flow has "needs commit" as a status i believe
[12:07:06 CST(-0600)] <colinclark> cool
[12:07:07 CST(-0600)] <colinclark> okay
[13:04:03 CST(-0600)] <jessm> anastasiac: ping
[13:08:46 CST(-0600)] <anastasiac> jessm: polo
[13:09:19 CST(-0600)] <jessm> anastasiac: this filter is all yers http://issues.fluidproject.org/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=project+%3D+FLUID+AND+resolution+%3D+Unresolved+AND+component+%3D+Wiki+ORDER+BY+priority+DESC&amp;mode=hide
[13:09:34 CST(-0600)] <anastasiac> k
[13:09:38 CST(-0600)] <jessm> anastasiac: not sure if you want to move some tasks or remark on them – where they are relevant to documentation work you'll be doing
[13:09:43 CST(-0600)] <jessm> not sure if they're relevant anymore or not
[13:09:59 CST(-0600)] <anastasiac> I'll have a look, and figure something out
[13:10:55 CST(-0600)] <anastasiac> jessm, this whole notion of a wiki component in jira got me thinking about the boundaries (or lack thereof) between our wiki, our website, our demo portal, and our (soon to come) tech docs
[13:11:08 CST(-0600)] <anastasiac> only musings so far, no solutions (smile)
[13:11:46 CST(-0600)] <jessm> anastasiac: ah, good stuff to chew on – let's chat about it at some point when it comes togehter a bit
[13:11:55 CST(-0600)] <anastasiac> yes, still chewing
[13:21:23 CST(-0600)] <jessm> anastasiac: can i also put FLUID-4001 on your plate for re-labeling?
[13:21:38 CST(-0600)] <anastasiac> sure, got it
[13:21:43 CST(-0600)] <jessm> thx!
[13:22:58 CST(-0600)] <anastasiac> justin_o, passing FLUID-1147 back to you for consideration - I've commented on it
[13:26:08 CST(-0600)] <anastasiac> jessm, 4001 has already been reviewed and updated. Still a bug...
[13:26:17 CST(-0600)] <anastasiac> it is labelled correctly
[13:26:24 CST(-0600)] <justin_o> anastasiac: i've closed out FLUID-1147
[13:26:25 CST(-0600)] <jessm> anastasiac: re: release?
[13:27:05 CST(-0600)] <anastasiac> it affects 1.3, and I don't know the priority for fixing, so not sure what the fix-for version should be - I suppose justin_o should comment on that?
[13:27:51 CST(-0600)] <anastasiac> it probably should be slotted into UIOptions timelines, since it's used by UIOptions
[13:29:32 CST(-0600)] <jessm> anastasiac: i had re-assigned 2946 to jamon and let him know earlier in the channel and he said a-ok
[13:29:35 CST(-0600)] <justin_o> anastasiac: i just put it for 1.4, since we should be working on UI Options for then
[13:29:58 CST(-0600)] <anastasiac> jessm, a-ok meaning he'll take care of it?
[13:30:01 CST(-0600)] <anastasiac> thanks, justin_o
[13:30:16 CST(-0600)] <jessm> anastasiac: yes
[13:31:04 CST(-0600)] <jessm> jamon: jessm: i see the jira, will do
[13:31:04 CST(-0600)] <jessm> [10:45]
[13:32:07 CST(-0600)] <jhung> justin_o: Forgot to tell you I'm looking at OSDPL bugs and UX Design Pattern bugs.
[13:33:40 CST(-0600)] <justin_o> jhung: thanks
[13:35:39 CST(-0600)] <anastasiac> justin_o, I'm updating all the child issues of FLUID-2280, but I note that 2280 itself is closed. Should these child issues be promoted to self-standing issues?
[13:37:08 CST(-0600)] <justin_o> anastasiac: i think so
[13:37:17 CST(-0600)] <anastasiac> k
[13:37:21 CST(-0600)] <justin_o> they don't really fit under the parent now that i read it
[13:38:57 CST(-0600)] <jessm> justin_o: i don't know that i understand FLUID-1869 but my sense is that it's no longer relevant – can you check?
[13:39:19 CST(-0600)] <colinclark> jessm: I'm actually about to fix that one
[13:39:36 CST(-0600)] <colinclark> By implementing something listed as a TODO in Heidi's most recent Uploader patch
[13:41:22 CST(-0600)] <heidi_> colinclark should i reassign the uploader markup jira to you, for reviewing?
[13:41:30 CST(-0600)] <colinclark> heidi_: Yes please!
[13:41:35 CST(-0600)] <heidi_> k
[13:41:36 CST(-0600)] <colinclark> I'll do that in a moment
[13:41:41 CST(-0600)] <colinclark> Review it, I mean
[13:42:17 CST(-0600)] <heidi_> i didn't go crazy with the .css file paring ... it's so delicate with that overlay stuff, didn't want to disturb too much
[13:48:37 CST(-0600)] <colinclark> At some point I'd really love to just really streamline
[13:48:52 CST(-0600)] <colinclark> but it makes sense not to destabilize it too much for a maintenance release, heidi_ (smile)
[13:49:01 CST(-0600)] <anastasiac> jessm, those wiki JIRAs have been reviewed, updated, commented, moved, etc. as appropriate
[13:49:25 CST(-0600)] <jessm> anastasiac: thanks
[13:55:02 CST(-0600)] <colinclark> mlam: It's an unsatisfied IoC dependency
[13:55:17 CST(-0600)] <colinclark> These things are subtle sometimes
[13:55:34 CST(-0600)] <mlam> is it something that I'm not passing properly into the options?
[13:55:49 CST(-0600)] <colinclark> I determined this, by the way, by just stepping through the debugger and noting that it was exploding on the call to fluid.initDependents()
[13:55:57 CST(-0600)] <colinclark> It is an error message we need to improve (wink)
[13:56:28 CST(-0600)] <colinclark> So if you look at line 303, the local requires a buttonView
[13:56:33 CST(-0600)] <colinclark> which you already know about
[13:56:56 CST(-0600)] <colinclark> but if you look down at the options block for the buttonView, you see that it's trying to pull a dependency from a "grandparent"
[13:57:05 CST(-0600)] <colinclark> It's looking for a container from the Uploader
[13:57:13 CST(-0600)] <colinclark> in your case, you're just testing, and you don't have an Uploader at all
[13:57:18 CST(-0600)] <jhung> justin_o: there are only 2 issues left open in the UX:Design Patterns component. I suggest we move those into the OSDPL component and close UX:DP.
[13:58:55 CST(-0600)] <colinclark> I believe you can override the options of the local to specify an "empty component" as the type of the button view
[13:59:00 CST(-0600)] <colinclark> I haven't done it in ages
[13:59:01 CST(-0600)] <colinclark> b
[13:59:09 CST(-0600)] <colinclark> but you should be able to do something along the lines of:
[13:59:10 CST(-0600)] <michelled> jhung: so, issues related to design patterns should be put against OSDPL? or the Design Handbook? or both?
[13:59:34 CST(-0600)] <jhung> michelled: Depends on the issue I think.
[13:59:54 CST(-0600)] <colinclark> mlam: { browseButtonView: { type: "fluid.emptyComponent", options: {} }
[14:00:15 CST(-0600)] <jhung> tasks specific to patterns (i.e. Update the Drag and Drop to include keyboard functionality) should probably go against OSDPL since that's where the patterns live now.
[14:00:24 CST(-0600)] <mlam> and this demands block would be placed inside the test file itself?
[14:00:43 CST(-0600)] <colinclark> This would actually just be in your options passed to the local upon instantiating it
[14:00:46 CST(-0600)] <colinclark> No demands block required
[14:01:05 CST(-0600)] <michelled> thanks jhung
[14:01:14 CST(-0600)] <colinclark> So what you're saying, in effect, is "For my browseButtonView subcomponent, instantiate as type <nothing>"
[14:01:23 CST(-0600)] <colinclark> Where <nothing> is fluid.emptyComponent
[14:01:31 CST(-0600)] <colinclark> Or a mock browseButton, if you needed such a thing
[14:01:36 CST(-0600)] <colinclark> but I doubt you will (wink)
[14:01:52 CST(-0600)] <colinclark> This is subtle stuff, so no worries if it isn't fully clear
[14:01:58 CST(-0600)] <colinclark> I can show you some code if it helps
[14:02:19 CST(-0600)] <jhung> Michelled: I guess an easy way to distinguish is that OSDPL deals with content, whereas the handbook is more ... instructional?
[14:02:27 CST(-0600)] <mlam> colinclark: yah, not fully clear yet
[14:02:33 CST(-0600)] <colinclark> k, i'll come over
[14:09:37 CST(-0600)] <mlam> thanks colinclark (smile) makes more sense now
[14:09:42 CST(-0600)] <colinclark> sweet
[14:17:46 CST(-0600)] <colinclark> mlam: I think, in the end, all of this suggests that the browse button is sort of in the wrong place
[14:17:56 CST(-0600)] <colinclark> So we have this browseButtonView, which is only implemented for HTML5
[14:18:06 CST(-0600)] <colinclark> The Flash strategy handles its button in a different way
[14:18:07 CST(-0600)] <heidi_> hey colinclark , could you clarify this issue at all? http://issues.fluidproject.org/browse/FLUID-4020 JSR 168 is a portal/portlet lib with styles i'm guessing?
[14:18:28 CST(-0600)] <colinclark> But, in Java terms, the Uploader has a strategy. And a strategy is an "interface"
[14:18:46 CST(-0600)] <colinclark> A thing that implements four methods: addFiles(), removeFiles(), enableBrowseButton() and disableBrowseButton()
[14:18:53 CST(-0600)] <colinclark> those are called by Uploader itself
[14:19:11 CST(-0600)] <colinclark> So clearly, if Uploader is going to call enableBrowseButton(), it has a concept of the fact there is a browse button there somewhere
[14:19:51 CST(-0600)] <colinclark> So it suggests to me that, really, the browse button is a thing the Uploader should have directly
[14:20:00 CST(-0600)] <colinclark> There'll be different versions--Flash or HTML5 buttons, for example
[14:20:28 CST(-0600)] <colinclark> but that, really, it's separate behaviour from this other stuff--adding and removing files, which are modelly-type methods
[14:20:35 CST(-0600)] <colinclark> Anyway, I don't think we need to sweat it for now
[14:20:59 CST(-0600)] <colinclark> heidi_: JSR-168 is the old standard for portlets in Java
[14:21:02 CST(-0600)] <colinclark> used by uPortal
[14:21:07 CST(-0600)] <mlam> hmm...interesting.
[14:21:29 CST(-0600)] <mlam> maybe it can be a bonus feature if we have time (smile)
[14:21:32 CST(-0600)] <colinclark> yep
[14:21:34 CST(-0600)] <colinclark> The standard includes a handful of somewhat poorly conceived styles, which all portlets must implement in order to be styled nicely across different types of portals
[14:22:01 CST(-0600)] <heidi_> ok, and uportal uses this now?
[14:22:10 CST(-0600)] <colinclark> uPortal had hoped that we could build into FSS some styles for those standard JSR-168 class names that were FSS-friendly
[14:22:59 CST(-0600)] <heidi_> ah, this helps: https://wiki.jasig.org/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions
[14:23:24 CST(-0600)] <colinclark> yep, those are them!
[14:23:47 CST(-0600)] <colinclark> So I believe the idea was to ensure that we provide nice styles for all those classnames listed on that page
[14:23:53 CST(-0600)] <colinclark> Jacob got a start on it, at some point
[14:23:56 CST(-0600)] <heidi_> i had made an extra jira for "portlet styles" as mentioned in the meeting - but maybe this is what they meant, not new fss for styling portlets from scratch?
[14:24:01 CST(-0600)] <colinclark> Since we do ship an optional JSR-168 CSS file
[14:24:07 CST(-0600)] <colinclark> yes, exactly
[14:24:17 CST(-0600)] <heidi_> tho i think that would be cool too,
[14:24:27 CST(-0600)] <heidi_> portlet styles for fss alone
[14:24:39 CST(-0600)] <colinclark> I guess our widget styles are an awful lot like portlets, structurally
[14:24:49 CST(-0600)] <heidi_> yeah that file is empty right now
[14:24:50 CST(-0600)] <colinclark> so there is some interesting work to be done in fleshing those out
[14:24:56 CST(-0600)] <colinclark> and I think gary did in fact mention exactly that
[14:25:05 CST(-0600)] <colinclark> So maybe you're right, we're talking about two different things here
[14:25:19 CST(-0600)] <colinclark> 1. Making a comprehensive set of styles for "widgety, portlety things"
[14:25:41 CST(-0600)] <colinclark> 2. Making a CSS files that provides nice FSS-esque styles for the standard JSR-168 class names
[14:26:01 CST(-0600)] <colinclark> I guess the only other thing is that uPortal now (or will soon) supports JSR-286, which is the second version of the portlet spec
[14:26:02 CST(-0600)] <colinclark> a
[14:26:08 CST(-0600)] <colinclark> and which has more styles
[14:26:11 CST(-0600)] <heidi_> ah
[14:26:18 CST(-0600)] <colinclark> athena might have more insight into how that is going
[14:26:29 CST(-0600)] * athena looks up
[14:26:47 CST(-0600)] <colinclark> We were just talking about JSR-168 styles
[14:26:59 CST(-0600)] <colinclark> and the long-standing feature request for having those fully fleshed out in FSS
[14:27:02 CST(-0600)] <athena> so i know we've had problems because we're using the widget styles for the portlet chrome
[14:27:07 CST(-0600)] <colinclark> and then it occurred to me that 286 includes new styles
[14:27:10 CST(-0600)] <colinclark> right
[14:27:17 CST(-0600)] <athena> and we need to separately style the contents
[14:27:31 CST(-0600)] <athena> i think 286 includes new styles but they still suck and the updates don't solve anything
[14:27:34 CST(-0600)] <athena> or something like that.
[14:28:11 CST(-0600)] <athena> so gary's thought i think was to have an enhancement to the crappy overly-general styles that have some specificlly defined usage, recommendations for their use, etc.
[14:28:19 CST(-0600)] <athena> the JSR guidelines are really vague
[14:29:17 CST(-0600)] <colinclark> ahhh
[14:29:21 CST(-0600)] <colinclark> That's interesting
[14:30:39 CST(-0600)] <colinclark> heidi_: Does this help at all?
[14:31:06 CST(-0600)] <heidi_> does jsr come with a .css file, or just class names that require the user to style
[14:31:47 CST(-0600)] <colinclark> the latter
[14:31:50 CST(-0600)] <heidi_> ie. athena are you guys over-riding a default stylesheet with your own styles right now
[14:31:52 CST(-0600)] <heidi_> ah
[14:31:53 CST(-0600)] <colinclark> JSR-168 is just a spec
[14:32:01 CST(-0600)] <colinclark> Portals have to implement it in their own way
[14:32:13 CST(-0600)] <athena> yeah, it's just a list of classes with no guidelines as to their use, basically
[14:32:22 CST(-0600)] <athena> and the problem is that everyone interprets them differently
[14:32:24 CST(-0600)] <colinclark> which is why they generally suck
[14:32:27 CST(-0600)] <heidi_> ah okayy
[14:32:30 CST(-0600)] <athena> so gary wrote some new extension styles for us
[14:32:31 CST(-0600)] <heidi_> thanks athena!
[14:32:41 CST(-0600)] <heidi_> i see
[14:32:45 CST(-0600)] <colinclark> I remember Chuck asking Fluid to contribute to the 286 classes, but it was just such short notice
[14:32:50 CST(-0600)] <colinclark> I guess we could have had a chance to make them suck less
[14:33:01 CST(-0600)] <colinclark> Back when Dr. Chuck was on the committee (smile)
[14:33:16 CST(-0600)] <athena> here are the original ones: https://wiki.jasig.org/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions
[14:33:51 CST(-0600)] <athena> here's gary's sample portlet template with suggested additional styles: https://wiki.jasig.org/display/UPC/Portlet+Markup+Template
[14:34:16 CST(-0600)] <colinclark> oh yes, I remember this
[14:34:18 CST(-0600)] <heidi_> super helpful
[14:34:25 CST(-0600)] <colinclark> I'm so glad Gary built that template
[14:34:28 CST(-0600)] <colinclark> do people use it?
[14:34:29 CST(-0600)] <athena> yeah (smile)
[14:34:32 CST(-0600)] <athena> yes
[14:34:34 CST(-0600)] <colinclark> what are its weaknesses?
[14:34:59 CST(-0600)] <athena> well, from my perspective it's greatest weakness is a lack of adoption and guarantees that it won't change
[14:35:18 CST(-0600)] <athena> right now basically all the portlets that are part of hte uportal webapp use them
[14:35:34 CST(-0600)] <athena> but i haven't encouraged any portlet devs to start incorporating the styles in because we need to know that they'll be really stable
[14:35:41 CST(-0600)] <athena> well-documented, consistent between versions
[14:36:25 CST(-0600)] <athena> we frequently run a version of a portlet in uportals 3.0 through the current release, and right now most portlets are compatible with all uportal 3.x versions, plus capable of being deployed into liferay
[14:36:43 CST(-0600)] <athena> so we need that CSS to be a public API
[14:36:52 CST(-0600)] <athena> which is why we keep trying to donate them to you (tongue)
[14:37:09 CST(-0600)] <athena> as for more technical weaknesses, you'd have to ask one of our resident CSS gurus
[14:37:15 CST(-0600)] <mlam> colinclark: events are passed into the "local" function of the uploader using options merging
[14:37:27 CST(-0600)] <colinclark> riiiight
[14:37:30 CST(-0600)] <mlam> so if i had to create my own events, does this also mean i have to create my own listeners as well?
[14:37:37 CST(-0600)] <colinclark> okay, let me find you an example of how to create your own events
[14:37:49 CST(-0600)] <colinclark> In terms of creating your own listeners, it's entirely up to you
[14:37:56 CST(-0600)] <colinclark> or, rather, up to what you're trying to test
[14:37:56 CST(-0600)] <colinclark> S
[14:38:16 CST(-0600)] <colinclark> So, if you're writing a test that verifies the correct events get fired (and you probably should), then you'll want a listener
[14:38:20 CST(-0600)] <colinclark> So two things
[14:38:24 CST(-0600)] <colinclark> 1. You need to make your own events
[14:38:30 CST(-0600)] <colinclark> I'll dig you up an example of that, one sec
[14:38:35 CST(-0600)] <mlam> k
[14:38:54 CST(-0600)] <colinclark> athena: heidi_ and I are starting to look into the planning for FSS, which'll get a big overhaul in Infusion 1.4
[14:39:12 CST(-0600)] <colinclark> Once we have a plan forming, I was thinking a chat with mpollizotti might be a good idea
[14:39:16 CST(-0600)] <heidi_> athena is there a css file to go with something like gary's portlet template i could check out?
[14:39:45 CST(-0600)] <athena> sounds awesome colinclark
[14:39:59 CST(-0600)] <athena> heidi_: hmm, right now i think some of it is kind of mixed in w/ the rest of the portal styles
[14:40:01 CST(-0600)] <athena> hang on
[14:40:36 CST(-0600)] <athena> ok, so a lot of it is here: https://source.jasig.org/uPortal/trunk/uportal-war/src/main/webapp/media/skins/universality/common/css/layout-portlet.css
[14:40:42 CST(-0600)] <athena> that file is shared between all skins of uportal
[14:40:43 CST(-0600)] <colinclark> The template uses FSS, so you're familiar with at least some of those styles, heidi_ (smile)
[14:41:00 CST(-0600)] <heidi_> sweet, thanks so much athena
[14:41:05 CST(-0600)] <colinclark> And then I guess these are overrides to FSS, athena, amongst other things
[14:41:27 CST(-0600)] <colinclark> ah, these are the JSR-168 styles
[14:41:32 CST(-0600)] <athena> interesting - looks like right now we don't have much in the way of overrides
[14:42:11 CST(-0600)] <colinclark> mlam: There's an example of making your own events on lines 18-22 of SWFUploaderSupportTests.js
[14:42:15 CST(-0600)] <athena> they sort of are colinclark - there's stuff like "titlebar", which is part of gary's markup
[14:42:22 CST(-0600)] <colinclark> right
[14:42:40 CST(-0600)] <colinclark> Gary's CSS is impeccably written
[14:42:42 CST(-0600)] <colinclark> and commented
[14:43:04 CST(-0600)] <athena> yeah, gary's awesome.
[14:43:14 CST(-0600)] <colinclark> And it's so cool that he's included recommendations on ARIA to include when you're building your markup
[14:43:18 CST(-0600)] <mlam> ahh ok, thanks colinclark
[14:43:27 CST(-0600)] <athena> yeah (smile) i feel really lucky whenever we get his time
[14:43:37 CST(-0600)] <athena> he's helping us redesign some of the admin portlets right now
[14:43:42 CST(-0600)] <athena> they're going to be so much less confusing
[14:43:44 CST(-0600)] <colinclark> heidi_: We should strive to be this wicked in the FSS for 1.4
[14:44:03 CST(-0600)] <heidi_> agreed!
[14:44:14 CST(-0600)] <athena> it's so nice that we all have minifiers now, so no one can object to verbose comments
[14:44:24 CST(-0600)] <athena> remember the bad old days when that was an issue
[14:44:56 CST(-0600)] <colinclark> yes
[14:45:07 CST(-0600)] <colinclark> We still don't provide a concatted version of FSS out of the box
[14:45:10 CST(-0600)] <colinclark> which is really something we should fix
[14:45:25 CST(-0600)] <colinclark> I forget, do you guys concat FSS yourselves?
[14:45:49 CST(-0600)] <athena> we do
[14:45:55 CST(-0600)] <athena> well, sort of
[14:46:11 CST(-0600)] <athena> we have a custom setup where we concat the three "shared" files - I think reset, text, and layout?
[14:46:18 CST(-0600)] <athena> and then keep the files for each theme separate
[14:47:08 CST(-0600)] <colinclark> right
[14:47:12 CST(-0600)] <colinclark> because of the image references?
[14:47:23 CST(-0600)] <colinclark> or because you don't use the themes?
[14:47:44 CST(-0600)] <athena> we import each theme inside the skin that's actually using it
[14:47:59 CST(-0600)] <athena> so most of the skins import mist, one imports coal, and one uses hc
[14:48:24 CST(-0600)] <athena> so we do still wind up with a bunch of css imports, but not as many as we'd otherwise have
[14:48:51 CST(-0600)] <athena> it's typically fluid-framework (the aggregated one), fluid-theme-whatever, a shared portal css file, and then the theme css file
[14:48:58 CST(-0600)] <athena> er, and an appropriate jquery ui theme
[14:49:14 CST(-0600)] <colinclark> ah, interesting
[14:51:31 CST(-0600)] <colinclark> heidi_: Okay, so which patches are the ones I should review and commit?
[14:51:42 CST(-0600)] <colinclark> I always get confused when they aren't labelled with version letters or something like that
[14:51:54 CST(-0600)] <heidi_> colinclark -h is the last one
[14:51:59 CST(-0600)] <colinclark> ahhh
[14:52:00 CST(-0600)] <colinclark> wicked
[14:52:05 CST(-0600)] <colinclark> i missed the letters
[14:52:06 CST(-0600)] <heidi_> thanks!
[14:52:07 CST(-0600)] <colinclark> i suck
[14:52:11 CST(-0600)] <heidi_> haha, np
[14:52:11 CST(-0600)] <athena> here's what our imports look like in the default theme: http://uportal.pastebin.com/KwRrArGT
[14:52:43 CST(-0600)] <heidi_> colinclark could builder someday do a mashing of css files ?
[14:52:53 CST(-0600)] <colinclark> yes, it absolutely should
[14:53:18 CST(-0600)] <colinclark> The only reason we don't do it currently is because of image references in the CSS files, which would break when the mashed file got moved around
[14:53:20 CST(-0600)] <athena> we of course have picky and idiosyncratic needs (smile)
[14:53:24 CST(-0600)] <colinclark> (smile)
[14:53:29 CST(-0600)] <colinclark> That's why we love you
[14:53:29 CST(-0600)] <athena> but something like the jquery ui one would probably work for a lot of people
[14:53:34 CST(-0600)] <athena> lol
[14:53:37 CST(-0600)] <athena> we're a good test case
[14:53:43 CST(-0600)] <athena> what can i break today . . . evil cackle
[14:53:48 CST(-0600)] <colinclark> (smile)
[14:53:58 CST(-0600)] <athena> by the way, did resetting your build's db make any difference?
[14:54:12 CST(-0600)] <colinclark> Justin and I had a long chat about how to rework our builds to support CSS mashing, heidi_, as well as significantly tidying up the directory structure of our builds
[14:54:15 CST(-0600)] <colinclark> anastasiac: ^
[14:54:28 CST(-0600)] <colinclark> michelled and I were also talking today about dropping Maven support in our builds
[14:54:33 CST(-0600)] <colinclark> I don't think anyone even uses it
[14:54:52 CST(-0600)] <athena> i've been thinking about writing a JSP tag to do aggregation of inline JS
[14:55:10 CST(-0600)] <athena> we have some decently large chunks of page-specific HTML that wire up a custom pager or whatever
[14:55:22 CST(-0600)] <colinclark> ah, that's really interesting
[14:55:32 CST(-0600)] <athena> i think it should actually be pretty trivial
[14:55:40 CST(-0600)] <athena> reuse the YUI compressor library to do it
[14:56:11 CST(-0600)] <athena> probably can grab some sample code from the maven-yui-compressor plugin
[14:56:16 CST(-0600)] <athena> or from our own custom aggregation plugin
[14:56:18 CST(-0600)] <anastasiac> athena, I didn't have any luck resetting the db, but I suspect I didn't "do it right." I removed the hsql-data folder and rebuilt: site still has same problem, and the hsql-data folder was never recreated. I'm suspecting that's not the way to reset the db
[14:56:49 CST(-0600)] <athena> hm, wonder if it was the right database
[14:56:55 CST(-0600)] <anastasiac> exactly
[14:57:13 CST(-0600)] <athena> from looking at your script, if i remember right, there was some magic where it seemed to actually auto-populate the db from another db, but that was commented out
[14:57:28 CST(-0600)] <anastasiac> right
[14:57:33 CST(-0600)] <athena> is there a "data" directory right under uportal?
[14:57:45 CST(-0600)] <athena> if there is, i'd try shutting down tomcat, then deleting that one and re-running the build
[14:57:55 CST(-0600)] <jamon> athena, anastasiac, colinclark, email me with an overview of the problem, i've been wanting to work on this for a while, will have time over the weekend i would be happy to devote to a challenge like this (smile)
[14:58:26 CST(-0600)] <athena> and if that doesn't work i recommend sacrificing some cut up CDs to the server or something, because i really don't get it (tongue)
[14:58:53 CST(-0600)] <anastasiac> athena, there is such a directory. I'll try that. and jamon, I'll fill you in
[15:01:03 CST(-0600)] <colinclark> hey heidi_, is your editor set to use four spaces instead of Tabs?
[15:01:20 CST(-0600)] <colinclark> In your patch, it looks like basically the whole HTML file has changed, and I think tabs have crept into it
[15:01:23 CST(-0600)] <heidi_> colinclark it is - is it tabby?
[15:01:29 CST(-0600)] <colinclark> looks sort of tabby, yes
[15:01:47 CST(-0600)] <heidi_> ill double check and put a new patch, sorry about that
[15:02:12 CST(-0600)] <colinclark> thanks
[15:02:25 CST(-0600)] <colinclark> that way I can see what actually changed in the HTML file
[15:02:44 CST(-0600)] <heidi_> my editor has a 'detab' feature... ill run it through all the fiels
[15:03:57 CST(-0600)] <colinclark> cool
[15:05:57 CST(-0600)] <jamon> ping fluid-everyone: favicon needs a confluence restart, 16:30 EST today an ok time for that? should be < 5minutes
[15:06:30 CST(-0600)] <heidi_> colinclark new patch on jira
[15:06:32 CST(-0600)] <colinclark> I have no complaints, but I'll defer to anastasiac among others in case she's deep in the midst of some documentation
[15:06:36 CST(-0600)] <colinclark> heidi_: You're fast!
[15:06:43 CST(-0600)] <heidi_> (smile)
[15:10:23 CST(-0600)] <anastasiac> jamon, fine with me, with a 1-minute warning in the channel
[15:10:43 CST(-0600)] <jamon> anastasiac: k, will give 5 and then 1
[15:12:05 CST(-0600)] <colinclark> mlam: Your FLUID-3699 patch is hot
[15:12:09 CST(-0600)] <colinclark> I'll commit it now
[15:12:20 CST(-0600)] <mlam> awesome, thanks!
[15:14:59 CST(-0600)] <colinclark> heidi, this patch is way easier to read and review
[15:15:00 CST(-0600)] <colinclark> thanks again
[15:15:26 CST(-0600)] <heidi_> okay good
[15:19:51 CST(-0600)] <colinclark> This is pretty awesome, in case anyone feels like a break to look at some HTML5 coolness: http://www.webglearth.com
[15:30:42 CST(-0600)] <jamon> ping fluid-everyone: wiki restart will have to wait, can't get the staging instance to accept a new favicon.ico per atlassian's instructions (sad)
[15:31:34 CST(-0600)] <anastasiac> colinclark, could you have look at http://issues.fluidproject.org/browse/FLUID-296 and comment on whether or not it's still an issue? there isn't quite enough info in the JIRA for me to tell. It's an old one...