20:00:56 <mmcgrath> #startmeeting
20:01:08 <mmcgrath> #topic Infrastructure -- Who's here?
20:01:08 * mchua here
20:01:27 * mmcgrath is here
20:01:28 * sijis is here
20:01:28 <mdomsch> here
20:01:29 * tmz watches
20:01:31 * jpwdsm is here
20:01:47 * ricky 
20:02:04 * abadger1999 here
20:02:24 <mmcgrath> Ok, lets jump right in to it then
20:02:32 <mmcgrath> #topic Infrastructure -- Alpha Release
20:02:39 <mmcgrath> The alpha release is next week
20:02:52 <mmcgrath> Lets go over these tickets and make sure things are all good
20:03:01 <mmcgrath> https://fedorahosted.org/fedora-infrastructure/report/9
20:03:03 <mmcgrath> .ticket 1608
20:03:18 <mmcgrath> I talked with Jesse yesterday and it seems we're good on space.
20:03:23 <mmcgrath> I'll re-verify today though.
20:03:29 <mmcgrath> .ticket 1607
20:03:32 <mmcgrath> ricky: you on this one?
20:03:49 <tmz> I can help out with that ricky.
20:03:54 <ricky> Yup, tmz has been working on branching and getting F12 keys up
20:04:10 <mmcgrath> ricky: tmz: will one of you accept that ticket so it goes to assigned?
20:04:18 <ricky> And I'll be getting some new contributors on making get-prerelease and checking URLs so that other people know what to do during the release
20:04:27 * SmootherFrOgZ is around
20:04:30 <ricky> I'll accept it and CC web-members
20:04:35 <mmcgrath> k
20:04:45 <mmcgrath> ricky: tmz: that'll all be ready in time for the alpha?
20:04:48 <sijis> ricky: i'm available to help too.
20:04:51 <ricky> Yup
20:05:35 <mmcgrath> k
20:05:37 <ricky> sijis: Thanks - I'll get a list of tasks documented on the wiki soon
20:05:42 <mmcgrath> .ticket 1609
20:05:47 <mmcgrath> This is just the release day tracker ticket.
20:05:53 <mmcgrath> .ticket 1610
20:06:05 <mmcgrath> SmootherFrOgZ: you've done this in the past, want to do it again?
20:06:38 <mmcgrath> if not I'll grab it.
20:06:41 <mmcgrath> Oxf13: you around?
20:07:14 <mmcgrath> I'll go ahead and accept this
20:07:14 <SmootherFrOgZ> mmcgrath: sure
20:07:16 <mmcgrath> jwb: you around?
20:07:26 <mmcgrath> oh good
20:07:31 <mmcgrath> SmootherFrOgZ: would you mind accepting that ticket?
20:07:37 <SmootherFrOgZ> no problem
20:07:45 <mmcgrath> follow up with releng and see if the bits are already staged, they might be.
20:08:02 <mmcgrath> next
20:08:09 <mmcgrath> .ticket 1611
20:08:22 <mmcgrath> mdomsch: ?
20:08:42 <mdomsch> mmcgrath, I probably need to do those
20:08:50 <mdomsch> I haven't looked at what redirects are in place yet
20:08:53 * mdomsch takes it
20:08:58 <mmcgrath> k
20:09:02 <mmcgrath> mdomsch: you da man, thanks
20:09:06 <mmcgrath> .ticket 1612
20:09:22 <mmcgrath> The change freeze is in affect.  I did mess up and start it later then normal but that's ok because we slipped.
20:09:26 <mmcgrath> and last
20:09:29 <mmcgrath> .ticket 1613
20:09:36 <mmcgrath> that's not something we have to do until after the release.
20:09:50 <mmcgrath> Ok, so does anyone have any outstanding concerns about the release from an Infrastructure point of view?
20:10:17 <mmcgrath> allrighty.
20:10:26 <mmcgrath> So the next thing on the list is to talk about Smooge's recent trip
20:10:33 <mmcgrath> #topic Infrastructure -- The Smooginator
20:10:35 <mmcgrath> smooge: you around?
20:10:39 * mmcgrath notes he might be faxing right now
20:11:09 <smooge> I am
20:11:13 <smooge> faxing right now
20:11:21 <mmcgrath> smooge: should we come back to you?  :)
20:11:58 <mmcgrath> we'll get back to the smooge :)
20:12:22 <mmcgrath> #topic Infrastructure -- Alt/network issues
20:12:30 <mmcgrath> so it seems we're having some network issues downloading from PHX.
20:12:44 <smooge> sorry give me 5 minutes.. I am using up all my upload speed
20:12:50 <mmcgrath> I've contacted the network team in charge of all of that, they did some similar tests and have at least been able to reproduce the 1MB/s download speed.
20:12:54 <smooge> ah crap did I mess soemthing up?
20:12:59 <mmcgrath> which is an order of magnitude slower then what we see elsewhere.
20:13:14 <mmcgrath> Nothing real interesting there.
20:13:24 <mmcgrath> smooge: Highly doubtful.
20:13:34 <mmcgrath> it's reproducable to all of our hosts in PHX.
20:13:42 <mmcgrath> and we're seeing other oddities related to port speeds.
20:13:55 <mmcgrath> for example iptraf shows 1M transfers on port 80 but 70M transfers on port 8080
20:14:06 <mmcgrath> sounds like QoS misconfiguration but I've been told it's not being used.
20:14:09 <smooge> ok.. I was noticing that getting stuff off of puppet1 last night was about 4mb/s
20:14:13 <smooge> in the colo
20:14:22 <mmcgrath> smooge: 4Mbps or MBps?
20:14:34 <smooge> hmmm whatever scp says
20:14:40 <mmcgrath> <nod>
20:14:41 <smooge> I think its MBps
20:14:43 * mmcgrath will look.
20:14:50 <mmcgrath> either eay, it's not the speeds I think we should be seeing.
20:14:57 <mmcgrath> That's really all there is on that.
20:15:01 <mmcgrath> #topic Infrastructure -- Zikula
20:15:05 <smooge> rsync died completely with a stall so I switched to scp
20:15:06 <mmcgrath> mchua: around?>
20:15:13 <mmcgrath> smooge: yeah I've seen that too.
20:15:16 <ricky> smooge: I've seen stalled scps to puppet1 too
20:15:30 <mchua> mchua: yes.
20:15:34 <mchua> ergh, mmcgrath yes.
20:15:48 <mmcgrath> mchua: want to talk about the zikula install you're wanting us to get up and going?
20:15:59 <mchua> .ticket 1615
20:16:03 <mchua> That'd be it.
20:16:21 <mchua> that's for https://fedoraproject.org/wiki/Fedora_Insight
20:16:25 <mmcgrath> mchua: who it's for, what you're wanting to do with it, etc
20:16:46 <mchua> it's a Marketing project, the user audience is going to be folks who aren't yet Fedora contributors.
20:17:04 <mchua> so the various marketing materials we usually pump out for each release - dev interviews, feature profiles, etc.
20:17:27 <mchua> will all be there for journalists, users, etc. to go to, and for Ambassadors to grab from, and for the NDN to pump things to newspapers from.
20:17:53 <mchua> we've got an ambitious schedule, we want to have this up for beta so that Ambassadors can use it when they start turning the big PR wheel.
20:18:01 * mchua posts schedule to wiki
20:18:46 <mchua> currently we have an instance up on pt6
20:18:59 <mchua> http://publictest6.fedoraproject.org/zikula/
20:19:05 <mmcgrath> mchua: and is http://fedoraproject.org/insight/ a good location for you or would you prefer insight.fedoraproject.org/zikula/ ?
20:19:09 <mchua> schedule is here: https://fedoraproject.org/wiki/Fedora_Insight#Schedule
20:19:21 <mchua> mmcgrath: fp.o/insight, with a redirect to that from insight.fp.o, would be great.
20:19:33 <mmcgrath> coolz, we can certainly do that.
20:19:36 <mchua> (no "zikula" needed in URL.)
20:19:58 <mchua> mmcgrath: any other info you were looking for?
20:20:11 <mmcgrath> mchua: not at the moment.
20:20:24 <mmcgrath> mchua: you have anything else?
20:20:36 <mchua> mmcgrath: huge thank you to you and tmz and ricky for all the patience + advice + help so far.
20:20:36 <mchua> that's it.
20:21:19 <mmcgrath> well, don't thank us yet.  We're not done :)
20:21:24 <mmcgrath> Ok.
20:21:32 <mmcgrath> smooge: you done faxing?
20:21:40 <smooge> yes
20:21:48 <mmcgrath> #topic Infrastructure -- The Smooginator
20:21:55 <mmcgrath> smooge: tell us a bit about your trip, what you did, etc.
20:22:00 <smooge> I have come back
20:22:32 <smooge> Ok I arrived on site on Monday and worked Jonathan Pickard on getting some hardware moved out of racks and new stuff put in
20:22:49 <smooge> Hardware wise, xen4 is gone from the rack.
20:23:07 <smooge> backup1 went from a 2950 to an IBM x3650
20:23:20 <smooge> and the tape storage is now an LTO-4 with a full box of tapes on it.
20:23:45 <smooge> I went through and labeled backup1 and sign-vault1 and looked at the various wiring and other problems.
20:24:03 <ricky> Did our total backup capacity go up then (as in can we afford to keep more at a time for example?)
20:24:14 <smooge> I also toured the new racks at PHX2 which was like being in geek heaven
20:24:22 <mmcgrath> ricky: it would have doubled.
20:24:23 <smooge> Our total should have more than doubled
20:24:50 <ricky> Nice - will we be editing the retention periods in bacula, or are there other plans for that space?
20:24:57 <smooge> the LTO-4 are 800 GB tapes and we have 22 tapes when we had 20 good tapes before
20:25:12 <smooge> I think we will be keeping the bacula the same at the moment.
20:25:36 <smooge> the current retention was too much for the old tapes from the amount of purging we did
20:25:37 <mmcgrath> ricky: that space is already long taken up I think :)
20:25:41 <mmcgrath> by /mnt/koji.
20:25:53 <ricky> Hehe
20:25:53 <mmcgrath> /mnt/koij == teh suck
20:26:03 <smooge> it will need 2 weeks to gauge how we look next
20:26:06 <mmcgrath> smooge: anyway, thanks for going out and doing that.
20:26:24 <smooge> the wiring at PHX1 is abysmal and we are way over power in one rack
20:26:45 <mmcgrath> smooge: yeah, the thing that sucks about the power is we were kind of forced into that.
20:26:50 <smooge> I was hoping to put in some extra 1 U PDU's for some boxes but didnt have time in the end
20:26:51 <mmcgrath> you saw the other rack where we only have one pdu?
20:26:56 <smooge> yes.
20:27:02 <mmcgrath> hopefully moving to PHX2 will help correct all of this.
20:27:13 <smooge> I think what we should look at doing is sending all our new hardware to PHX2 and work out a storage plan for there.
20:27:37 <smooge> Then we will work out how we will do a transfer of old hardware.
20:27:43 <mmcgrath> there's already a plan to move stuff over but I've never been given a timeline yet.
20:27:49 <mmcgrath> nor how long we'll have to do it.
20:27:53 <smooge> Finally I saw our pile of delapidated hardware.. it was uhm impressive
20:27:55 <mmcgrath> I think most of our stuff can go over in small segments.
20:28:09 <mmcgrath> but some stuff, like the buildsys, might have to go over in one swoop.
20:28:27 <smooge> I would like to have the guys RHIT are using to wire things at PHX2 for our stuff.
20:28:27 <ricky> Do we have enough space reserved in PHX2 already?  Cool
20:28:31 <smooge> it was so pretty
20:28:33 <mmcgrath> though the blade center is EOLed as of next year so we might just be able to purchase a new thing.
20:28:35 <smooge> it made me cry
20:28:39 <mmcgrath> smooge: you nkow RHIT wired PHX1 too right?  :)
20:28:46 <smooge> different RHIT people
20:28:51 <mmcgrath> heheheh yeah
20:28:55 <mmcgrath> jonathan does good work there.
20:29:21 <mmcgrath> Well, I'll schedule a meeting and see what timeline we're looking at now.
20:29:27 <mmcgrath> Hopefully sooner then later.
20:29:28 <smooge> The wiring and power at the other places is very clear on how much we are oging to put in a cage at a time.
20:29:32 <mmcgrath> i also hear the PHX2 network stuff is far superior
20:29:46 <mmcgrath> <nod>
20:29:47 <smooge> we wont be putting as much in which will allow us to deal with power maximums better
20:29:55 <mmcgrath> smooge: have anything else?
20:30:15 <smooge> I will be writing up a report and passing it by people by tomorrow
20:30:29 <mmcgrath> coolz.
20:30:46 <mmcgrath> Ok, with that I'll open the floor
20:30:51 <mmcgrath> #topic Infrastructure -- Open Floor
20:30:56 <mmcgrath> anyone have anything they'd like to discuss?
20:31:16 <ricky> Welcome to jpwdsm - he's working on FAS OpenID - some of you may have seen the hosting request
20:31:20 <jpwdsm> I'd like to introduce myself
20:31:26 <mmcgrath> jpwdsm: please do
20:31:30 <abadger1999> jpwdsm: Welcome!
20:31:38 <jpwdsm> I'm Jason Walsh, new member of sysadmin sponsored by ricky
20:31:59 <jpwdsm> hopefully I'll be helping out with infrastructure's web apps, and as ricky said working on FAS + OpenID
20:32:07 <mmcgrath> that's exiting
20:32:20 <mmcgrath> it'll be nice to get the OpenID stuff finalized
20:32:47 <ricky> He's working in a pylons app for now, which we can either move into FAS later, or run separately if FAS doesn't get TG2 or Pylons-ified by then :-)
20:33:20 <ricky> TG1 did lead to some special pain with OpenID though which is why I didn't think it was worth it to put much more effort into that bit
20:33:37 <mmcgrath> ah
20:33:57 <ricky> (Particularly dealing with getting non-TG-modified request parameters and the poor framework for sessions which we might have hacked around somewhat)
20:34:41 <ricky> Anyway, thanks jpwdsm for taking this up - it's been on the back burner for a looong while :-)
20:35:03 <mmcgrath> jpwdsm: excellent
20:35:09 <mmcgrath> Ok, anyone have anything else they'd like to discuss?
20:35:21 <abadger1999> mmcgrath: Relicensing or not.
20:35:29 <mmcgrath> abadger1999: take it
20:35:52 <abadger1999> mmcgrath: So while you were gone, I think we ironed out all the wrinkles except stagin/publictest.
20:36:12 <abadger1999> ricky and I have two different ideas of how we could implement staging/publictest to comply.
20:36:12 <mmcgrath> is the problem still doing development on public facing hosts?
20:36:16 <abadger1999> yep.
20:36:29 <mmcgrath> if the problem is config files, could we make everything a config file?
20:36:45 <Oxf13> Sorry I was busy looking at a house
20:36:46 <Oxf13> back now
20:37:11 <abadger1999> heh :-)  config files aren't a problem but making everything a config file would mean why do we license at all :-)
20:37:24 <mmcgrath> Oxf13: no worries, just wanted to know if the alpha bits are staged or still in progress.
20:37:33 <Oxf13> staged on the mirror, about to be opened to other mirrors
20:37:36 <mmcgrath> abadger1999: so what are the two ideas?
20:37:40 <abadger1999> So myidea is to close off access to staging and publictest to everyone except sysadmin and select others that we allow in.
20:37:40 <Oxf13> er on the master mirror
20:37:43 <mmcgrath> Oxf13: excellent
20:37:44 <Oxf13> I'm still staging things to the torrent system
20:38:18 <abadger1999> staging can be done via mod_pgsql on the proxys, publictest could be handled by mod_auth_pam on the publictest machine itself.
20:39:00 <abadger1999> ricky's idea is to make those people who have AGPL apps responsible for keeping the source requirement met at all times.
20:39:04 <mmcgrath> and what's our gain to switch?
20:39:15 <mmcgrath> just code sharing?
20:39:29 <abadger1999> mmcgrath: essentially.  No one can take the code private.
20:39:41 <abadger1999> mmcgrath: It's the reason I like the GPL extended to web services.
20:40:24 <abadger1999> Right now, any of our web services could be taken private since the code wouldn't be distributed, just the service.
20:40:26 <mmcgrath> well, I have no more opinion on this subject now then I did a month ago so.
20:40:31 <abadger1999> <nod>
20:40:37 <mmcgrath> abadger1999: if you have something in mind you'd like to do, lets just do it.
20:40:43 <mmcgrath> or wait, what was ricky's opinion on it?
20:40:50 <mmcgrath> or did you two agree on the test/staging implementation?
20:40:58 <smooge> I would like to see a mixture of the two approaches
20:41:36 <ricky> I just don't like testers/users on publictest/staging have to deal with auth 100% for the sake of AGPL compliance
20:41:47 <ricky> **having
20:41:55 <smooge> If a person HAS to have open access in staging, they (the service owner) are on the hook for complying with the letter and spirit of the AGPL. If they don't want to, we will provide a nice password protected area for them
20:42:17 <ricky> Especially when we have staging pulling from an outdated FAS db and publictest using mod_auth_pam which is downright restrictive for non-sysadmin-test testers
20:42:36 <abadger1999> I think it's time for a decision.  But I would like you to leave it for you to decide.  I like the AGPL, but there's definitely costs associated with it.  If you don't think the benefit is worthwhile, we shouldn't switch.
20:43:23 <abadger1999> smooge, ricky: The one part of that is that we're contemplating switching all the web services we've written over to it.
20:43:49 * XulWork has an AGPL package
20:43:54 <abadger1999> So we'd be inconveniencing fas, pkgdb, elections, bodhi, etc development by making it something that the individuals have to manage.
20:44:08 <abadger1999> Err.. I guess that was more for ricky than for smooge :-)
20:44:49 <mdomsch> Given that our applications are already open source and hosted publicly (fedorahosted)
20:44:53 <ricky> Are most of our apps in risk of other people running them and not sharing the improvements?
20:44:57 <abadger1999> smooge: i'd rather set it up so that if you are AGPL, you must be in an account protected area.  if you're using another license that's fine.
20:44:59 <smooge> I think that we would need to revisit a lot of different areas of roll out on what environment gets what access etc. It happens for any project as it grows :)
20:45:11 <mmcgrath> mdomsch: but it makes things such more a pain in the ass
20:45:19 <mmcgrath> hell, I did work on smolt just last night that is now out of compliance.
20:45:20 <mdomsch> mmcgrath, right, AGPL does make it a PITA
20:45:26 <ricky> I'm not sure how much the AGPL brings for highly Fedora-specific apps like FAS and pkgdb and bodhi
20:45:29 <sijis> what if the pt web services/apps are populated from an scm only? the source would be available. and any chagnes to pt has to be through a scm.
20:45:29 <mdomsch> so the question is, what's the huge benefit?
20:45:48 <mmcgrath> mdomsch: just that we get to let legal tell us what to do and live with the consequences and like it
20:45:51 <mdomsch> someone could take FAS, pkgdb, bodhi code, run it themselves
20:45:54 <abadger1999> ricky: Well, fas is being used outside fedora.
20:45:57 <mdomsch> and not contribute back to the mainline projects
20:46:17 <mmcgrath> abadger1999: and you're in favor of the AGPL?
20:46:32 <mmcgrath> compared to the GPL for our web apps?
20:46:33 <mdomsch> so, the benefit is "forcing others to give us the changes they make to our code"
20:46:37 <abadger1999> ricky: And packagedb hasbeen considered -- but the present architecture is pretty fedora0centric.  I think by winter release we'll have some features that people will either want to run it themselves, or copy the features, though.
20:46:50 <mmcgrath> mdomsch: I think so.
20:47:01 <ricky> I imagine FAS would be slightly less attractive to rpmfusion if we put the AGPL on them too - they have patches that are highly specific to them :-)
20:47:08 <abadger1999> mmcgrath: I'm in favor of it on the basis of the benefits.  But I'm not as able to judge the costs as you.
20:47:28 <ricky> Although I doubt they'd stop using it over stuff like this.
20:47:31 <mmcgrath> ricky: what about you, whats your opinion.  Lean more towards AGPL or GPL?
20:47:40 <smooge> mdomsch, I don't see it as they are forced to give it back. Its on us to ask them for their changes. If we don't know that Bobs plumbing is using AGPL-FAS their changes will not be put in our tree
20:47:50 <ricky> I'm leaning more towards GPL because I don't see us as being at risk of what the AGPL is protecting us from
20:47:59 <ricky> For something like moksha it's more in the air for me.
20:48:04 <abadger1999> SmootherFrOgZ: What do you think of that?  Would AGPL compliance make fas less attractive to you?
20:48:27 <ricky> (As long as not everybody else has to deal with extra publictest/staging restrictions due to it)
20:48:29 <mmcgrath> smooge: whats your opinion.  Do you like the GPL or AGPL for our apps better?
20:48:42 <mmcgrath> our web apps.
20:49:57 <smooge> my opinion is that I like the IDEA behind the AGPL. I am not sure how the details of it being implemented will affect us
20:49:58 <abadger1999> elections is not very tied to fedora.
20:50:03 <abadger1999> :-)
20:50:13 <rsc> well, private patches must not upstreamed IIRC - even with AGPL.
20:50:29 <rsc> but IANAL, spot is the legal guy ;)
20:50:29 <SmootherFrOgZ> abadger1999: as i'm working with upstream, not really
20:50:37 <smooge> my opinion is tied to the fact that all of the questions and issues we keep bringing up are the same that I remember from 1992 and people licensing or not with GPL
20:50:43 <lmacken> speaking of elections, the Sugar Labs guys will be trying to deploy FAS and our elections app soon.
20:50:52 <lmacken> not sure if they contacted any of you guys yet
20:50:55 <ricky> Coool.
20:51:08 * ricky likes getting extra incentive to make FAS better.
20:51:09 <LinuxCode> rsc, any patches need to be made avilable under the agpl
20:51:15 <LinuxCode> even when testing
20:51:15 <mmcgrath> lmacken: haven't heard from him, hopefully he's interested in converting it to TG though :)
20:51:26 <lmacken> oh, elections isn't TG?  /me thought it was
20:51:29 <smooge> will elections ever support something other than the bane of my existence method?
20:51:31 * ricky has started vaguely dreaming about a TG2/Pylons version...
20:51:33 <ricky> lmacken: It is
20:51:36 <mmcgrath> lmacken: I thought it wasn't
20:51:39 <mmcgrath> ricky: is it?
20:51:42 <mmcgrath> ok my bad then :)
20:51:48 <mmcgrath> lmacken: hopefully he's interested in converting it to TG2 :)
20:51:50 <rsc> LinuxCode: uh, the FSFE has not identical thinking about when I got a lawyer correctly.
20:51:53 <lmacken> heh :)
20:52:09 <LinuxCode> rsc, well redhat legal is quite adamont
20:52:18 <rsc> LinuxCode: who cares about the US? ;)
20:52:20 <mmcgrath> abadger1999: ok, well.  Based on what I'm hearing from everyone there's not an overwhelming urge here.  Lots of meh's  and question marks.  I say for now we toe the line.
20:52:29 <abadger1999> rsc: heh -- it might depend on definitions of "testing" and "private".
20:52:31 <mmcgrath> abadger1999: if something changes later, we can always change later.
20:53:09 <abadger1999> mmcgrath: Sure.  Sounds good -- I'd like for us to license under GPLv2+ then, just like the proposal for our regular scripts.
20:53:09 <rsc> LinuxCode: the interesting point comes up, if upstream explicitly refuses your patch :)
20:53:10 <LinuxCode> rsc, red hat does
20:53:15 <mmcgrath> lots of the questions have been answered really, there's a few implementation details left.  But I just don't see the pro's as outweigning the cons.
20:53:16 <smooge> mmcgrath, abadger1999 in the end, I would like us to deploy moksha, deal with the kinks, relicense next, deal with the kinks etc
20:53:18 <mmcgrath> abadger1999: that sounds good to me.
20:53:26 <LinuxCode> rsc, that is besides the point
20:53:28 <rsc> LinuxCode: which causes less discomfort to RPM Fusion...
20:53:31 <abadger1999> Cool.
20:53:34 <mmcgrath> smooge: yeah, moksha's already deployed.
20:53:36 <LinuxCode> you must make patches available
20:53:48 <abadger1999> mmcgrath: The tangent that comes up is how do we want to deal with moksha/community?
20:53:50 <smooge> mmcgrath, I know.. we are in deal with he kinks stage.
20:53:54 <mmcgrath> we're all far better educated on this whole process, abadger1999, spot, lmacken thanks for that.
20:53:59 <lmacken> mmcgrath: partially... the messaging components of moksha aren't out yet, since we don't have an AMQP broker
20:54:03 <ricky> On staging/publictest, I'd like developers to handle their own patch posting
20:54:17 <lmacken> (partially, regarding moksha's deployment)
20:54:20 <mmcgrath> lmacken: hell even I've got plans for that broker, lets get it out :)
20:54:22 <abadger1999> mmcgrath: production is fine.  But we can't deal with it in staging and publictest without some sort of policy or change to the environment.
20:54:26 <ricky> So on publictest, perhaps set the footer link to a directory publictestx.fedoraproject.org/mokshapatches with patches
20:54:30 <lmacken> mmcgrath: yeah, I'm down.
20:54:41 <mmcgrath> abadger1999: well, we can write an AGPL sop for when we're dealing with AGPL code.
20:54:59 <ricky> On staging, they can do the ticket thing if those changes are going to make it into master soon, or commit those changes in git while they work (remind me if that's valid again?  :-))
20:55:00 <mmcgrath> abadger1999: which may just be a strict "rpm release only" model?
20:55:23 <abadger1999> mmcgrath: yeah -- it might be -- that limits the use case for publictest significantly, though.
20:55:34 <mmcgrath> abadger1999: or, alternatively, just not have it publically accessable during tests.
20:55:47 <mmcgrath> via your password protected setup.
20:55:49 <abadger1999> mmcgrath: Right.
20:55:49 <ricky> I think mod_auth_pam limits it even more - I think the public part of publictest is very valuable
20:56:06 <ricky> Ah, they could do that if they can live with limited public testing too :-)
20:56:16 <mmcgrath> well, it doesn't mean we can't use agpl stuff in pt, it just means that if we do, it has to match upstream by the time we allow others to use it.
20:56:42 <mmcgrath> hell, we could even script some sort of rpm -qV thing that puts a lock on the app if it's not matching
20:56:47 <abadger1999> Yep.  Okay, so I guess an AGPL SOP with discussion is the next thing I'll write up.
20:56:54 <mmcgrath> abadger1999: yeah
20:57:05 <abadger1999> In the meantime, I'll update the tickets for people to update code to GPLv2+.
20:57:06 <SmootherFrOgZ> abadger1999: yep, thx
20:57:20 <mmcgrath> abadger1999: thanks
20:57:24 <abadger1999> Excellent.
20:58:12 <mmcgrath> Ok, we're nearing the end of the meeting.
20:58:17 <mmcgrath> anyone have anything else they'd like to discuss?
20:58:46 <smooge> not me
20:58:55 <mmcgrath> Ok, well thanks for coming by everyone!
20:59:00 <mmcgrath> we'll close in 30
20:59:03 * mmcgrath forgot that part :)
20:59:30 <mmcgrath> 15(ish)
20:59:33 * mmcgrath isn't really counting
20:59:44 <rsc> [22:59:00] < mmcgrath> we'll close in 30
20:59:45 <mmcgrath> #endmeeting