20:00:11 <mmcgrath> #startmeeting
20:00:12 <ricky> (switch it)
20:00:49 <mmcgrath> #topic Who's here?
20:00:51 * ricky 
20:01:00 * nirik is here in the cheap seats in the back.
20:01:04 * sijis is here.
20:01:11 * dgilmore is here
20:01:18 * nb 
20:01:37 * dgilmore pulls nirik out of teh cheap seats
20:01:37 <mmcgrath> K, lets get started with the tickets
20:01:42 <mmcgrath> #topic Infrastructure -- Tickets
20:02:24 <mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority
20:02:30 <mmcgrath> Ok, so the only one there is on abadger1999
20:02:33 <mmcgrath> .ticket 1503
20:02:35 <mmcgrath> abadger1999: around?
20:02:41 <smooge> meeting
20:02:44 <smooge> here
20:02:44 <abadger1999> Yep.
20:02:46 * f13 
20:03:02 <davivercillo> **davivercillo is here
20:03:14 <abadger1999> phew.  So I've been busy and haven't done on anything again.  I'll take this off the meeting for now.
20:03:25 <abadger1999> I'll go ahead with relicensing python-fedora first.
20:03:34 <abadger1999> Then I think we'll do FAS or pkgdb.
20:04:18 * ianweller is here
20:04:23 <mmcgrath> abadger1999: ok
20:04:28 <smooge> abadger1999, do we have a list of apps we write?
20:04:34 <abadger1999> After we see that it seems prettystraightforward to do that we can go ahead with everything else.
20:04:52 <abadger1999> smooge: Unfortunately no -- I go off of memory/what's in puppet/what's running on the app servers.
20:05:03 <smooge> abadger1999, and do you have an idea on how we will publish local changes to meet AGPL needs.
20:05:10 <jeff_hann> hello all
20:05:11 <ricky> You can get a decent list in appRhel.pp
20:05:15 <ricky> But not totally complete either.
20:05:32 <davivercillo> Hi everybody, I'm new here ! I'm from Brazil and I would like to help you with something... try at lest...
20:05:33 <abadger1999> smooge: That's a good point.  So I made several proposals in the wiki page.
20:05:34 <smooge> ricky, ok thanks..
20:05:40 * johe here, late but here
20:05:41 <abadger1999> davivercillo: Welcome!
20:05:51 <davivercillo> abadger1999: thanks ! =D
20:05:52 <ricky> jeff_hann, davivercillo: Hey, welcome!
20:05:59 <abadger1999> smooge: We can do several things...
20:06:20 <heffer> i'm here too :)
20:06:25 <abadger1999> 1) Not hotfix.  Everything has to be released as a tarball which we can link to.
20:06:32 <abadger1999> Pro: simple.  Con: limiting
20:06:53 <f13> 'released as a tarball'?
20:07:04 <abadger1999> 2) thanks to our new policy, hotfixes have tickets.
20:07:39 <abadger1999> f13: Well.... I suppose we can point people to a revision/branch in revision control... But it needs to be the source that we're running on the server.
20:07:46 <abadger1999> f13: So it can't be HEAD.
20:07:51 <dgilmore> f13: released as a tarball that can be packaged
20:07:59 <abadger1999> f13: It would have to be a branch dedicated to mirror produciton.
20:08:37 <f13> sorry I think I'm not quite following the discussion
20:08:47 <abadger1999> So baack to #2 -- If we have a patch to the hotfixes in the tickets we can probably link to tarball + list of tickets.
20:08:48 <f13> I thought the no hotfix policy meant that fixes have to be in rpm form in the repo
20:08:50 <f13> or in puppet
20:08:59 <f13> but not just modified directly on the box in question
20:09:10 <abadger1999> f13: This is a different policy.... licensing Guideline.
20:09:11 <dgilmore> f13: they should be yes
20:09:20 <abadger1999> f13: We're going to try to switch to the AGPLv3.
20:09:30 <f13> ah right, nuance there
20:09:34 <abadger1999> f13: (In part because moksha/ fedora community is)
20:10:01 <abadger1999> f13: So we have to figure out how to provide the code that we're running on the servers to people at all times.
20:10:35 <abadger1999> smooge: Other options that aren't so painful?
20:10:59 <f13> imho we are either running rpm code, or running signed tagged checkouts
20:11:13 <smooge> I am wondering if a git archive meets the AGPL need.
20:11:15 <f13> and thus we can either point to the srpm, or to the source repo we're running a checkout from
20:11:17 <dgilmore> i think we should always use rpms
20:11:41 <abadger1999> f13: Early on in infrastructure I proposed that we use checkouts from revision control.
20:11:44 <f13> releasing tarballs is a bit of a hassle and redundant in today's scm days
20:11:45 <dgilmore> then they are always available via the infra repo
20:11:55 <smooge> I would prefer if we used RPMS so we can do the worlds easiest tripwire (rpm -V)
20:12:00 <abadger1999> I stil think that's nice... but I don't think mixing rpms and checkouts for a single app is good.
20:12:11 <f13> if we go with scm checkouts, the process to get it checked out and deployed has to be in puppet
20:12:16 * ricky agrees with what abadger1999 says
20:12:19 <abadger1999> We'd either want rpms always (with hotfixes) or checkouts always for any given app.
20:12:20 <f13> so using a tag is somewhat necessary
20:12:26 * nirik wonders also if there couldn't be a wiki page or something noting why something is in infrastructure and not just EPEL. ;)
20:12:28 <smooge> f13 I would like it to be the following:
20:12:34 <ricky> Luke always manages to get hotfixes into RPMs - maybe we can aim for the same?
20:12:50 <dgilmore> abadger1999: does the direct link to the source need to be on each web page
20:12:56 <abadger1999> heh, last time he complained about it though ;-)
20:13:06 <abadger1999> spot: ping
20:13:12 <f13> he's at LS
20:13:15 <f13> in canadia
20:13:18 <abadger1999> Yeah...
20:13:22 <smooge> git pull, make changes, git commit, git whatevermakes branches, git push; make rpm; make push-to-repo; puppet do your thing
20:13:34 <abadger1999> I hear they have internet there ;-)
20:13:42 <f13> don't even have to do that
20:13:43 <mdomsch> abadger1999, barely generally...
20:13:52 <f13> git pull/ chnage/ commit/ tag push ; push --tags
20:14:07 <f13> puppet config would always be pulling from a given tag in the repo
20:14:11 <abadger1999> mmcgrath: care to go over why you'd rather have rpms than checkouts again?
20:14:22 * mmcgrath might be missing something too
20:14:54 <mdomsch> abadger1999, for the same reason we don't install everything into /usr/local?
20:14:58 <mmcgrath> abadger1999: you're talking about packages right?
20:15:00 <mmcgrath> like fas?
20:15:10 <abadger1999> mmcgrath: correct
20:15:35 <abadger1999> mdomsch: But -- we'd be able to track what's installed because the code is in the scm.  either HEAD of a specific branch or a tag.
20:15:53 <ricky> rpm -V, package dependencies and puppet's facilties for managing packages are nice
20:15:55 <abadger1999> using puppet to pull it will give us repeatablity.
20:15:55 <dgilmore> f13: id like to know why you think pulling from scm is better?
20:15:57 <f13> HEAD is bad
20:15:57 <skvidal> abadger1999: so now we have 2 pkging systems?
20:15:59 <mmcgrath> abadger1999: IIRC it's part of our freesoftware policy.  And for the same functionality and ease of updates as why Fedora doesn't ship tarballs.
20:16:03 <ricky> It's also pretty consistent between apps
20:16:05 <ricky> That's why I like RPMs
20:16:15 <abadger1999> skvidal: That's one strike against it, sure.
20:16:21 <skvidal> abadger1999: it's a big strike, imo
20:16:25 <f13> dgilmore: during development of an app, its moving quite a lot faster than what we can push through creating tarball, building rpm, stuffing tha trpm into a repo somewhere, and then updating the host
20:16:27 <mmcgrath> abadger1999: what benefit do we get?
20:16:44 <abadger1999> dgilmore: I'm not sure if we need a direct link on every page.  Fedora community I believe links to the fedorahosted web page which links to the source repo.
20:17:05 <f13> it's far easier and smoother to cherry pick a hot fix into the "live" tag, and push that change set, letting the server pick up the live tag at the next puppet run
20:17:27 <skvidal> f13: not sure it is easier for anyone else looking to replicate what we do
20:17:28 <f13> once things get more stable, I definitely agree that rpms are the way to go
20:17:35 <dgilmore> abadger1999: ok, just curious as to how we meet the requirement thatthe live code is available
20:17:37 <abadger1999> mmcgrath: It's nice from a developer's standpoint.  Gets the most benefits when it's an app that runs at a single location.
20:17:39 <skvidal> f13: nor does it provide the unity of system
20:17:50 <f13> skvidal: correct, it is not a perfect solution.  There are none
20:17:51 <smooge> could we ship them as conaries?
20:18:08 <skvidal> I think we'd end up making our very own 'stow' type of system
20:18:25 <mmcgrath> abadger1999: you can do that in the test environment if you want :)  but not in production
20:18:30 <skvidal> which is just implementing another package system
20:18:30 <dgilmore> f13: i have to say its maybe easier from a developer standpoint but not from a sysadmin perspective
20:18:40 <abadger1999> mmcgrath: Allows the developer to not have to deal with making a release (update versions, make tarball, make rpm, deploy) instead they can deploy using (the developer's) normal scm tool.
20:18:46 <abadger1999> Those are the benefits.
20:18:53 <f13> dgilmore: from a sysadmin perspective, does it matter much when its entirely driven by puppet?
20:18:56 <abadger1999> (as I see them).  But there's definitely cons.
20:19:02 <mmcgrath> abadger1999: but once it's in production it's not about them
20:19:04 <dgilmore> f13: i think so
20:19:17 <ricky> Even in puppet, it would add a good deal of complexity.
20:19:26 <f13> mmcgrath: so we're only talking about once in production?
20:19:36 <f13> but a test instance in development wouldn't have to play by the same rules?
20:19:36 <mmcgrath> well I'm talking a minimum of once it's in production.
20:19:43 <mmcgrath> I'd prefer it in staging.
20:19:53 <mdomsch> agpl doesn't seem to note any difference
20:19:54 <abadger1999> mmcgrath: Well... that depends... what are you going to want to do to fas or packagedb that you wouldn't toss at a developer and would benefit from an rpm?
20:19:56 <mmcgrath> on the publictest servers I don't have a preference since so much actual development goes on there.
20:20:12 <mmcgrath> abadger1999: I'd hope they'd be developing on their workstation, not in production is all.
20:20:23 <abadger1999> mmcgrath: If we're sticking with rpms over scm, I definitely want rpms in staging.
20:20:50 <dgilmore> abadger1999: right do same thing across the board
20:20:52 <mmcgrath> just so I'm clear who's advocating the tarball method, who's advocating rpms and who has no preference?
20:21:05 <mmcgrath> +1 rpm
20:21:07 * ricky likes RPMs in staging/production
20:21:07 <mdomsch> public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version
20:21:15 <ianweller> +0
20:21:18 <dgilmore> mmcgrath: i think tarballs should lead to rpms and we should use rpms
20:21:21 <f13> I'm advocating checkouts from a specific tag in scm at least during the time where changes are rapid.
20:21:23 <mdomsch> quoth agpl
20:21:42 <skvidal> +1 rpm
20:21:54 <f13> whether that time is restricted to pre-staging or not, I don't really care
20:21:55 <smooge> mdomsch, what difference
20:21:56 <ricky> I think the argument here is that changes should be rapid in testing/development, not in staging/prod
20:21:56 * mdomsch uses staging as a test platform
20:22:09 <mdomsch> rpm + patches from scm
20:22:16 <ricky> Currently, people are free to go from SCM on publictest machines though
20:22:25 <mmcgrath> ricky: and typically do
20:22:32 <smooge> mdomsch, nm.. figured it out
20:22:34 * ianweller certainly does :)
20:22:34 <skvidal> mdomsch: what does '+patches' mean?
20:22:45 <skvidal> mdomsch: do you mean patching the fs itself - or do you mean %patches?
20:23:03 <mdomsch> skvidal, most often, git-format-patch HEAD^; scp 0001-foobar.patch app1.stg
20:23:09 <skvidal> mdomsch: nod
20:23:10 <abadger1999> No preference -- as long as we do it across the board.
20:23:27 <f13> so, lets propose that once an app goes to staging, all modifications to the app must happen through rpms
20:23:28 <mdomsch> test; fix; repeat; cut version
20:23:33 <ianweller> if we go RPMs are we going to require that on pt servers
20:23:37 <smooge> ok stupid question time.. do changes to configuration files count as patches that need to be publci.
20:23:40 <f13> since one can easily generate a rpm with patches from git
20:23:46 <f13> before one does the actual full release
20:23:50 <mmcgrath> f13: I'd make an exception for emergency patches that require a ticket.
20:23:50 <skvidal> smooge: I don't think so
20:24:10 <f13> mmcgrath: why make an exception?  It takes only a few minutes to generate a patched rpm
20:24:11 * abadger1999 agrees with mdomsch's use of staging
20:24:20 <smooge> skvidal, I just want to get that dealt with before the "Red Hat breaks the AGPL by not publishing their passwords" slashdot fest
20:24:26 <mdomsch> I don't want to have to respin the RPM just to test a fix on staging
20:24:27 <skvidal> :)
20:24:37 <ricky> mmcgrath: What is the policy on testing hotfixes on staging?
20:24:39 <f13> mdomsch: apparently it isn't about your wants though.
20:24:48 <ricky> mmcgrath: Like when we were doing FAS testing there, I ran it off of a patched wsgi file somtimes.
20:24:54 <abadger1999> smooge: I agree with skvidal.  configs are managed via puppet
20:25:04 <f13> mdomsch: if we go strict to just rpms in production, it seems that we want the same thing in staging
20:25:06 <mmcgrath> it's been my experience that in our environment, requireing a full rebuild of an rpm is a pretty high cost.
20:25:12 <mmcgrath> not everyone has access to the signing key for one thing.
20:25:16 <mdomsch> f13, fair enough; but I do want a place to test things before production.  Staging has been that so far.  if staging isn't going to be that, fine; but something else needs to be.
20:25:16 <smooge> mdomsch, mmcgrath are we using staging for devepment or for integration.. or both
20:25:28 <mmcgrath> next you'll have to make sure that the next release of the rpm (whatever it is) is at least higher then what yours is.
20:25:51 <mmcgrath> smooge: a little of both.  It's really supposed to be for integration/staging.
20:25:56 <ricky> staging has been mostly for staging deployments and debugging issues (like FAS 500s) in an environment with close-to-prod data
20:25:58 <abadger1999> mdomsch: +1
20:26:00 <mmcgrath> but we don't have a fully functional development environment.
20:26:09 <smooge> so we need some .devel. boxes for everything?
20:26:11 <f13> mdomsch: isn't that what publictest instances are for?
20:26:23 <abadger1999> The policy on staging has been -- okay to break it for a short period... but by the time it is deployed it has to be right.
20:26:23 <mmcgrath> f13: we don't have enough pt boxes though
20:26:26 <f13> ah.
20:26:29 <mmcgrath> many of them are being used for proof of concepts and things.
20:26:33 <ricky> smooge: devel mostly happens on pt machines or home machines right now
20:26:50 <abadger1999> So rpm + patch hotfix in staging seems to fit that idea -- but it becomes an rpm by the time it goes to production.
20:26:54 * smooge starts to look up .pt. boxes to figure out how many are needed
20:26:55 <mmcgrath> this is one of those instances where we see the flaws in our process, but fixing the process isn't that feasible at the moment because of man hours and hosting space
20:27:13 <mmcgrath> in theory, for a full environment, we'd need
20:27:15 <mmcgrath> 1 db server
20:27:17 <mmcgrath> 2 app servers
20:27:19 <mmcgrath> 1 proxy server
20:27:22 <mmcgrath> 1 bapp server
20:27:24 <mmcgrath> 1 releng box
20:27:26 <mmcgrath> 1 koji box
20:27:28 <mmcgrath> 1 cvs host
20:27:29 <mdomsch> abadger1999, right.  code running in staging doesn't have to be published in a downloadable fashion per agpl as it's not public.
20:27:41 <mmcgrath> so that's a minimum 8 per environment.
20:27:47 <f13> mdomsch: that's a very strange interpretation of "public"
20:27:51 <mmcgrath> so if we do a full staging and devel environment that's 16 new boxes
20:27:53 <mmcgrath> err new hosts.
20:27:59 <f13> mdomsch: I wonder if they assume "staging" isn't on the internet
20:28:01 <f13> where ours is
20:28:21 <mdomsch> "It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. "
20:28:25 <f13> so if we're going to allow rpms + patches with tickets in production, then rpms + patches (without tickets) should be OK in staging
20:28:27 <mdomsch> the only "users" of the staging server is us
20:28:44 <mmcgrath> abadger1999: are we discussing this for legal obligations or just to get our policy figured out?
20:28:48 <f13> mdomsch: except that the staging servers are accessable by the entire world.
20:28:49 <jwb> i missed something.  how did agpl get involved here?
20:28:59 <mdomsch> therefore: rpms only in production; rpms + patches in staging.
20:28:59 <thekad> mmcgrath, can we compress a little? i.e. using a db server for both dev and stg? or is it needed for stg to be on its own? maybe we need less machines
20:29:02 <f13> jwb: we're talking about re-licensing all of Fedora web apps as agpl
20:29:10 <mdomsch> f13, they are?
20:29:12 <mmcgrath> thekad: not reliably
20:29:14 <f13> jwb: and if we do, there are things we have to consider
20:29:26 <jwb> ok....
20:29:27 <f13> mdomsch: Hrm, I was under the impression that they were.
20:29:30 <ricky> technmeg: We usually don't want real data on development
20:29:36 <jwb> why agpl?
20:29:39 <mmcgrath> abadger1999: if this time next year no one is using fedoracommunity, can we get rid of it and go back to GPL?
20:29:41 <abadger1999> thekad: staging is supposed to be more secure than devel.  So separate db servers.
20:29:42 <mmcgrath> :)
20:29:46 <f13> jwb: moksha alreasy is agpl
20:29:49 <thekad> abadger1999, gotcha
20:29:57 <mdomsch> mmcgrath, app1.stg isn't reachable outside FI, right?
20:29:59 <abadger1999> jwb: Largely because moksha/community switched to it.
20:30:05 <mmcgrath> mdomsch: correct
20:30:10 <ricky> mdomsch: It isn't, but the staging proxy server is
20:30:13 <abadger1999> jwb: Here's some additional justification: https://fedoraproject.org/wiki/Infrastructure_Licensing
20:30:16 <ricky> So it's similar to the prod setup
20:30:16 <f13> mdomsch: I stand corrected
20:31:02 <mmcgrath> lets take a step back and look at the hot fix we did for mirrormanager last week.
20:31:07 <f13> Proposal: Production env is ran by rpms, plus hotfixes with associated tickets with code available.  staging is ran from rpms and code patches.
20:31:08 <mmcgrath> Pretend mirrormanager was AGPL.
20:31:29 <mmcgrath> abadger1999: would we have not been able to do what we did?
20:31:39 <smooge> f13, lets table that for mmcgrath's stuff then we will discuss proposal
20:31:44 <abadger1999> mmcgrath: Where's the ticket for that?
20:32:01 <jwb> abadger1999, thanks
20:32:01 <abadger1999> Let's look at it and see what we might need to do differently.
20:32:02 <mmcgrath> .ticket 1524
20:32:40 <abadger1999> So mirrormanager --- we have a base of an rpm that's available from the repo on http://infrastructure.fedoraproject.org/
20:32:55 <mdomsch> include srpm
20:32:58 <abadger1999> We don't have a patch in the ticket...
20:33:06 <f13> I think might have had to generate a patch file that does the revert, and attached the patch file to the ticket
20:33:09 <mdomsch> abadger1999, you have a pointer to the patch
20:33:16 <f13> (and then have something on MM that points to the ticket queue to look for changes)
20:33:27 <abadger1999> Right.  Partial instructions on how to generate a patch
20:33:31 <f13> you have a pointer to the patch that was reversed.
20:33:42 <abadger1999> <nod>
20:33:59 <f13> now, I don't think anybody would sue us over the minor nit pick
20:34:18 <mmcgrath> abadger1999: ok, now take this same scenario
20:34:20 <mdomsch> especially as the patch is public
20:34:28 <mmcgrath> and lets say that it wasn't a revert.  But I had to add a line of code.
20:34:39 <f13> mmcgrath: you'd generate a patch file, attach it to the ticket
20:34:47 <ricky> Attaching the patch sounds reasonable to me.
20:34:52 <mmcgrath> and that alone, would make me legally compliant?
20:34:56 <f13> (or reference the commit upstream)
20:34:57 <mdomsch> or commit the patch to MM upstream, with a pointer to the commit
20:35:08 <f13> mmcgrath: provided that the mirrormanager site has some link to the ticket queue
20:35:14 <mmcgrath> mdomsch: it dawns on me that I actually have commit access in MM and should have done that ;-)
20:35:25 <abadger1999> mmcgrath: I'd say that we need a patch, rather than just hte line of code pasted in the ticket.
20:35:33 <abadger1999> (as the patch tells where in the code to apply it).
20:36:21 <f13> (side note, using git am would be perfect here, as it also contains info about the author, and has the commit message)
20:36:27 <abadger1999> We'd also need to point people at the patch.
20:36:33 <abadger1999> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&keywords=%7EHOTFIX&order=priority
20:36:37 <f13> an dhas the shasum of the patch which won't change when applied upstream
20:36:44 <abadger1999> I thought that would do us... but it's not quite enough :-(
20:36:54 <abadger1999> We need two keywords per hotfix.
20:37:01 <abadger1999> Hotfix Appname
20:37:03 <mmcgrath> So the one bit there that's confusing to me is that mirrormanager would have to link to my hosted ticket some how?
20:37:28 <f13> mmcgrath: right.  MirrorManager would have to have a link to wherever the patch is posted.
20:37:36 <mmcgrath> holy fuck do I hate AGPL
20:37:44 <ricky> :-(
20:37:49 <f13> be it the infra ticket queue, the MM ticket queue, or the MM upstream repo
20:37:49 <abadger1999> That way mirrormanager can say infrastructure.fedoraproject.org rpm/srpm + URL that finds just mirrormanager hotfixes.
20:37:50 <davivercillo> :P
20:37:59 <jwb> mmcgrath, heh.  and i thought i was the only one
20:38:09 <f13> mmcgrath: hate or not, it's actually making us be much better about our patch management.
20:38:13 <abadger1999> mmcgrath: well, we haven't relicensed anything yet -- now's the time to holler if it's not going to fly.
20:38:38 <f13> the infrastructure ticket could have been moved to MM"s trac instead
20:38:40 <mmcgrath> how will the actual implementation of this "linking to bug fixing" work?
20:38:52 <ricky> f13: That makes them harder for us to track though :-(
20:39:03 <abadger1999> mdomsch: Re: or commit the patch to MM upstream, with a pointer to the commit
20:39:07 <mdomsch> MM is the upstream project.  It doesn't need a link to all the downstream implementations thereof.
20:39:07 <abadger1999> mdomsch: I don't think that's enough.
20:39:13 <thekad> f13, having moved to MM's trac and referencing that trac on f-i's trac would work?
20:39:15 <f13> ricky: rather, a ticket with the patch could have been filed at MM site.
20:39:18 <ricky> A central web area where we store current patches to our apps?
20:39:20 <mmcgrath> is that a legal question?
20:39:24 <abadger1999> mdomsch: Unless there's a branch dedicated to what we deploy.
20:39:25 <mmcgrath> mine I mean.
20:39:38 <mdomsch> The downstream implementations need a link to the code they're running: that can be "pointer to upstream version" plus patches
20:39:39 <abadger1999> mdomsch: ie, a patch against HEAD might not apply to what we have in production.
20:40:00 <f13> mmcgrath: probably a legal question
20:40:07 <mdomsch> abadger1999, rpmfusion uses MM now too.  I'd need a separate branch for them too?
20:40:08 <mmcgrath> Ok
20:40:13 <mdomsch> repeat for other folks wanting to run MM
20:40:16 <mmcgrath> so I think here's what we generally agree on.
20:40:20 <mdomsch> and then give those downstream users commit rights on my repo?
20:40:23 <mdomsch> uh, no thanks.
20:40:25 <f13> mmcgrath: I'm looking at the Community site right now, and they just have a footer that points to the hosted site for both Fedora COmmunity and Moksha
20:40:28 <f13> no other details.
20:40:41 <f13> mdomsch: why would they have commit access?
20:40:48 <f13> mdomsch: they can post patches in tickets just like everybody else
20:40:56 <f13> you can choose to apply them if you want.
20:41:02 <f13> but that's not a matter for us
20:41:06 <f13> lets forget that MM is done by one of us
20:41:07 <mdomsch> f13, for abadger's suggested "FI deployment branch"
20:41:10 <mmcgrath> so I think we agree, you make a change.  Put the patch in fedora-infrastructure trac right?
20:41:12 <abadger1999> mdomsch: Yep.  So I don't think the "pointer to scm commit" is going to work well.
20:41:25 <mdomsch> mmcgrath, I agree.
20:41:32 <f13> In /our/ deployment of MM, we need to account for not only the upstream source we use, but also the modifications /we/ make
20:41:41 <mdomsch> abadger1999, it _can_ work for apps we own; but none other.
20:41:44 <abadger1999> f13: Note that I talked to spot and specifically brought up this point.
20:41:46 <mmcgrath> Should we ask legal about the "linking app back to bug tracking" bit?
20:41:51 <ricky> OK, that sounds fine to me, but it's hard to collect them in a central place to link off of the web app pag.
20:41:54 <ricky> **page
20:41:55 <f13> so putting a footer in our deployment of MM that points to not just the upstream source, we can point to say our infra repo where hotfix patches go
20:42:03 <mdomsch> f13, right
20:42:06 <abadger1999> f13: So it's possible that community is out of compliance -- or is in compliance as long as we don't hotfix it.  Or...
20:42:08 <ricky> It wouldn't be too hard to setup a directory containing all currently applied live patches
20:42:14 <mmcgrath> abadger1999: did spot say that was a hard requirement?
20:42:17 <smooge> ricky, we send them to a src.rpm file?
20:42:29 <mmcgrath> Does oracle ship any products similar but with a less confusing license?
20:42:30 <f13> abadger1999: nod.  I think it depends on how 'exact' we have to be in offering the source
20:42:40 <ricky> smooge: Well, I'm just talking about live patches here, not package changes
20:42:44 <mdomsch> corresponding == exact
20:43:04 <f13> then Fedora Community will be out of compliance the moment we apply a patch
20:43:15 <f13> since their pages only point you to fedorahosted, not even the git repo
20:43:23 <f13> you have to go somewhere else once you get to fedora hosted to get to the source code
20:43:28 <abadger1999> f13: Yeah -- I'm a bit worried about that actually.
20:43:42 <ricky> OK, so are we basically waiting on legal advice about the linking requirements at this point?
20:43:44 <f13> well the page tells you how to get it
20:43:45 <dgilmore> f13: my understanding is that it needs to point at what is live.  so i could setup the service exactly as it is in our infra
20:43:48 <abadger1999> f13: Since even git repo != what we have deployed without additional instructions
20:43:58 <ricky> Because otherwise, it doesn't seem to be moving forward all that much
20:44:24 <jwb> make a pi icon that you can click and it just starts spewing the live source
20:44:33 <abadger1999> Can we eliminate some things?
20:44:37 <f13> IMHO it should be enough to point to A) upstream source, B) any changes we make to it.
20:44:38 <jwb> like the agpl?
20:44:50 <jwb> sorry, i should shut up
20:44:56 <f13> A) can be the upstream source repo, B) can be a ticket query that shows any active hotfixes
20:44:56 <abadger1999> jwb: No that's valid.
20:45:04 <mmcgrath> abadger1999: and you talked to spot specifically about having our applications point directly to trac?
20:45:14 <jwb> abadger1999, perhaps.  but i have little vested in this
20:45:14 <f13> (and I guess hotfixes will have to remain active if they are only in our rpm and not the upstream source)
20:45:16 <abadger1999> Proposal #1 -- Don't use AGPL as license.
20:45:39 <abadger1999> mmcgrath: No -- just whether we have to provide any hotfixes that go onto our servers.
20:45:46 <f13> I really don't want to get into banning software due to it's free license
20:45:50 <abadger1999> We didn't talk about how to provide them.
20:45:56 <jwb> f13, bannign?
20:46:01 <f13> banning that is
20:46:02 <abadger1999> f13: Not quite what we're saying
20:46:05 <f13> sure it is
20:46:06 <mmcgrath> we ban software based on free licenses already :)
20:46:10 <abadger1999> f13: This is about how we license our stuff.
20:46:19 <f13> define "our stuff"
20:46:20 <abadger1999> f13: Not about third-party stuff.
20:46:26 <mmcgrath> "Don't use AGPL as license" meaning FAS, mirrormanager, etc.
20:46:26 <f13> is Fedora Community "our stuff" or third party?
20:46:29 <ricky> Proposal #2: Central directory containing all patches linked directly on website footers as well as source?
20:46:31 <abadger1999> If we write it
20:46:35 <f13> define "we"
20:46:36 <ricky> (That's if the trac ticket thing doesn't fly)
20:46:37 <abadger1999> f13: That's actually a problem
20:46:52 <mmcgrath> f13: he's saying "don't apply AGPL to our software"  not "don't use software that is under AGPL"
20:46:53 <jwb> my point is, looking at the number of questions and hurdles the AGPL would force on you, why in the name of all things Fedora would you want to use that when it causes so much hassle to just get a damn _fix_ onto your services?
20:46:56 <dgilmore> f13: things written with fedoraproject use intended
20:46:58 <abadger1999> Fedora Community acts like a third party but wants in-house treatment.
20:47:11 <abadger1999> We have to shift that one way or another.
20:47:26 <ricky> Agreed
20:47:28 <f13> jwb: because the AGPL actually ensures that the source code for the web service you're using is actually available
20:47:48 <f13> unlike other licenses where you can patch it to hell and back and never be required to provide your changes
20:47:53 * mmcgrath is actually fine with people making changes to fas and not making that code available as long as they're not distributing it
20:48:02 <dgilmore> abadger1999: right i view it as third party due to the way that things have been done
20:48:04 <jwb> f13, i don't think that is really causing Fedora any pain
20:48:05 <f13> mmcgrath: define "distribution"
20:48:11 <jwb> whereas using AGPL seems to...
20:48:12 <abadger1999> jwb: What f13 said and that Community is using it -- which means that sharing code with community is harder.
20:48:14 <thekad> mmcgrath, +1
20:48:17 <mmcgrath> f13: don't have to, thats for legal to decide
20:48:18 <mdomsch> idea: how about a web page that lists the apps we have in deployment, with links to a) their upstream source; b) the live patch queue; for each app.
20:48:25 <mmcgrath> as well as what day of the week it is ;)
20:48:36 <f13> Lets look at koji code
20:49:02 <f13> if somebody, like say oracle, took koji code and started using it and made it available to people, but patched it to add functionality
20:49:03 * abadger1999 notes that we're at 46minutes.
20:49:15 <ricky> mmcgrath: I would be pretty disappointed if somebody added an good OpenID provider to FAS and started running it without it being free :-)  Of course, the chances of that happening are almost nine.
20:49:16 <f13> we'd want those code changes, particularly as they're a compeditor
20:49:17 <dgilmore> f13: they could
20:49:19 <ricky> **none
20:49:33 <dgilmore> f13: as koji is currently licensed
20:49:34 <f13> with the way that koji is licensed now, they can do just that, and we have no recourse
20:49:38 <thekad> yeah, nine are too many
20:49:41 <smooge> mdomsch, I think in the end we will need to get a legal idea on what is required in the sharing of the code. Do patches count? Or is it the full tree? Do config file changes count if the config file is listed as beign AGPL also.
20:49:47 <ricky> thekad: :-)
20:50:00 <dgilmore> f13: they do have to post there code for there customers
20:50:03 <f13> if it were AGPL, they'd be required to make those changes available.
20:50:09 <f13> dgilmore: not as a webapp
20:50:27 <f13> dgilmore: client code ran on the computer yes, but none of the hub code would be required to be made public to their customers
20:50:28 <abadger1999> dgilmore: They're not distributing hte web ap.. only letting people use it.
20:50:35 <mmcgrath> abadger1999: so before the cost of not moving our apps to AGPL meant sharing code was very nasty.  Now, moving our apps to AGPL means doing practical things might be illegal?
20:50:40 <dgilmore> f13: right.
20:50:57 <abadger1999> mmcgrath: Yes.
20:51:06 <f13> mmcgrath: practical very often gets in the way of opensource licensing
20:51:06 <mmcgrath> we've got some decisions to make.
20:51:08 <abadger1999> Although doing practical things has always been illegal.
20:51:11 <jwb> mmcgrath, burdensome at best.  illegal at worst
20:51:19 <abadger1999> This just hits us in a place where we haven't considered before.
20:51:32 <f13> the burden really only seems to be on A) making the site footer link to places we put source
20:51:47 <thekad> I think we should get advice from legal and be done with it, because I don't know about you guys, but IANAL
20:51:47 <abadger1999> (As an example -- we can't link a pretty common piece of javascript to any app because it's CC licensed which is not compatible with the GPL)
20:51:53 <f13> the rest of it is really just good practice (posting patches to tickets for hotfixes we make)
20:52:17 <ricky> abadger1999: Oh :-(  that's starting to get pretty annoying then.  We can currently do that with GPLv2?
20:52:36 <abadger1999> ricky: That was an example of something that's illegal now.
20:52:54 <mmcgrath> abadger1999: "now" as in the AGPL world or now as in like right this second?
20:53:08 <ricky> Oh, OK.
20:53:11 <abadger1999> But we are used to thinking about different licenses conflicting so we know to check that out no matter how nice it would be to reuse that code.
20:53:16 <abadger1999> mmcgrath: right this second
20:53:30 <abadger1999> GPL (any version) not compatible with CC (any variant)
20:53:56 <f13> abadger1999: define "link to javascript"?
20:54:04 <mmcgrath> As someone who loves and believes in free software.  I _CAN'T IMAGINE_ what some exec things if a mess like this were to be brought up to him.
20:54:12 <mmcgrath> s/things/thinks/
20:54:26 <skvidal> mmcgrath: she would think "I have hired people to do this for me"
20:54:26 <f13> abadger1999: I could have sworn recently legal said that the act of say importing one python module and using its api didn't mean it's license had to be fully compatible with your software's license.
20:55:05 <f13> but I could be on crack, so blah.
20:55:13 <smooge> ok how about this.. can we dual license?
20:55:23 <abadger1999> smooge: Nooooooo ;-)
20:55:28 <mdomsch> f13, I'd love to to get more info on that if so...
20:55:31 <mdomsch> really.
20:55:39 <abadger1999> Query -- is there anything else to announce/discuss today?
20:56:04 <mmcgrath> abadger1999: I don't think so.
20:56:04 <abadger1999> I've got nothing else but this.
20:56:09 <mmcgrath> we spent literally the whole meeting on this.
20:56:10 <ricky> Yeah, we're almost at the 1 hour mark on just this
20:56:21 <abadger1999> Okay -- we have 6 minutes -- shall we list our questions for spot?
20:56:22 <mmcgrath> which is a strong indication....  we've bitten off quite a bit here.
20:56:30 <mmcgrath> abadger1999: yeah
20:56:36 <mmcgrath> #topic Infrastructure -- Questions for legal
20:56:45 <ricky> 1) Explain the linking requirements
20:56:47 <mmcgrath> 1) Do we have to link the application to the ticket
20:57:04 <mmcgrath> 2) Is it really "absolutely critical" that fedoracommunity be AGPL
20:57:13 * mdomsch has another meeting; thanks all.
20:57:17 <ricky> mdomsch: See you later
20:57:17 <mmcgrath> mdomsch: laters
20:57:21 <f13> 3) Is linking to a list of tickets with patches to the application enough to cover "modifications"
20:57:50 <smooge> 4) Do config changes count as code changes if the config file is marked as being AGPL
20:57:52 <ricky> 4) Can we get a clarification of what the consequences would be if fcomm stays AGPL but our apps stay as they are?
20:58:00 <abadger1999> 4) which of (A) patch (B) full tree or (C) description of what line to change in which file suitable for the requirement
20:58:09 <smooge> we need one more 4
20:58:36 <jwb> btw, i'm not against AGPL as a whole.  but it seems like lots of work for little gain here
20:58:39 <davivercillo> people... I'm not feeling fine... I think that I'm getting sick, so I'm gonna home to rest a little bit... see you soon ! have a nice meeting !
20:58:50 <davivercillo> bye
20:58:50 <smooge> bye
20:58:58 <mmcgrath> jwb: I'm not either, I just want someone else to use it, not me :)
20:59:00 <ricky> davivercillo: Thanks for stopping by, sorry we didn't get a chance to discuss anything else
20:59:14 <mmcgrath> Ok, any other questions?
20:59:21 <mmcgrath> davivercillo: take it easy, see you next week.
20:59:22 <abadger1999> davivercillo: Thanks for being here -- we can talk some other day in #fedora-admin
20:59:26 <jwb> abadger1999, dual license might not be so bad
20:59:37 <abadger1999> 5) Can we link to a whole list of patches for all of our apps or does it need to be the specific patches per app?
20:59:44 <davivercillo> thanks !
20:59:44 <jwb> abadger1999, stuff in staging is $not_agpl.  stuff in production is
20:59:45 <ricky> would that double the requirements we have to hold up?
20:59:49 <f13> honestly, I think it wouldn't take much work on our part to comply with AGPL
21:00:07 <skvidal> f13: I think I agree w/you
21:00:09 <abadger1999> jwb: Is that question 6)
21:00:10 <jwb> abadger1999, actually.  scratch that
21:00:11 <ricky> I agree with f13, but there's still the question of how worth it it is for the work
21:00:12 <f13> provided legal responds well to our questions, such as just linking to tickets.
21:00:14 <abadger1999> Okay
21:00:31 <skvidal> ricky: same question could be asked of the GPL - but surely we value what we get from it
21:00:32 <f13> ricky: I think it's very little work we wouldn't/shouldn't already be doing.
21:00:33 <jwb> abadger1999, no.  because if staging is public, then people could just take the staging code before it hits production and circumvent what you'd want from AGPL
21:00:46 <mmcgrath> Ok all we're at time.
21:00:48 <f13> jwb: I was corrected, staging isn't "public"
21:00:52 <mmcgrath> anyone have anything else?  If not we'll close the meeting
21:00:54 <abadger1999> 6) Do we need to link to the source from every page of the app?
21:01:01 <jwb> f13, so hotfixes are the largest concern then?
21:01:06 <f13> jwb: yes
21:01:08 <smooge> close
21:01:09 <ricky> Staging is web-accessible, ubt we do not necessarily consider it public
21:01:11 <ricky> *8but
21:01:13 <ricky> **but
21:01:21 <ricky> So let's make that 7) Does staging count if it's web-accessible
21:01:22 <jwb> f13, hm.  my concerns are lessened but not completely
21:01:26 <f13> ricky: uh, mmcgrath earlier said it wasn't public.
21:01:38 <jwb> confused as to how it's not public
21:01:41 <ricky> https://admin.fedoraproject.org/community/
21:01:47 <ricky> That's the type of public I'm talking about
21:01:55 <abadger1999> I'll write the questions up and pass them to the list for a few hours before making sure that spot sees them.
21:02:00 <ricky> app1.stg is not publicly accessible, but the proxy server that serves the app is
21:02:21 <mmcgrath> https://admin.stg.fedoraproject.org/community/ is I think the link you want.
21:02:24 <abadger1999> jwb: We're trying to divide it on the term "users".
21:02:24 <f13> <mdomsch> mmcgrath, app1.stg isn't reachable outside FI, right?
21:02:30 <f13> <mmcgrath> mdomsch: correct
21:02:35 <mmcgrath> app1.stg isn't
21:02:36 <jwb> abadger1999, maybe that's a question for legal too
21:02:39 <mmcgrath> it's through a proxy server
21:02:39 <ricky> mmcgrath: Oops, thanks
21:02:57 <f13> er.
21:02:59 <f13> that's a symantic
21:02:59 <abadger1999> jwb: Okay.. care to phrase it for me?
21:03:04 <f13> if the world can get to the site, it's public
21:03:07 <f13> and AGPL would apply
21:03:14 <ricky> jwb: My #7 is that exact question
21:03:20 <jwb> ricky, oh, ok
21:03:28 <jwb> abadger1999, then whatever ricky said :)
21:03:29 <mmcgrath> Ok guys we're going over, anyone have anything else?
21:03:31 <f13> so it looks like staging /would/ have to account for AGPL
21:03:34 <mmcgrath> abadger1999: you have everything you need to keep you busy?
21:03:50 <abadger1999> mmcgrath: For weeks and weeks ;-)
21:03:57 <mmcgrath> f13: sorry my misunderstanding, when you said app1.stg I thought you ment the host, I wasn't thinking about the apps
21:03:59 <abadger1999> Close it up and lets continue on list
21:04:09 <mmcgrath> Ok, if no one has anything else I'll close in 10
21:04:24 <mmcgrath> #endmeeting