18:00:52 <stickster> #startmeeting Fedora Insight
18:00:52 <zodbot> Meeting started Thu Jun 17 18:00:52 2010 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:45 <stickster> #topic Agenda
18:01:48 <stickster> #link https://fedoraproject.org/wiki/Fedora_Insight#Meeting_agenda
18:01:51 <stickster> #topic Roll call
18:01:52 * stickster 
18:02:00 * rbergeron 
18:02:01 <pcalarco> pcalarco
18:02:04 * Sparks_too .
18:02:14 <stickster> Wow, we have a Sparks_too here, cool!
18:02:20 <stickster> I saw smooge around earlier as well.
18:02:41 <rbergeron> smooge just joined like... 3 minutes ago
18:02:53 <smooge> here
18:03:04 <smooge> sorry distracted
18:03:05 <rbergeron> sparks_too: you finally figured out the mchua_clone process?
18:03:06 * rbergeron is jealous
18:03:29 <Sparks_too> rbergeron: Yeah... this is my right side
18:03:44 <stickster> :-)
18:03:51 <stickster> OK, let's review last week's action items:
18:03:57 <stickster> #topic Last week's action items
18:04:00 <stickster> #link http://meetbot.fedoraproject.org/fedora-mktg/2010-06-09/fedora_insight.2010-06-09-18.00.html
18:04:21 <stickster> I was supposed to finish up the EZComments upgrade, and email the logistics list when that happened.
18:04:24 <stickster> Done and done.
18:04:31 <stickster> #info stickster finished his individual stuff.
18:05:00 <stickster> rbergeron and I were supposed to talk at SELF, which we did.
18:05:04 <rbergeron> check!
18:05:10 <stickster> #info stickster and rbergeron finished their immediate joint AI's too
18:05:16 <pcalarco> Folks, I want to apologize for borking our milestone by opening new tickets kinda at the last moment before that; I didn't expect to see the interface changed to that degree
18:05:28 <stickster> pcalarco: I don't think you're altogether at fault there.
18:05:31 <rbergeron> I tested out EZcomments and it seemed to work, although I think the formatting was a little funky
18:05:51 <rbergeron> but - the actual commenting functionality with moderation now works correctly.
18:06:07 <stickster> #topic What next?
18:06:18 <stickster> #info EZComments seems to have made moderation work
18:06:23 <stickster> #undo
18:06:23 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x841f050>
18:06:29 <stickster> #chair pcalarco rbergeron Sparks_too smooge
18:06:29 <zodbot> Current chairs: Sparks_too pcalarco rbergeron smooge stickster
18:06:36 <stickster> #info EZComments 2.0.0 upgrade seems to have made moderation work
18:06:57 * smooge almost has most of things dealt with
18:08:05 <rbergeron> I have some formatting / html (or whatever it is) things I need to submit on for the comments
18:08:09 <rbergeron> but - not functional
18:08:12 <rbergeron> just... look and feel
18:08:13 <stickster> smooge: How much help are you getting from mateo?
18:08:38 <smooge> pretty good when our times sync up
18:09:26 <smooge> but the time sync up is usually the issue. I think gwerra made some new updated rpms for me that i need to put into the infrastructure repo for stg
18:09:34 <smooge> Here are the issues I don't know yet.
18:09:48 <smooge> 1) How does zikula work with multiple front ends talking to a single DB.
18:10:21 <smooge> 2) how many more little things have to be changed to make it work
18:10:44 <smooge> currently as far as I can tell only app01.stg is talking to the backend db. app02.stg is not..
18:11:11 <stickster> smooge: Could that be because of the local configuration in /etc/zikula/zikula.conf on apps?
18:11:15 <stickster> s/apps/app2/?
18:11:23 <smooge> we need to see if this will scale to 7 app servers
18:11:28 <smooge> possibly
18:12:06 <smooge> I have had to deal with a turbogears issue the last 48 hours so haven't tracked it down. I was going to look at it today stickster
18:12:44 <smooge> hmmm app01 and app02 should be configured exactly the same. If they aren't then something is foo'd
18:13:16 <stickster> smooge: So here's the thing
18:13:42 <stickster> We set up a milestone for June 15th, and I'm worried about whether that was unreasonable for you, given your other commitments
18:14:20 <stickster> I don't want you to feel like this whole project hinges on you, but we have little in the way of other infrastructure resources.
18:14:28 <stickster> What can some of us do to help?
18:14:42 * stickster has access, but probably less knowledge than he needs
18:15:30 <smooge> To be honest I am not sure. I had been hoping actually to get help from ricky and ian as they know much more php than me but both have had other issues come up
18:16:07 <smooge> And this week I am filling in for mmcgrath as he is in training.
18:16:18 <stickster> smooge: Ah, good point -- I had forgotten that mmcgrath is out
18:16:20 <smooge> so our depth of bench has shrunk more than I expected
18:16:29 <smooge> s/more/much more/
18:17:15 <stickster> Anyone else have comments?
18:17:28 <smooge> And while some people have been really helpful on the stg environment they have done it by hand and I need it done by puppet which makes it hard
18:18:00 <stickster> smooge: Right, it seems like we're still trying to impress upon people that they need to follow a procedure for puppet stuff.
18:18:12 <stickster> smooge: Is there a simple document for making puppet-based changes on the iwki?
18:18:15 <stickster> *wiki
18:18:44 <smooge> Not that I know of. I think its the usual thing about documentation
18:19:03 <stickster> smooge: Seems like something we ought to remedy -- that's a fairly broad need across Infra-related projects I'd think
18:19:08 <smooge> for us to document things we need to stop doing other things...
18:19:28 <stickster> smooge: Maybe we can get ianweller or a Docs person from Sparks_too's team to help with that
18:19:54 <stickster> Ah!
18:19:56 <stickster> smooge: https://fedoraproject.org/wiki/Puppet_Infrastructure_SOP
18:20:05 <smooge> I would like help on it. mmcgrath will probably say I missed some large document that I should know about
18:20:12 <smooge> like https://fedoraproject.org/wiki/Puppet_Infrastructure_SOP
18:20:27 <stickster> heh, *jinx
18:21:09 <stickster> smooge: When I tuned in before SELF, there were people helping, but making "temporary" changes on stg.fp.o to see if they were properly resolving problems.
18:21:15 <Sparks_too> stickster: If we need to document Puppet within Infra more than the SOP I can probably round up some folks to help look over shoulders and take notes
18:21:45 <smooge> It really needs a lot more in it... we don't allow the puppet repository outside of PHX2 systems (eg don't checkout to your local machine). etc etc.
18:21:59 <stickster> smooge: Were those folks -- gwerra, mateo, whoever -- then getting things into puppet properly? Or sending diffs somewhere, or otherwise making sure you didn't have to run around with a broom and mop after everyone?
18:22:02 * rbergeron just opened up 2 tickets - https://fedorahosted.org/fedora-infrastructure/ticket/2232 and https://fedorahosted.org/fedora-infrastructure/ticket/2231 - both minor relating to fonts / css stuff
18:22:10 * rbergeron will add them to the FI ticket list on the wiki
18:22:19 <smooge> stickster, they were doing so.. I just didn't get a copy of those so I am not sure what/where they were documented (beyond a coyuple of symlinks you said
18:22:58 <stickster> smooge: Sorry, I'm slow on the uptake today -- you didn't get a copy of... ?
18:23:01 <smooge> rbergeron, send me a link to that list.
18:23:55 <rbergeron> smooge: http://fedoraproject.org/wiki/Fedora_Insight#Meeting_agenda - there are tickets in a list there, although listed under old items
18:23:59 <smooge> stickster, my fault.. I am saying words in my head but not typing them :). I know that they made various small changes, but I don't know all of them, which ones worked, which ones didn't and where there were.,
18:24:11 <stickster> smooge: :-(
18:24:32 <rbergeron> stickster: do we want to go through that list - and see what is valid / still open and not - and come up with a more consise list?
18:24:35 <rbergeron> concise?
18:24:40 <stickster> smooge: Does that mean there are changes on stg.fp.o now, that aren't captured in puppet or in the git repo backing up the theme and/or modules?
18:25:06 <smooge> in the end it is a communication issue. I did not specify that they needed to put what they did in email or a ticket
18:25:07 <stickster> rbergeron: Absolutely, great idea. I do want to finish figuring out the state of our staging instance first
18:25:14 <rbergeron> okay.
18:25:25 * rbergeron just looks for ways to help that she can actually ... do :)
18:25:34 <smooge> stickster, I am trying to find that out. its on my list to do after meeting.
18:25:47 <stickster> rbergeron: One thing that would be useful is to make sure all those open tickets have "Insight" in the keywords
18:25:53 * smooge is trying to remain focused on channel versus adhd onto other tasks :)
18:25:56 <stickster> rbergeron: So we can just have a query instead of another list on the wiki to keep up
18:26:05 <stickster> smooge: I sympathize! :-D
18:26:32 <stickster> #action smooge to figure out (again) if we have uncaptured changes on stg.fp.o
18:27:01 <rbergeron> stickster: that is exactly what i was just thinking
18:27:03 <smooge> the second thing I have to figure out is what configuration where on proxy.stg sends stuff to the app servers for insight so I can make sure its hitting both boxes and then we can see if we are going to be able to make that part wrok
18:27:44 <stickster> #action smooge Figure out what config on proxy.stg sends to the app servers for Insight, so we know both boxes will work properly
18:28:18 <stickster> #action rbergeron Check tickets for Insight in f-infra trac to ensure each has the "insight" keyword, so we can track with a query instead of a separate list
18:28:47 <stickster> smooge: I think it's fair to point out that the work we're doing now would be the same no matter what platform we were using.
18:29:10 <stickster> smooge: So with Insight 2.0, 3.0, and beyond... a change would require us to revisit all this stuff, including scale.
18:29:18 <smooge> correct
18:29:32 <stickster> Although I suspect that other popular CMS platforms likely have a ton of documentation on load balancing the app
18:30:12 <smooge> yes. from what I understand drupal is meant to work in farm mode (or whatever the term is these days)
18:30:22 <smooge> others do it othter ways
18:31:30 <stickster> One of the fellows at our FAD @ SELF '10 this past weekend had some CMS experience
18:31:31 <smooge> i don't have much more to say at the moment
18:31:39 <stickster> smooge: Thanks for the update
18:31:56 <stickster> smooge: For now, I guess the best we can do is to pursue answers to the questions you raised above
18:32:33 <stickster> Anyway, as I was saying
18:32:35 <stickster> One of the fellows at our FAD @ SELF '10 this past weekend had some CMS experience
18:33:08 <stickster> We talked to him about our difficulties in getting a team up to speed on a CMS, and he mentioned how Drupal solved a lot of problems in one of his recent gigs
18:33:21 <rbergeron> stickster, smooge:when adding keywords to a ticket - does one need to put a comment between, not put a comment between, or does it not matter either way
18:33:40 <stickster> rbergeron: comma? yes, a comma is the right way I believe
18:33:50 <smooge> rbergeron, comma I believe
18:33:53 <rbergeron> okay, that's what i've been doing - just making sure
18:34:01 * rbergeron didn't want to go through twice :)
18:34:04 <stickster> They had started on Joomla I believe, and one of the things he pointed out to us at the conference...
18:34:22 <stickster> ...was that "lock in" comes in many different forms, and committing to a content model in one CMS can make it difficult to move data later.
18:34:49 <rbergeron> stickster: i don't have permissions in that trac to make a custom report for keywords of zikula and insight
18:35:02 <stickster> rbergeron: Yeah, that's OK, we can just use a tinyurl for it
18:35:03 <rbergeron> if someone else wants to take that on - or i can request one... via trac
18:35:06 <rbergeron> ok
18:35:27 <stickster> rbergeron: You can just use the long one, note it on the wiki with [way-too-long-url  nice easy text]
18:35:27 <ianweller> you can just hit 'custom query' at the top of the reports page
18:36:33 <stickster> ianweller: I think rbergeron was talking about saving it -- or maybe I'm just confused.
18:36:51 <stickster> Does anyone have thoughts about the subject of content lock-in?
18:37:05 <Sparks_too> I think lock-in is dangerous
18:37:14 <stickster> Is it worth worrying about at this point?
18:37:16 <rbergeron> ianweller: i meant one more permanent - added to the list of reports
18:37:29 <rbergeron> although - i'm querying for keyword insight
18:37:29 <ianweller> ah
18:37:29 <Sparks_too> Although I don't know that we wouldn't have that problem with any solution.
18:37:31 <rbergeron> or zikula
18:37:37 * mchua reads up
18:37:46 <rbergeron> custom query isn't returning a thing, which is odd
18:37:48 <stickster> rbergeron: Yeah, between those two, we should be in good shape to catch all tickets.
18:38:01 <mchua> (for the record, we have some writing profs here at RIT who *really* want to get their students writing stuff for a FOSS project, so we have content minions if we want them... platform needed, though.)
18:38:09 <Sparks_too> changing CMS solutions would mean data transfers.  The longer down the road the more data
18:38:19 <smooge> correct
18:38:22 <stickster> https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&keywords=~zikula&keywords=~insight&order=priority
18:38:38 <Sparks_too> mchua: I could abuse some in Docs...
18:38:56 <smooge> ending up with a CMS that can't be transferred has been the death of many projects
18:39:03 <rbergeron> ah - i needed to remove the owner line
18:39:15 <smooge> or a very looooong week of rewriting
18:39:22 <Sparks_too> Yeah
18:39:40 <Sparks_too> I don't know if it would be a simple as relabeling tables in the db or worse
18:39:52 <Sparks_too> and it's impossible to know the answer to now.
18:40:00 <stickster> It's probably more like a complicated query and then sending the info into the new schema somehow
18:40:07 <mchua> Sparks_too: Excellent, Dave_S and Andrea_H are in #teachingopensource right now, I can get them into #fedora-docs to say hello if you like, too
18:40:21 * rbergeron suddenly feels stupid for tweaking the actual query by hand rather than using the dropdown button when making reports for the marketing trac
18:40:24 <rbergeron> lol
18:40:27 <stickster> I'll be honest, I don't know the nature of the Zikula db schema vs. Drupal db schema.
18:40:34 <stickster> Are they even comparable?
18:40:37 <ianweller> stickster: no
18:40:56 <Sparks_too> mchua: or I could step over to their room if it's not busy
18:41:04 <stickster> ianweller: expound! :-)
18:41:12 <ianweller> stickster: they're just way different.
18:41:26 <mchua> Sparks_too: #teachingopensource is fairly quite, yeah - come on over
18:41:46 <mchua> Sparks_too: or, actually - will you be around tomorrow morning? The day is almost over for us now
18:41:56 <stickster> ianweller: In a way that would make porting content... way hard? Or just medium hard?
18:42:06 <Sparks_too> mchua: I will
18:42:24 * stickster has a pretty good idea that this sort of data migration never gets easier than "pretty hard"
18:42:47 <smooge> I would probably say dump and retype
18:43:09 <ianweller> smooge++
18:43:20 <stickster> Yikes
18:43:22 <Sparks_too> That would really be bad in a year or two
18:43:31 <smooge> at best, one window content A and in another editor B
18:43:37 <ianweller> think of the moinmoin -> mediawiki transfer, and then make it worse... :)
18:43:43 <stickster> smooge: That worries me, because essentially it means "Choose wisely the first time."
18:44:02 <smooge> yeah.. its the big downside of CMS tools
18:45:11 <smooge> in fact in many ways most CMS"s want you to really be locked in because it means you are more likely to go for commerical support at some point
18:45:20 <smooge> its the heroin
18:45:37 <Sparks_too> sounds fairly anti-opensource
18:45:55 <Sparks_too> protocol-wise
18:46:00 <stickster> Sparks_too: Well, only in the sense that "I'd rather pay you to do the work than figure it out myself"
18:46:23 <Sparks_too> yeah
18:46:27 <stickster> Which is very much in keeping with open source principles
18:46:37 <stickster> As long as you don't *stop* me from learning how :-)'
18:46:38 <Sparks_too> Standardization of backend would be a big plus
18:47:39 <smooge> yeah.. but thats like getting art people to decide which color is the best
18:47:57 <Sparks_too> true
18:48:28 <stickster> OK, I'm going to put some time this weekend into figuring out a Drupal plugin for AuthFAS
18:48:30 <Sparks_too> well, we know that's not the case so...
18:48:31 <smooge> about the only way it happens is when someone comes out with an RFC and says you want our money you have to store your stuff like this
18:48:46 <stickster> #action stickster to research and maybe try a hand at Drupal plugin like AuthFAS
18:48:53 <stickster> So that we have options moving forward
18:49:06 <Sparks_too> stickster: I can probably do some research on clustering if that would be helpful
18:50:02 <stickster> Sparks_too: Probably your time is best spent cobbling on an instance on your own host
18:50:25 <Sparks_too> stickster: Well, I was going to setup a bunch of virtualized servers this weekend...
18:50:36 <Sparks_too> I was going to cobble Drupal on all of them..  :)
18:50:53 <stickster> I think the question of making either Drupal or Zikula work over multiple app servers has basically the same answer
18:51:15 <stickster> so if you can figure one out, you've probably got the other figured as well
18:51:34 <smooge> actually no
18:52:19 <smooge> scalability is usually a deep down issue... with locking issues and such. One might have been written that way and the other not
18:52:35 * stickster definitely defers to more experience
18:52:50 * stickster gives up second career in web app consulting
18:53:10 <stickster> Sparks_too: Shall I action you on that then?
18:53:44 <Sparks_too> stickster: I'll do my best!
18:53:56 <stickster> smooge: Are we concerned about multiple db servers too?
18:54:05 <stickster> Or just multiple app servers and front end proxies?
18:54:56 <smooge> at the moment just 1 db and multiple app/proxy servers
18:55:02 <stickster> #action Sparks_too to research procedure for distributing Drupal over multiple app/proxy servers
18:55:09 <stickster> smooge is doing this for the Zikula case.
18:55:30 <stickster> OK, I don't want to belabor this, but we're running out of time so I want to be candid
18:55:42 <smooge> I want to make sure that if you edit on app7 you aren't locking up everything until you are done OR that someone on app6 will be able to edit stuff
18:55:42 <Sparks_too> smooge: So no db replication
18:55:52 <drak> greetings
18:55:57 <smooge> I don't think we are set up currently for db replication
18:55:59 <drak> finally my internet works
18:56:36 <Sparks_too> smooge: Cool.
18:57:14 <stickster> I'm going to be spending some time on the Insight 2.0 route myself, and I want to engage on that as quickly as possible.
18:57:16 <Sparks_too> stickster: There is also the capability to run several sites from a single instance of Drupal... of course that should work fairly easily if the single site works.
18:57:46 <drak> Zikula can do this
18:58:18 <stickster> Team: We missed our milestone, as set out here: https://fedoraproject.org/wiki/Insight#Goals
18:58:34 <stickster> drak: Yes, smooge is looking into this for Zikula as well
18:59:06 <stickster> We are at staging, but we're still in an uncertain state for production.
18:59:35 <stickster> If smooge is the only person who's going to be working on the infrastructure, that doesn't bode well for our ability to roll out to production and maintain over time.
18:59:59 <smooge> sorry dealing with a page
19:00:17 <drak> what is remaining for it to go into production?
19:00:37 <smooge> drak I need documentation on what is needed to do this and how
19:00:53 <stickster> drak: There's = a list of tickets we've been tracking for some time, which we refer to in our meetings, and on the wiki.
19:00:56 <stickster> s/=//
19:00:57 <smooge> stickster, I would like to get some more people into infrastructure on this.. but its a time/focus thing
19:01:01 <stickster> smooge: Right
19:01:23 <drak> i thought the idea was to push it live first, then focus on training and building the number of contributors
19:01:40 <drak> I can send you people after it goes live.  We've people itching to do stuff
19:01:58 <drak> Do you have a list of "what to document"
19:03:48 <stickster> drak: I thin our infrastructure guys want to feel confident that when we put a site out, it's backed already by at least a few people who are watching over it. I thought mateo was one of those people, but we haven't had him at meetings so we can plan effectively
19:04:25 <stickster> I'm very grateful we have help from Zikula folks to address some of the issues we've been running into
19:05:29 <stickster> But part of the process that's essential to any project in Fedora is open meetings where we can keep everyone up to date on current problems, progress, etc.
19:05:50 <stickster> Maybe we haven't communicated that well, and if not, that's my fault
19:07:03 <drak> well yes, you guys do seem to have a lot of meeting requirements and so on. not so easy to work async like this (you should really try Google Wave).
19:07:11 <stickster> Not free :-)
19:07:25 <drak> i guess that's a joke
19:07:30 <drak> heh
19:07:33 <stickster> :-D
19:07:41 <rbergeron> as in freedom....
19:07:50 <stickster> Yeah, I think drak was being ironic
19:08:06 <drak> seriously, Google wave really allows incredible async collaboration - but I guess this isnt the point... but maybe it is
19:08:16 * rbergeron still feels like she's been run over by a bus
19:08:41 <drak> at one point we tried to have regular meetings, but it is hard to maintain and keep a large number of participants (I found anyhow).
19:09:17 * stickster notes by clock we're :08 minutes overtime.
19:09:28 <stickster> Er, :09
19:09:44 <drak> so what can we do anyhow
19:09:56 <drak> I'd very much like to get this 'signed off'
19:10:20 <drak> but despite all the meetings etc, minutes and so on I am still not clean what is actually pending
19:11:17 <stickster> Current tickets: https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&keywords=~zikula&keywords=~insight&order=priority
19:11:26 <drak> and really, i would strongly suggest you find a way to allocate tasks without needing the volunteers to HAVE TO attend a meeting.
19:11:52 <drak> if you want to increase your number of volunteers, reduce that requirement... people hate meetings
19:11:52 <stickster> drak: Right, the ticket queue above is supposed to provide that
19:12:04 <drak> awesome :)
19:12:21 <stickster> drak: But we've been pointing to that list, or a variant, for some time
19:12:33 <drak> wow, there are old tickets there!
19:12:48 <smooge> drak I need a list of settings and documentation on how to deal with a zikula web farm. my google skills have failed me
19:13:05 <drak> would you mind mailing me some questions?
19:13:22 <stickster> smooge: You can cc: the logistics@ list on that too
19:13:38 <drak> in fact, if you dont mind using Google Wave, I can get a bunch of people to document everything
19:13:43 <smooge> drak, what is your emaill address you can pm me if you need
19:13:50 <drak> drak@zikula.org
19:14:21 <stickster> #action smooge and drak to talk by email about web farm requirements
19:14:23 <smooge> ok will email you after a couple more meetings
19:14:56 <drak> sweet
19:15:41 * stickster notes that we have the logistics@lists.fp.o list for async talk, as well as the tickets
19:15:43 <smooge> ok I have to go do something else. I will be back in a bit
19:15:46 <stickster> Thanks smooge
19:16:15 <drak> tc
19:16:27 <stickster> rbergeron: Did you have anything to add here?
19:16:37 <rbergeron> i do not.
19:16:58 <stickster> OK, I'm going to call it then.
19:17:01 <stickster> #endmeeting