[11:47:43 CST(-0600)] <Arvids1> could it be that mobile view renders all portlets?
[11:47:56 CST(-0600)] <EricDalquist> by default yes it does
[11:48:09 CST(-0600)] <EricDalquist> I believe there is an option to disable mobile rendering on a per-portlet basis
[11:48:14 CST(-0600)] <Arvids1> emm... how can i avoid such behaviour?
[11:50:05 CST(-0600)] <Arvids1> ah.. now i get it
[11:54:12 CST(-0600)] <Arvids1> my question was a bit misleading - first mobile view (where only icons are showed) gives me an impression that content of each and every portlet in user layout gets rendered (but is not visible on the screen)
[11:54:23 CST(-0600)] <EricDalquist> nope
[11:54:41 CST(-0600)] <EricDalquist> all the portlets are executed in minimized windowstate
[11:54:57 CST(-0600)] <EricDalquist> and if they are well behaved that should take all of 10ms
[11:55:08 CST(-0600)] <Arvids1> ok
[11:55:25 CST(-0600)] <EricDalquist> the reason they render at all is the mobile view has support for badge #s
[11:55:35 CST(-0600)] <EricDalquist> and a few portlets set response properties that the mobile view uses
[11:55:46 CST(-0600)] <EricDalquist> athena and I have talked about adding a new uP specific WindowState
[11:55:54 CST(-0600)] <EricDalquist> name it DASHBOARD or some such
[11:56:10 CST(-0600)] <EricDalquist> and then uP would only actually render portlets that declare support for said WindowState
[11:56:18 CST(-0600)] <EricDalquist> saving some time and cpu
[11:56:30 CST(-0600)] <Arvids1> sounds reasonable
[11:56:42 CST(-0600)] <EricDalquist> but that is more of a "that would be nice" than "we need to have" so it hasn't really had any time spent on it
[11:56:45 CST(-0600)] <EricDalquist> beyond those thoughts
[11:59:54 CST(-0600)] <EricDalquist> how's the performance testing going?
[12:01:27 CST(-0600)] <Arvids1> really nice
[12:01:40 CST(-0600)] <Arvids1> we´re setting everything up today
[12:01:53 CST(-0600)] <EricDalquist> great
[12:02:06 CST(-0600)] <EricDalquist> so that permissions check fix addressed most of it?
[12:02:07 CST(-0600)] <Arvids1> our main portal page could handle like 40 rq/sec without any big problems
[12:02:10 CST(-0600)] <Arvids1> yes
[12:02:11 CST(-0600)] <EricDalquist> nice
[12:20:20 CST(-0600)] <Arvids1> I´m not sure why, but that dashboard view tries to render all portlets in ´normal´ window state :-/
[12:20:54 CST(-0600)] <EricDalquist> hrm, I thought we had put something in place in 4.0.3 that specifically fixed that
[12:23:06 CST(-0600)] <EricDalquist> maybe that was put in after 4.0.3 ...
[12:23:27 CST(-0600)] <athena> might have been
[12:23:38 CST(-0600)] <athena> i know at least one of the fixes we needed for umobile was after the 4.0.3 release
[12:24:33 CST(-0600)] <Arvids1> I´ll try to dig through the latest changes
[12:24:52 CST(-0600)] <EricDalquist> I'm looking right now as well
[12:27:38 CST(-0600)] <EricDalquist> https://issues.jasig.org/browse/UP-3334
[12:27:43 CST(-0600)] <EricDalquist> looks like it's a 4.0.4 issue
[12:28:23 CST(-0600)] <Arvids1> i´ve applied this one
[12:28:26 CST(-0600)] <EricDalquist> https://issues.jasig.org/browse/UP-3327
[12:28:36 CST(-0600)] <EricDalquist> but 3327 appears to be in 4.0.3
[12:30:37 CST(-0600)] <EricDalquist> you might need a data import
[12:30:38 CST(-0600)] <EricDalquist> https://github.com/jasig/uPortal/commit/9e539d6830c2cc3cfee9cce3a936f14ccd904b86
[12:31:07 CST(-0600)] <EricDalquist> to add the defaultWindowState param to your mobile stylesheet descriptors
[12:32:18 CST(-0600)] <Arvids1> yes, I was lookin at that exact commit and realized that our entities were imported before that patch
[12:34:05 CST(-0600)] <drewwills> morning EricDalquist... I can't remember if we previously discussed bundling the Notification portlet (in incubation) or not... I think we may have
[12:34:16 CST(-0600)] <EricDalquist> I can't either
[12:34:29 CST(-0600)] <drewwills> anthony cut a release of it last week
[12:34:39 CST(-0600)] <drewwills> it seems like now could be a good time
[12:34:58 CST(-0600)] <drewwills> it has a nice demo experience
[12:35:00 CST(-0600)] <EricDalquist> sounds good, are you going to setup the overlay and stuff?
[12:35:10 CST(-0600)] <drewwills> yes i can/ am happy to
[12:35:50 CST(-0600)] <athena> can we maybe talk about splitting out a jsr-286 branch for that, if it's going to be included in up4?
[12:36:07 CST(-0600)] <EricDalquist> I'm fine with bundling more stuff as long as it participates in filtering (db, logging, etc) correctly, and has a reasonable default dataset and portlet definition
[12:36:38 CST(-0600)] <athena> i think we also need to take import/export into consideration
[12:36:41 CST(-0600)] <drewwills> athena I don't believe any 286 work has been done on that one yet
[12:37:03 CST(-0600)] <EricDalquist> where does this thing store data?
[12:37:39 CST(-0600)] <drewwills> it has an interface-based API for pulling data... doesn't store it, unless you write one to store data
[12:37:56 CST(-0600)] <drewwills> for the demo experience it pulls demo data from the classpath
[12:38:05 CST(-0600)] <EricDalquist> ok, so what is the concern around import/export athena?
[12:38:24 CST(-0600)] <athena> none, since it doesn't store data 
[12:38:25 CST(-0600)] <drewwills> i thought that was just a general concern
[12:39:06 CST(-0600)] <EricDalquist> ah ok
[12:44:25 CST(-0600)] <Arvids1> regarding notifications - i´ve implemented another notificaton portlet (inspired by previously mentioned) but with some differences - concurrent notification retrieval, no extended description (hence no ajax)
[12:45:03 CST(-0600)] <Arvids1> ... and of course - changes in data classes
[12:46:18 CST(-0600)] <athena> would it make sense to contribute some of that back so we can all contribute to a shared project?
[12:46:32 CST(-0600)] <EricDalquist> +1 to that
[12:46:45 CST(-0600)] <Arvids1> requirements must be discussed, since i´ve taken a little bit another approach
[12:46:50 CST(-0600)] <athena> so i guess my biggest concern with including the notifications portlet out of the box right now is that it's a young project and the APIs might need to change
[12:47:06 CST(-0600)] <athena> and we may need to pull in changes brought up by things arvids or other schools notice
[12:47:23 CST(-0600)] <EricDalquist> ah
[12:47:35 CST(-0600)] <Arvids1> now it would be nice to have notification portlet on github
[12:47:35 CST(-0600)] <athena> i guess we just need to decide what level of API changes we're willing to have in a portlet between portal version numbers
[12:47:51 CST(-0600)] <athena> yes, moving to github would also help w/ the JSR-286 changes
[12:48:07 CST(-0600)] <athena> the umobile effort would like to use the notifications portlet to drive some new functionality
[12:48:19 CST(-0600)] <EricDalquist> one thing we should talk about with moving projects to github is how incubation on github will work
[12:48:32 CST(-0600)] <athena> particuarly add an event-based API so that other portlets could potentially publish notifications, then pull them all down in one JSON feed
[12:48:46 CST(-0600)] <EricDalquist> yeah
[12:49:02 CST(-0600)] <athena> do we have concerns about incubation on github?
[12:49:13 CST(-0600)] <EricDalquist> well just project designations
[12:49:49 CST(-0600)] <EricDalquist> part of my wants to say that only post-incubation projects should end up under the jasig org and in-incubation projects should stay in the account of whoever the sponsor is until they complete
[12:49:57 CST(-0600)] <EricDalquist> but that probably isn't actually realistic
[12:50:31 CST(-0600)] <athena> that would also make collaboration really hard
[12:50:47 CST(-0600)] <EricDalquist> yeah, I know
[12:50:49 CST(-0600)] <athena> i'd worry that that would discourage people from working together
[12:51:29 CST(-0600)] <athena> maybe we can just track which projects are sponsored /incubated in the wiki or somewhere else?
[12:51:34 CST(-0600)] <EricDalquist> yeah
[12:51:38 CST(-0600)] <athena> i think that's where most people get information about the portlets already, at least
[12:51:47 CST(-0600)] <athena> coudl have a similar page that's not portlet-specific
[12:52:15 CST(-0600)] <EricDalquist> we could also require that incubating projects have a github readme doc that states such
[12:52:18 CST(-0600)] <Arvids1> implementing notification portlet using event API is a bit problematic since events can not be published at rendering
[12:52:24 CST(-0600)] <EricDalquist> so that looking at the project page is informative
[12:53:07 CST(-0600)] <athena> EricDalquist: that seems helpful. what's our timeline on git migration? i think it'd probably be helpful to move as soon as we can
[12:53:22 CST(-0600)] <athena> Arvids1: we haven't experimented with it yet at all, but it seems like we could use a resource request?
[12:53:22 CST(-0600)] <EricDalquist> I'll take a look at the list and add some other projects
[12:53:36 CST(-0600)] <athena> sounds good
[12:53:43 CST(-0600)] <EricDalquist> the actual timeline will depend on who can help
[12:53:52 CST(-0600)] <athena> maybe when we've added everything we want, we could send a note out to the list
[12:53:53 CST(-0600)] <EricDalquist> I have near zero spare time between now and April 5
[12:53:54 CST(-0600)] <athena> what needs to be done?
[12:54:55 CST(-0600)] <EricDalquist> https://github.com/Jasig/svn2git-migration
[12:55:07 CST(-0600)] <EricDalquist> the readme for that project should detail the steps
[12:55:21 CST(-0600)] <athena> makes sense
[12:55:37 CST(-0600)] <athena> anyway, i'd be willing to help out with that
[12:55:40 CST(-0600)] <EricDalquist> assuming we aren't doing a read only SVN mirror of anything the work isn't too bad
[12:55:48 CST(-0600)] <athena> i have a pretty high incentive to move right now, since it would make my life a lot easier
[12:55:51 CST(-0600)] <EricDalquist> probably a few hours of setup and testing
[12:56:01 CST(-0600)] <EricDalquist> and then 15-30 minutes per project
[12:56:11 CST(-0600)] <athena> that seems fine
[12:57:24 CST(-0600)] <Arvids1> A screenshot from my version of portlet: http://oi40.tinypic.com/33nj4wi.jpg
[12:58:06 CST(-0600)] <EricDalquist> we should also touch base with scheduling assistant and open registry
[12:58:11 CST(-0600)] <EricDalquist> see if they want to be moved
[12:58:20 CST(-0600)] <athena> makes sense
[12:59:18 CST(-0600)] <EricDalquist> so why isn't everything under /portlets listed?
[12:59:44 CST(-0600)] <athena> i listed everything that i personally know something about and know is being maintained
[12:59:53 CST(-0600)] <athena> there are some portlets on there that i don't really know anything about
[13:00:21 CST(-0600)] <athena> like the xythos and deployer portlets
[13:00:28 CST(-0600)] <athena> i think everything else is listed
[13:00:31 CST(-0600)] <athena> except for tabbed search
[13:00:43 CST(-0600)] <EricDalquist> ok
[13:00:49 CST(-0600)] <athena> which hasn't been contributed to in quite a while and i don't intend to maintain going forward
[13:00:57 CST(-0600)] <athena> i've recommend that that one be dropped from incubation
[13:01:04 CST(-0600)] <EricDalquist> and do we have a consensus as to what we should do with the stuff in svn?
[13:01:13 CST(-0600)] <EricDalquist> do we delete them from HEAD?
[13:01:18 CST(-0600)] <athena> sounds reasonable to me
[13:02:21 CST(-0600)] <EricDalquist> ok I added a few more items to the list
[13:04:01 CST(-0600)] <EricDalquist> can you email the uportal-dev and portlet-dev lists with the list asking if anyone would like any other projects want to get moved?
[13:04:11 CST(-0600)] <athena> sure
[13:04:29 CST(-0600)] <EricDalquist> set a deadline of like the 7th and then you can pick a date to do the actual move
[13:05:01 CST(-0600)] <athena> sounds great
[13:05:02 CST(-0600)] <athena>
[13:09:29 CST(-0600)] <athena> ok, so back to the notifications portlet
[13:09:45 CST(-0600)] <EricDalquist> ok
[13:09:47 CST(-0600)] <athena> what level of API consistency do we want to have from bundled portlets?
[13:10:11 CST(-0600)] <athena> i think in the past we've been pretty cautious about only including portlets that have fairly mature, stable APIs
[13:10:25 CST(-0600)] <EricDalquist> hrm
[13:10:28 CST(-0600)] <EricDalquist> I'm not sure
[13:10:29 CST(-0600)] <athena> and for those that aren't there yet (like the courses portlet), we've included mockups with a link to more information about the actual portlet
[13:10:42 CST(-0600)] <EricDalquist> I haven't really thought about that as much
[13:10:44 CST(-0600)] <athena> i'm not saying that that's necessarily what we need to keep doing, but i think that's generally what we've been doing until now
[13:11:01 CST(-0600)] <EricDalquist> since it is significantly easier to simply specify an earlier version of a specific portlet
[13:11:07 CST(-0600)] <athena> yeah
[13:11:08 CST(-0600)] <EricDalquist> even when doing a big uPortal upgrade
[13:11:24 CST(-0600)] <EricDalquist> very rarely should a uPortal upgrade break an old portlet
[13:11:43 CST(-0600)] <athena> and i'd imagine that schools that are sophisticated enough to create their own API implementations will be able to drop the version number back down if needed
[13:12:23 CST(-0600)] <EricDalquist> yup
[13:12:25 CST(-0600)] <athena> kind of annoying to have a portal upgrade break your portlet because it updated the version number, but i guess that's maybe just not that hard to resolve
[13:14:23 CST(-0600)] <athena> actually, as a general point
[13:14:35 CST(-0600)] <athena> in the past we've required portlets to actually be sponsored by jasig before including them
[13:14:46 CST(-0600)] <EricDalquist> that was going to be a question I had
[13:14:49 CST(-0600)] <athena> yeah
[13:14:59 CST(-0600)] <EricDalquist> if we don't have any incubating stuff bundled
[13:15:03 CST(-0600)] <EricDalquist> then that seems reasonable to continue
[13:15:21 CST(-0600)] <EricDalquist> and if a project dev is motivated getting out of incubation should be able to happen very fast
[13:15:27 CST(-0600)] <athena> yeah, we actually worked pretty hard to get all those included portlets through the queue
[13:15:42 CST(-0600)] <athena> i'll check and see if we actually got that finished
[13:15:50 CST(-0600)] <EricDalquist> pl
[13:15:52 CST(-0600)] <EricDalquist> ok
[13:16:34 CST(-0600)] <athena> heh
[13:16:40 CST(-0600)] <athena> bookmarks and widgets are both still in incubation
[13:16:44 CST(-0600)] <EricDalquist> 
[13:17:26 CST(-0600)] <athena> not actually sure why on the widgets
[13:17:36 CST(-0600)] <athena> bookmarks just hasn't been updated in forever
[13:17:40 CST(-0600)] <EricDalquist> bookmarks is likely my fault
[13:17:41 CST(-0600)] <EricDalquist> and yes
[13:17:49 CST(-0600)] <EricDalquist> I think it is out of fear I'll break it if I touch it
[13:17:52 CST(-0600)] <athena> but any new portlets we've included are indeed fully sponsored
[13:17:53 CST(-0600)] <athena> yeah 
[14:00:34 CST(-0600)] <athena> have you guys published the code for your HR portlets yet?
[14:00:44 CST(-0600)] <athena> thinking that that might be another good portlet to include as a mockup
[14:00:57 CST(-0600)] <athena> would give us some more interesting data for staff / faculty demo accounts
[14:01:10 CST(-0600)] <EricDalquist> no
[14:01:16 CST(-0600)] <EricDalquist> I've been too busy with our upgrade
[14:01:21 CST(-0600)] <EricDalquist> I'll see if I can find/make time for that
[14:01:26 CST(-0600)] <athena> no worries
[14:01:31 CST(-0600)] <athena> just thinking about the future
[14:01:41 CST(-0600)] <athena> we need to re-poke jim about default layout suggestions too
[14:09:35 CST(-0600)] <awills_bbl> i don't think it's an issue to include portlets that are incubating... actually I think it could make a big difference in promoting them... persuating new schools to make contributions... it's nice to see a good buffet of options when you spin the portal up for evaluation