16:30:32 <mmcgrath> #startmeeting
16:30:34 <mmcgrath> abadger1999: ping
16:30:36 <mmcgrath> rishi: ping
16:30:38 <mmcgrath> err
16:30:39 <mmcgrath> ricky: ping
16:30:41 <mmcgrath> rishi: sorry
16:30:43 <abadger1999> yep.
16:30:44 <mmcgrath> lmacken: ping
16:30:46 <ricky> pong
16:30:46 <mmcgrath> spot: ping
16:30:49 <mmcgrath> J5: ping
16:31:09 <J5> pong
16:31:32 * spot is here
16:31:51 * nixdude 1s too
16:32:04 <mmcgrath> I've not seen lmacken today so I'll assume he's not able to make it.
16:32:29 <mmcgrath> So this meeting's just a quick round up of what happened during the fedora community deployment, trying to shake out some communication issues, and hopefully clear up any misunderstandings.
16:32:36 <mmcgrath> or missed emails or notifications or anything
16:32:52 <mmcgrath> We have a hard stop in 30 minutes when the packaging committee meets and I hope it won't go anywhere near that long.
16:33:04 <mmcgrath> There's two main points of contention that I know of
16:33:16 <mmcgrath> 1) deployment times/expectations and 2) is the very late in the game license change.
16:33:24 <mmcgrath> anyone have anything they'd like to add to that?
16:33:48 <abadger1999> General communication is an issue but could be talked about some other time.
16:33:49 <mmcgrath> K, so I'll knock 1) out because I think it's more straight forward then 2)
16:33:53 <mmcgrath> yeah
16:34:08 <mmcgrath> So around the F10 launch, just a day or so before the launch J5 came to me asking for fedora community to be deployed.
16:34:19 <smooge> ok here I am
16:34:27 <ricky> s/10/11 :-)
16:34:30 <mmcgrath> We didn't know much about it at that time
16:34:33 <mmcgrath> ricky: this was F10
16:34:41 <ricky> Oh, wow, my mistake :-)
16:34:47 <mmcgrath> it was in our final freeze and I made it known that it was just not possible to deploy it at that time.
16:34:56 <mmcgrath> that final 2 week freeze is critical
16:35:04 <mmcgrath> So flash forward to F11.
16:35:16 <mmcgrath> We had a few minor issues when deploying to test,
16:35:19 <mmcgrath> we got it ready in staging.
16:35:26 <mmcgrath> but at no point in time did I have a date for when this was to go live.
16:35:41 <mmcgrath> Now, on the F11 release date, lmacken told me that it was to go live that day and that spot said so.
16:35:50 <mmcgrath> This put me in a horribly ackward position.
16:36:07 <mmcgrath> spot is very much one of us, but he's also the boss (both my manager and the Fedora Project Engineering lead)
16:36:14 <spot> So, we definitely had a communication breakdown here.
16:36:36 <spot> In our Fedora Community meetings, I repeatedly asked luke to make sure you knew about our schedule
16:37:04 <spot> I'm not sure where it fell apart, but we definitely can do better.
16:37:31 <mmcgrath> So if it was just a communications breakdown (that happens) then there's not much else to discuss on it.  We'll just all be more careful next time.
16:37:44 <mmcgrath> There were also some announcements that went out about it being live before it was actually live
16:37:47 <spot> Yeah, we had every intent of giving you advance notice.
16:37:54 <mmcgrath> but I don't think those were public
16:38:17 <spot> mmcgrath: yeah, that was because it was mentioned in the early F11 interviews
16:38:24 <mmcgrath> <nod>
16:38:25 <spot> before the instance was live
16:38:38 <J5> It partly has to do with not being clear on what checkmarks need to be hit to get things deployed.  What do you do to get it into staging and then what was needed after things were in staging to say ok it is good to go
16:39:00 <mmcgrath> so one note I think I'd like to make more clear (not related to fedora community directly) is that maybe we should have a more clear feature process similar to the OS.
16:39:10 <mmcgrath> our livecycle is very tied to the Fedora releases.
16:39:12 <J5> agreed
16:39:16 <abadger1999> J5: Partly but not all -- we would not make a new app go-live date coincide with the release date no matter what.
16:39:46 <mmcgrath> and I think we're starting to get into a little groove where stuff that gets deployed is related to the Fedora release (start.fedoraproject.org, mirrorlist, etc) all could directly impact users.
16:39:47 <abadger1999> We could announce it was live on that date but it would have already been deployed on the production instance long before that date.... just the announcement would coincide.
16:40:07 <spot> abadger1999: sure. that makes sense.
16:40:53 <mmcgrath> Ok, so does anyone have anything else on the deployment thing?  It seems we all agree communication could be better and I don't think anyone is against a better documented Fedora-Infrastructure -> Fedora (OS) lifecycle
16:41:23 <mmcgrath> Ok,
16:41:28 <mmcgrath> the next bit is the licensing.
16:41:41 <mmcgrath> which has come under more light over the last couple of meetings.
16:41:56 <mmcgrath> in particular things like hot patching concern me as an operations guy.
16:42:11 <mmcgrath> I'm still learning how the agpl will affect us
16:42:33 <mmcgrath> So what happened there?  Is it too late to go back and release it under a GPL license?
16:42:42 <spot> well, we really want it under the AGPL
16:43:00 <spot> the reason we didn't use the GPL is because the GPL is not a good fit for web apps
16:43:18 <spot> we wanted to encourage people to use the FC/moksha code, but we also want to get back improvements
16:43:19 <mmcgrath> who's "we", because it's not the infrastructure team.  AGPL means a lot more process, and higher barriers to running this app then before.
16:43:52 <spot> under the GPL, someone (*cough*google*cough*canonical*cough*) could take moksha and FC, make a ton of changes, and run it
16:44:02 <spot> without any requirement that they share their fixes, or changes, or anything
16:44:08 <mmcgrath> and that's a problem for who?
16:44:17 <mmcgrath> it's just not something we wanted to allow them to do?
16:44:24 <abadger1999> spot: Did you get the email I sent you: I believe Subject: Licensing Part II ?
16:44:27 <spot> we want to be able to get those fixes
16:44:35 <spot> and encourage open development
16:44:48 <mmcgrath> spot: I have to be honest, the license in mokesha will probably prevent me from ever using it in any of my projects.
16:44:51 <abadger1999> spot: we == moksha & Fedora Community.
16:44:57 <spot> mmcgrath: why exactly?
16:45:07 <mmcgrath> it's just too much of a pain to comply with.  especially from an operations point of view.
16:45:17 <spot> mmcgrath: really? a url to fixes is too much of a pain?
16:45:18 <mmcgrath> I can't just go in and make a change.
16:45:19 <jwb> mmcgrath, maybe if you state your concerns first, it might help
16:45:33 <mmcgrath> spot: a week ago mirrormanger broke and I had a pot on the stove.
16:45:34 <abadger1999> jwb: The concerns were in the Licensing Part II email.
16:45:37 <mmcgrath> It took a couple of seconds to fix.
16:45:40 <jwb> abadger1999, ok
16:45:55 <spot> mmcgrath: to comply with the AGPL, you just need to have a link to the source that is running.
16:46:03 <mmcgrath> that couple of seconds, takes much longer when I have other stuff to do with linking to this or that and publishing, etc.
16:46:06 <spot> that could be a link to the base source control and a link to the hotfixes
16:46:19 <mmcgrath> except none of our code currently does that.
16:46:20 <abadger1999> spot: I think infra needs to know more about what compliance to the AGPL means in order to understand how costly/inexpensive it is to comply.
16:46:28 <spot> honestly, you should be tracking your hotfixes anyways
16:46:43 <jwb> spot, that is sort of orthogonal
16:46:47 <spot> no, not really
16:46:51 <mmcgrath> awhat about config files?
16:47:00 <spot> mmcgrath: config files aren't code.
16:47:12 <jwb> yes, sure.  but if they don't right now, they aren't violating a license
16:47:17 <mmcgrath> additionally if I worked at either of the last two places I worked with, they'd immediatly say no to using it.
16:47:21 <ricky> With something like mod_wsgi, code and configuration can be very mixed at times.
16:47:22 <mmcgrath> just because of that.
16:47:30 <ricky> But I think the bigger concern is exactly how we have to link to hotfixes
16:47:30 <abadger1999> spot: But they're in the tarball along with the code and the only license in the tarball is AGPLv3.
16:47:34 <J5> A lot of people say no to GPL
16:47:35 <spot> mmcgrath: because they ran proprietary web apps
16:47:38 <spot> we don't.
16:47:39 <abadger1999> So how do we differentiate.
16:47:42 <J5> because of the same reasons
16:47:49 <abadger1999> J5: Yeah, once of the infra developers does, in fact.
16:47:50 <mmcgrath> spot: they also ran open source apps, it took a long time to get them to do it.
16:48:02 <mmcgrath> now imagine if the barrier to using those apps was even higher.
16:48:09 * abadger1999 notes meeting reaches halfway point.
16:48:14 <spot> abadger1999: well, we've never been that anal about configs in any other fedora package
16:48:33 <spot> abadger1999: but we can explicitly relicense the configs if it helps people sleep at night
16:48:43 <abadger1999> spot: We've never had a license that might require us to release them.
16:48:53 <smooge> spot, config files may be code depending on how they are implemented and if the file has a "AGPL" header in it. I couldn't find an exclusion to config files in the AGPL :/
16:49:02 <mmcgrath> I'm not talking about developing code, I'm talking about very practical operations issues.
16:49:07 <spot> abadger1999: thats not true, there are plenty of licenses that could be interpreted that way
16:49:08 <J5> I personally think LGPL would make sense in some of the code in Moksha
16:49:34 <smooge> spot, I am not against the AGPL, I just want to make sure we have a process in place so that we know the following:
16:49:38 <spot> mmcgrath: the issue is this, you need to make the code that is running available.
16:49:42 <abadger1999> spot: We just need to know what the rules are for compliance.  If there's some escape hatch built into the code vs config that says configs are uncopyrightable therefore they are freely copyable/do not fall under AGPL, that's fine.
16:49:44 <spot> to the user of the web app
16:49:48 <mmcgrath> spot: and alter the webapp to point at it.
16:50:06 <spot> well, the webapp can point to a directory or a git tree or a url where source can be found
16:50:07 <smooge> a) How do we run in staging. Who are the 'customers' we need to publish the code for. {If some joe comes across it do we have to show them the exact code at that moment?}
16:50:12 <ricky> One thing we were concerned about is how we need to link to hotfixes.
16:50:15 <spot> it doesn't have to be an explicit link
16:50:22 <spot> you just have to be able to get it from there
16:50:32 <abadger1999> spot: Are you talking Fedora or Fedora Infra?
16:50:44 * spot sighs
16:50:46 <ricky> OK, and what about what smooge said?  Does this entire process need to be followed for our staging environment too just because it's web accessible?
16:50:49 <spot> this is a royal pain to do over irc.
16:50:50 <mmcgrath> but git trees and directories don't come out of thin air.  We have to put them somewhere, we have to back them up
16:50:53 <mmcgrath> etc, etc.
16:51:00 <mmcgrath> spot: imagine being legally liable for it.
16:51:02 <J5> ricky: why wouldn't a hotfix go into version control and the app be packaged first?
16:51:06 <spot> mmcgrath: guess what, i am. ;)
16:51:11 <smooge> spot I agree. I will send my problems via email and we can work out a process there.
16:51:18 <spot> no, lets try this again.
16:51:23 <spot> the webapp
16:51:31 <spot> has to have a link to the source of the code it is running
16:51:37 <spot> thats it.
16:51:53 <jwb> and if someone hotfixes a python bit that's live?
16:51:55 <mmcgrath> and the benefit to us is now canonical and google won't use mokesha?
16:51:59 <spot> that link can go to a page that says "here is the base git" and "here is a directory that contains any hotfixes we have applied"
16:52:10 <J5> mmcgrath: launchpad was just AGPL'ed
16:52:13 <ricky> J5: In staging, it probably should, but we use staging for debugging as well.  One thing I did recently was write some debugging middleware for FAS in staging and leave that running for a few days
16:52:27 * mmcgrath writes down another reason not to use launchpad.
16:52:42 <nixdude> lol
16:52:47 <mmcgrath> I really don't like the AGPL and here's why.  It protects the developer at the cost of the user.
16:52:56 <spot> honestly, i'm starting to get a little pissed off at the AGPL hate here.
16:53:08 <spot> you should be tracking your damn hotfixes anyway
16:53:17 <abadger1999> spot: People don't understand the AGPL.
16:53:18 <spot> and if you're doing that, its trivial to put up a link to them
16:53:25 <mmcgrath> spot: but having to do so in public is a higher burden then you think it to be.
16:53:38 <mmcgrath> from your point of view we don't get it
16:53:39 <spot> mmcgrath: if you're doing it right, you have nothing to fear.
16:53:41 <mmcgrath> from our point of view you don't get it.
16:53:44 <J5> mmcgrath: actually it protects users at the cost of the developers - you said it yourself, you are afraid of what it will cost us to do hotfixes but it allows users to not be locked in
16:53:48 <spot> if you're doing it wrong, you have more to fear than AGPL clauses
16:53:57 <abadger1999> Without understanding, people don't know what they can implement to comply and how much time that will take; what changes will be needed.
16:54:09 <abadger1999> https://www.redhat.com/archives/fedora-infrastructure-list/2009-July/msg00094.html
16:54:20 <spot> abadger1999: you can implement it pretty much any way you want as long as the user can get the source that is running
16:54:23 <ricky> https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7Ehotfix&order=priority
16:54:25 <smooge> well ok lets try a different tack. what we need to do to properly track changes:
16:54:35 <mmcgrath> spot: you mean as long as the developer can get the source that is running right?
16:54:42 <spot> mmcgrath: no, the user of the webapp
16:54:50 <spot> any user of the webapp
16:55:05 <abadger1999> That's the summary of questions people asked at  the last infra meeting about AGPL.
16:55:11 <mmcgrath> spot: and if the webapp doesn't have some way to do that we have to constantly patch the app to do it?
16:55:15 <spot> thats why FC has a link at the bottom of the page
16:55:36 * abadger1999 notes we are down to 7 minutes.
16:55:50 <mmcgrath> spot: but none of that links to where we track bugs
16:55:52 <spot> mmcgrath: then fix the webapp so it doesn't.
16:56:04 * mmcgrath doesn't think s/AGPL/GPL/ is legal though :)
16:56:06 <lmacken> Hey guys, sorry I'm late :)
16:56:08 <spot> mmcgrath: if you say "we put hotfixes for FC and moksha <here>", we'll link to it.
16:56:16 <spot> and we're compliant
16:56:17 * lmacken wsa thinking it was at 13:00
16:56:27 <mmcgrath> spot: and from your poitn of view, as someone that doesn't actually have to do that work, it seems trivial doesn't it?
16:56:29 <abadger1999> spot: I was wondering if that covers us or not -- it doesn't link to the version of code that we're running.... even with hotfixes.
16:56:48 <abadger1999> But once again, that was once of the questions in the email.
16:56:48 <ricky> lmacken: Hey, I have a bodhi question for you after this meeting if you'll be around
16:56:51 <spot> abadger1999: legal says it does cover us because the code we're running is there.
16:56:54 <mmcgrath> so what, we just copy the file into puppet, alter it, and hope upstream doesn't change it?
16:56:57 <abadger1999> spot: But it's not.
16:57:01 <lmacken> ricky: ok
16:57:18 <spot> abadger1999: how is it not there? we're linking to git
16:57:30 <abadger1999> spot: There's code i nthe moksha/fedoracommunity repo -- but it's not necessarily what we're running.
16:57:54 <spot> abadger1999: the code that we're running is in git.
16:58:13 <spot> unless one of you applied hotfixes without telling lmacken or J5
16:58:14 <J5> abadger1999: you can get to the revision
16:58:23 <ricky> what if mmcgrath finds a security bug in fcomm and doesn't have commit access?
16:58:24 <spot> or without checking it into git
16:58:29 <abadger1999> spot: Where?  What revision?
16:58:40 <abadger1999> What tag/branch/etc
16:58:51 <spot> abadger1999: i'm pretty sure "HEAD" is the answer
16:58:57 <ricky> I can see this being painful when it happens that we aren't upstream, or that we're not directly involved in development
16:59:04 <spot> abadger1999: and even if it wasn't, legal said it was sufficient to point to git
16:59:19 <abadger1999> spot: So even though we aren't running HEAD, it's sufficient to point to HEAD?
16:59:29 * mmcgrath notes 1 minut left
16:59:33 <spot> abadger1999: as long as the code we're running is actually in git
16:59:46 <jwb> they are telling you it's not
16:59:49 <spot> now, if you guys have a directory or a git repo or something
16:59:53 <spot> where you store hotfixes
16:59:55 <abadger1999> spot: k.  So we don't need to point to our hotfixes either as long as they've been checked into some branch in git at some point?
16:59:59 <spot> we can link to that too
17:00:04 <spot> and we're compliant
17:00:04 <abadger1999> Even if they've later been reverted, etc?
17:00:08 <spot> yeah, sure.
17:00:14 <abadger1999> Excellent.
17:00:15 <mmcgrath> ugh
17:00:25 <mmcgrath> what a pita
17:00:33 <ricky> So what do we do for cases where we don't have commit access like the one I mentioned above?
17:00:40 <spot> you're making a mountain out of a molehill here.
17:00:42 <mmcgrath> Ok, we're at the stop point guys, sorry.  We said hard stop so we're going to hard stop.
17:00:50 <mmcgrath> spot: you don't have to live with the consequences of this decision.
17:00:53 * mmcgrath does
17:00:57 <abadger1999> spot: System admins have to understand the worse case scenarios.
17:01:06 <mmcgrath> #stopmeeting
17:01:12 <mmcgrath> #meetingstop
17:01:14 <mmcgrath> it's one of those
17:01:19 <ricky> #endmeeting
17:01:22 <nirik> (endmeeting)
17:01:24 <ricky> (But you have to do it)
17:01:25 <mmcgrath> #endmeeting