19:00:03 <stickster> #startmeeting Insight
19:00:03 <zodbot> Meeting started Mon Apr  4 19:00:03 2011 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:05 <stickster> #meetingname Insight
19:00:05 <zodbot> The meeting name has been set to 'insight'
19:00:09 <stickster> #topic Roll call!
19:00:10 * stickster 
19:00:15 * rbergeron !
19:01:02 <pcalarco> present
19:01:42 * Sparks 
19:02:18 <stickster> #link https://fedoraproject.org/wiki/Fedora_Insight#Meeting_agenda <-- Agenda for today
19:03:14 <asrob-eee> hi
19:03:18 <stickster> #chair pcalarco rbergeron Sparks asrob-eee
19:03:18 <zodbot> Current chairs: Sparks asrob-eee pcalarco rbergeron stickster
19:03:33 <stickster> #info present pcalarco rbergeron Sparks asrob-eee stickster
19:03:42 <stickster> #topic Drupal status
19:03:59 <stickster> OK, I sort of bypassed our last meeting action items, because, well, they're all done :-)
19:04:09 <stickster> The long and short of the status is that we now have http://insight.fedoraproject.org
19:04:34 <pcalarco> yay, bravo!
19:04:34 <stickster> Thanks to help from smooge, abadger1999, nirik
19:04:46 <asrob-eee> awesome \o/
19:04:58 <rbergeron> HOORAY
19:05:08 * averi is around
19:05:08 <stickster> #info Present: averi too!
19:05:11 <stickster> #chair averi
19:05:11 <zodbot> Current chairs: Sparks asrob-eee averi pcalarco rbergeron stickster
19:05:26 <stickster> pcalarco: I've made a couple changes in the FWN announcement stories on the site, that should make sense to you -- basically, use relative links for things so they'll work wherever we're working on the data
19:05:35 <averi> stickster gave the announcement? :)
19:05:36 <stickster> i.e. /fwn/269
19:05:46 <stickster> averi: Not yet, we have a couple things to discuss here first
19:05:59 <averi> sure, sorry, i thought that HOORAY was for that :)
19:06:25 <stickster> It's not a secret that it's done, it's an open project of course... :-) But it would be nice to make sure our content is a little more robust for a big announcement.
19:06:31 <pcalarco> stickster:yes, understood and makes sense
19:06:40 <stickster> Having the news is the first and most important priority, and that really does work
19:08:12 <stickster> I'd also like to get Marketing help looking through some of the recent planet posts to see what's worth elevating into that filtered feed
19:08:39 * rbergeron nods
19:08:51 <stickster> Here's how that works in a nutshell: Insight reads the Fedora Planet. It makes a copy of every post that appears there, but it doesn't republish anything unless someone goes into the "Moderation queue" and marks it as published.
19:09:16 <Sparks> could there be a licensing issue here?
19:09:23 <stickster> When published, that blog post will show up in the links on the upper right under Fedora Planet highlights
19:09:49 <stickster> Sparks: Yes, which is why whoever publishes it needs to check with the author to get permission, *unless* the post is provided under CC-BY or CC-BY-SA license.
19:10:00 <Sparks> good call
19:10:01 <stickster> (or CC-0 I suppose)
19:10:34 <stickster> rbergeron: Can I get you to make this known in a SOP document, link it from the Insight page, and make it well-known in Marketing?
19:11:12 <rbergeron> stickster: yes, if you give me a few days - /me needs to play with insight and hasn't done so yet and probably should do that before writing a how-to ;)
19:11:18 <stickster> rbergeron: Certainly
19:11:32 <stickster> rbergeron: I'd like to try and have that done by end of the week.
19:12:00 <rbergeron> #action rbergeron to SOP planet moderation queue for Marketing team
19:12:00 <stickster> rbergeron: At the same time as you're doing that, some of us will also be working on development tasks, just so you don't feel you got socked with the first action item :-D
19:12:31 <rbergeron> #info read meeting minutes for some details to document re: licensing when republishing blog postsw
19:12:40 <stickster> awesome.
19:13:19 <stickster> Pascal -- the system is set up so that, if desired, you can have people write their beats directly on Insight. That doesn't have to transition until/unless the FWN staff is ready to do that.
19:13:45 <pcalarco> stickster: sounds great
19:14:14 <stickster> pcalarco: I would recommend that you guys look at either standardizing your beat writing, or having someone(s) edit for consistency -- could produce a nicer end result.
19:14:30 <stickster> Just a proposal for the team, it's really up to them whether they want to worry about it.
19:15:27 <stickster> pcalarco: And if you find content is not coming out looking right -- that can be reported via a ticket and we'll fix it ASAP
19:16:03 <pcalarco> stickster: I have been watching beats to catch writing that falls outside of standards and correcting those, and making suggestions to beat writers, yeah
19:16:08 <stickster> Cool
19:16:24 * stickster thinks we're getting into a "stuff TODO" mode now...
19:16:27 <stickster> Can I /topic?
19:16:35 <pcalarco> its important for a consistent product
19:16:40 <stickster> *nod
19:17:18 <stickster> #topic Development going forward
19:17:39 <stickster> #idea We need to come up with a way to keep doing development on pt09, so we can work rapidly
19:17:58 <stickster> #info At the same time we need to be sure to document as we go, and everyone needs to be vocal about what they're doing
19:18:54 <stickster> Over the weekend, averi and I talked a bit about how we might be able to do this, especially in the situation that we can't just go in and take backup snapshots of the production database by SSH'ing somewhere and running mysql.
19:19:47 <stickster> This was an unforeseen speed-bump, but there's an easy way around it -- which is to have a Drupal module installed that lets us snapshot from within the app itself.
19:19:59 * stickster packaged that this weekend and it's waiting on review
19:20:24 <stickster> .bug 693117
19:20:26 <Sparks> stickster: So it does a db snapshot and puts it in a flat file?
19:20:27 <zodbot> stickster: Bug 693117 Review Request: drupal6-backup_migrate - Database backup, restore, and migrate module for Drupal 6 - https://bugzilla.redhat.com/show_bug.cgi?id=693117
19:20:51 <asrob-eee> Sparks: yep
19:20:58 <stickster> Sparks: Yes, it's basically just a mysql dump with specific tables removed (object caches or logs that don't need to come over)
19:21:14 * Sparks can already see deploying this on his instances of Drupal
19:21:40 <averi> I checked it out and we can even do scheduled backups if needed
19:21:51 <stickster> If we can grab a snapshot from within the app, then we don't have to have a bunch of people with infrastructure access that only need it for one specific database.
19:21:54 <asrob-eee> averi: yeah, it's great tool :)
19:22:07 <stickster> averi: The scheduled backups are already happening for us through the infra team, they run that for all db01, db02 products
19:22:12 * Sparks will do the review on this package later tonight.
19:22:22 <averi> so we'll just have to setup a profile on the backup_restore module and run it with cron within the built-in cron module of backup_restore
19:22:36 <averi> stickster, yup, but we can't access them atm :)
19:22:56 <averi> either those or the ones available in db01
19:23:25 <stickster> averi: Right, we'll add the package and cron file in puppet -- so it should get brought in either automatically, or we can get someone in core infra team to run puppet to bring them in.
19:23:46 <stickster> #action Sparks do review on bug 693117
19:24:40 <stickster> #action stickster Do puppet changes in staging, test, and then get infra help moving the changes to production. The production change will have to wait until after freeze.
19:25:49 <averi> agreed :)
19:25:52 <stickster> #agreed We'll use backup_migrate to get us db snapshots when needed for development/testing on pt09
19:26:27 <stickster> So that brings me to another piece of the same puzzle, which is how to manage our development going forward. We want to be able to tinker with a host without that host being the production one :-)
19:26:54 <stickster> Both production and staging have back end databases we can't fool around with, which is a good thing... but we need one that we can fool around with for development
19:27:06 <averi> pt09 should be ok
19:27:12 <averi> I can ask smooge to keep it for us
19:27:50 <stickster> averi: That would be great, thanks
19:27:59 <averi> stickster, when the rc for insight.fp.o will be up, I'll just import the final db to pt09
19:28:26 <averi> and that will happen as soon as we have the backup_restore module ready to go
19:29:32 <stickster> averi: OK, note the backup_restore module won't be able to deploy on the main insight.fp.o until after F15 Beta and the freeze lifts
19:29:36 <stickster> (Freeze starts tomorrow)
19:30:23 <stickster> #action averi ask smooge to keep pt09 in play for our use
19:30:34 <averi> stickster, I'll ask for someone scping the current db into my home folder into pt09
19:30:35 <averi> :)
19:31:55 <stickster> I think we should also agree that no one will *import* db's anywhere without checking with the team first, on the email list, and giving enough time for people to answer
19:32:08 <stickster> (unless the import is done somewhere brand new and thus we don't care) :-)
19:32:55 <averi> sure
19:33:07 <asrob-eee> :)
19:33:16 <averi> don't worry, I won't hide while doing things like stickster did!! :P
19:33:24 <stickster> Yeah, exactly averi !!! :-D
19:33:29 <asrob-eee> :D
19:33:36 <stickster> #agreed No one will import db's anywhere without getting +1's
19:33:41 <stickster> #undo
19:33:41 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x22969190>
19:33:44 <stickster> #agreed No one will import db's anywhere without getting +1's on list
19:34:19 <stickster> OK, so far we have a game plan for getting db snapshots, and we have a plan for when not to use them
19:34:30 <stickster> We still want a plan for when and where it's OK to use them
19:34:51 <stickster> And I wrote this up over the weekend among other things: https://fedoraproject.org/wiki/How_to_develop_for_Insight
19:35:05 <stickster> #link https://fedoraproject.org/wiki/How_to_develop_for_Insight <-- proposal for how to make changes
19:35:54 <asrob-eee> stickster: it's great, thanks
19:36:07 <rbergeron> /win 3
19:36:20 <stickster> rbergeron: I'm WINNING
19:36:44 <rbergeron> TRI-WINNING according to my typo!
19:37:03 <stickster> #info That link is missing some information on how to conduct content freezes on the main insight.fp.o site
19:38:21 <stickster> Does someone have suggestions for how we should do that?
19:38:54 <asrob-eee> yep, I will help
19:40:23 * stickster suspects freezes will not be necessary often, because most of our changes will be module configuration, added views, filters, etc.
19:40:35 <rbergeron> AGH
19:40:46 <stickster> asrob-eee: Are you going to tell us your idea here, or do you want to write it to the list?
19:41:08 * rbergeron has to run, apparently daughter just threw up at school
19:41:30 <stickster> ruh roh, see you rbergeron, good luck and hope she feels better
19:41:45 <asrob-eee> stickster: about how to moderate contents?
19:42:20 <stickster> asrob-eee: No, about how to conduct a content freeze on the production site
19:42:45 <stickster> In case we have to make sure no more content nodes are added while we are making a change
19:42:49 <asrob-eee> stickster: hm, I don't really understand it :(
19:42:53 <stickster> I guess we could just use "maintenance mode" for that
19:44:11 <asrob-eee> stickster: when you are adding a new content, don't need to use "maintance mode"
19:44:29 <asrob-eee> stickster: if you are upgrading modules or core, then you have to use that
19:44:42 <stickster> asrob-eee: Sorry, I'm not being clear enough. I mean, how do we stop new content while we are doing some sort of database change, like importing something from development
19:45:00 <stickster> Maybe this is not necessary most of the time?
19:45:23 <stickster> Ah, I think it would be less confusing if I explain the idea in that proposal above ^^
19:46:27 <stickster> My proposal is: To address issues on the main site, we must always file a ticket. The fix must be documented in the ticket. The steps have to be tested on our development server (we can use snapshots of the production data there). The change must be approved by the team, and then the steps that have been documented are made in production.
19:47:03 <stickster> I'm just wondering... are there any kinds of changes that we *couldn't* handle in that process?
19:47:20 <asrob-eee> ah, yes, imho it's great
19:48:09 <stickster> #idea What do we consider "approved" by the team? Can we call that two (2) "+1" votes?
19:48:13 <asrob-eee> if our changes is production ready then we should build that from scratch
19:50:28 <stickster> ^^
19:50:28 <stickster> pcalarco: averi: Sparks: (anyone) ^^^
19:50:28 <stickster> Can we consider two "+1" votes to be an approval in a ticket for a change?
19:50:30 <stickster> That way it's clear when something is approved and can move on
19:50:38 <averi> sure
19:50:41 <asrob-eee> +1
19:50:47 <averi> two +1 are usually enough :)
19:50:56 <stickster> OK, that's two +1's there, so we're agreed on that agreement :-D
19:51:02 <asrob-eee> :)
19:51:08 <stickster> #agreed Two +1 votes in a ticket constitute an approvall
19:51:15 <stickster> OK
19:51:40 <stickster> Should we also vote on that proposal today as well? Or do you guys need time to read it more carefully?
19:52:27 <averi> which proposal are you talking about?
19:52:40 <stickster> averi: The proposal on how to make changes, documented at https://fedoraproject.org/wiki/How_to_develop_for_Insight
19:53:20 <asrob-eee> I have to read it carefully, I am not good in English today :(
19:53:38 <averi> stickster, let's vote it on the next meeting
19:54:11 <stickster> averi: OK, should be no problem since we're going to need a little time to get past freeze anyway.
19:54:14 <averi> stickster, re: insight's pt09
19:54:32 <stickster> #agreed We'll look at proposal and vote next week on it, or approve on list before that.
19:54:39 <averi> stickster, we can't keep the pt09 box for too long
19:54:55 <averi> we need an RFR for an insight01.dev box instead
19:55:09 <stickster> averi: Can you pursue that then?
19:55:18 <averi> yeah!
19:55:20 <averi> :)
19:55:23 <stickster> I am going to be SUPER busy the next week or two and won't be able to work on it :-(
19:55:36 <asrob-eee> stickster: could you give me a link about our phase 2?
19:55:37 <averi> i will write the required docs and ask it
19:55:51 <pcalarco> stickster: sounds good
19:55:52 <stickster> asrob-eee: It's the [[Insight project plan]] page on the wiki, linked from the main page
19:55:56 <stickster> averi: Thank you!
19:56:00 <asrob-eee> stickster: okay, thanks
19:56:10 <averi> stickster, np :) please add an item so that i don't forget :)
19:56:15 <stickster> #action averi Write RFR for insight.dev box, and get that up and running
19:56:23 <asrob-eee> stickster: could I work on that?
19:56:30 <stickster> asrob-eee: On the .dev box?
19:56:44 <asrob-eee> stickster: on the phase 2
19:57:10 <asrob-eee> and yeah, on the .dev box or do I on my instance?
19:57:28 <stickster> asrob-eee: Sure, but I think the idea is that anything you want to do for phase 2 should get a ticket, and follow the change process -- so we should approve that frist
19:57:29 <stickster> *first
19:57:42 <stickster> asrob-eee: You can work on things and document them in the meantime
19:57:56 <asrob-eee> stickster: OK
19:58:03 <stickster> I would suggest filing the tickets and documenting now, and then we'll put those things on the .dev box, not pt09
19:59:13 <asrob-eee> stickster: I am trying to fix our issues in the next days
19:59:23 <stickster> #action asrob-eee start filing tickets for phase 2 work, document and test privately in spare time as desired, and we'll deploy on .dev box when it's ready
19:59:38 <stickster> asrob-eee: The challenge here is that we don't want to have too many copies of our db floating around with all different changes
19:59:52 <stickster> So I would stick to tickets, documenting in them, and your own sandbox until we have .dev up
20:00:04 <stickster> As opposed to doing work on pt09 which might be destroyed with an import of data from the production site
20:00:30 <asrob-eee> okay
20:01:15 <asrob-eee> I won't work on those, I am waiting for the green signal :)
20:01:44 <asrob-eee> I am fixing our tickets like RSS icons next to the beats
20:01:50 <stickster> OK, I need to go for another meeting
20:02:04 <averi> stickster, NO, don't leave us :(
20:02:19 <pcalarco> asrob-eee: thank you for that!
20:02:46 <asrob-eee> np :)
20:04:08 <stickster> We need to make way for next group, let's end and go to #fedora-mktg for anything else
20:04:13 <stickster> We have plenty to work on it sounds like :-)
20:04:18 <stickster> Thanks to everyone for coming!
20:04:26 <stickster> #endmeeting