20:00 < mmcgrath> #startmeeting 20:00 < zodbot> Meeting started Thu Jul 16 20:00:11 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00 < ricky> (switch it) 20:00 < mmcgrath> #topic Who's here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Who's here? 20:00 * ricky 20:01 * nirik is here in the cheap seats in the back. 20:01 * sijis is here. 20:01 * dgilmore is here 20:01 * nb 20:01 * dgilmore pulls nirik out of teh cheap seats 20:01 < mmcgrath> K, lets get started with the tickets 20:01 < mmcgrath> #topic Infrastructure -- Tickets 20:01 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:01 -!- trgeier [n=tgeier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #fedora-meeting 20:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 20:02 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:02 < mmcgrath> Ok, so the only one there is on abadger1999 20:02 < mmcgrath> .ticket 1503 20:02 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503 20:02 < mmcgrath> abadger1999: around? 20:02 < smooge> meeting 20:02 < smooge> here 20:02 < abadger1999> Yep. 20:02 * f13 20:03 < davivercillo> **davivercillo is here 20:03 < 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 < abadger1999> I'll go ahead with relicensing python-fedora first. 20:03 < abadger1999> Then I think we'll do FAS or pkgdb. 20:04 * ianweller is here 20:04 < mmcgrath> abadger1999: ok 20:04 < smooge> abadger1999, do we have a list of apps we write? 20:04 < abadger1999> After we see that it seems prettystraightforward to do that we can go ahead with everything else. 20:04 < abadger1999> smooge: Unfortunately no -- I go off of memory/what's in puppet/what's running on the app servers. 20:05 < smooge> abadger1999, and do you have an idea on how we will publish local changes to meet AGPL needs. 20:05 < jeff_hann> hello all 20:05 < ricky> You can get a decent list in appRhel.pp 20:05 < ricky> But not totally complete either. 20:05 < 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 < abadger1999> smooge: That's a good point. So I made several proposals in the wiki page. 20:05 < smooge> ricky, ok thanks.. 20:05 * johe here, late but here 20:05 < abadger1999> davivercillo: Welcome! 20:05 < davivercillo> abadger1999: thanks ! =D 20:05 < ricky> jeff_hann, davivercillo: Hey, welcome! 20:05 < abadger1999> smooge: We can do several things... 20:06 < heffer> i'm here too :) 20:06 < abadger1999> 1) Not hotfix. Everything has to be released as a tarball which we can link to. 20:06 < abadger1999> Pro: simple. Con: limiting 20:06 -!- Southern_Gentlem [n=notfred@fedora/Southern-Gentleman] has quit Remote closed the connection 20:06 < f13> 'released as a tarball'? 20:07 < abadger1999> 2) thanks to our new policy, hotfixes have tickets. 20:07 < 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 -!- kolesovdv [n=kolesovd@xxxxxxxxxxxxx] has joined #fedora-meeting 20:07 < abadger1999> f13: So it can't be HEAD. 20:07 < dgilmore> f13: released as a tarball that can be packaged 20:07 < abadger1999> f13: It would have to be a branch dedicated to mirror produciton. 20:08 < f13> sorry I think I'm not quite following the discussion 20:08 < 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 < f13> I thought the no hotfix policy meant that fixes have to be in rpm form in the repo 20:08 < f13> or in puppet 20:08 < f13> but not just modified directly on the box in question 20:09 < abadger1999> f13: This is a different policy.... licensing Guideline. 20:09 < dgilmore> f13: they should be yes 20:09 < abadger1999> f13: We're going to try to switch to the AGPLv3. 20:09 < f13> ah right, nuance there 20:09 < abadger1999> f13: (In part because moksha/ fedora community is) 20:10 < 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 < abadger1999> smooge: Other options that aren't so painful? 20:10 < f13> imho we are either running rpm code, or running signed tagged checkouts 20:11 -!- Southern_Gentlem [n=notfred@fedora/Southern-Gentleman] has joined #fedora-meeting 20:11 < smooge> I am wondering if a git archive meets the AGPL need. 20:11 < f13> and thus we can either point to the srpm, or to the source repo we're running a checkout from 20:11 < dgilmore> i think we should always use rpms 20:11 -!- JSchmitt [n=s4504kr@fedora/JSchmitt] has quit Remote closed the connection 20:11 < abadger1999> f13: Early on in infrastructure I proposed that we use checkouts from revision control. 20:11 < f13> releasing tarballs is a bit of a hassle and redundant in today's scm days 20:11 < dgilmore> then they are always available via the infra repo 20:11 -!- Sonar_Guy [n=Who@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #fedora-meeting 20:11 < smooge> I would prefer if we used RPMS so we can do the worlds easiest tripwire (rpm -V) 20:11 < abadger1999> I stil think that's nice... but I don't think mixing rpms and checkouts for a single app is good. 20:12 < f13> if we go with scm checkouts, the process to get it checked out and deployed has to be in puppet 20:12 * ricky agrees with what abadger1999 says 20:12 < abadger1999> We'd either want rpms always (with hotfixes) or checkouts always for any given app. 20:12 < f13> so using a tag is somewhat necessary 20:12 * 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 < smooge> f13 I would like it to be the following: 20:12 < ricky> Luke always manages to get hotfixes into RPMs - maybe we can aim for the same? 20:12 < dgilmore> abadger1999: does the direct link to the source need to be on each web page 20:12 < abadger1999> heh, last time he complained about it though ;-) 20:13 < abadger1999> spot: ping 20:13 < f13> he's at LS 20:13 < f13> in canadia 20:13 < abadger1999> Yeah... 20:13 < smooge> git pull, make changes, git commit, git whatevermakes branches, git push; make rpm; make push-to-repo; puppet do your thing 20:13 < abadger1999> I hear they have internet there ;-) 20:13 < f13> don't even have to do that 20:13 < mdomsch> abadger1999, barely generally... 20:13 < f13> git pull/ chnage/ commit/ tag push ; push --tags 20:14 < f13> puppet config would always be pulling from a given tag in the repo 20:14 < abadger1999> mmcgrath: care to go over why you'd rather have rpms than checkouts again? 20:14 * mmcgrath might be missing something too 20:14 -!- Sonar_Guy [n=Who@fedora/sonarguy] has quit Client Quit 20:14 -!- Sonar_Guy [n=Who@fedora/sonarguy] has joined #fedora-meeting 20:14 < mdomsch> abadger1999, for the same reason we don't install everything into /usr/local? 20:14 < mmcgrath> abadger1999: you're talking about packages right? 20:15 < mmcgrath> like fas? 20:15 < abadger1999> mmcgrath: correct 20:15 < 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 < ricky> rpm -V, package dependencies and puppet's facilties for managing packages are nice 20:15 < abadger1999> using puppet to pull it will give us repeatablity. 20:15 < dgilmore> f13: id like to know why you think pulling from scm is better? 20:15 < f13> HEAD is bad 20:15 < skvidal> abadger1999: so now we have 2 pkging systems? 20:15 < 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 < ricky> It's also pretty consistent between apps 20:16 < ricky> That's why I like RPMs 20:16 < abadger1999> skvidal: That's one strike against it, sure. 20:16 < skvidal> abadger1999: it's a big strike, imo 20:16 < 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 < mmcgrath> abadger1999: what benefit do we get? 20:16 < 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 < 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 < skvidal> f13: not sure it is easier for anyone else looking to replicate what we do 20:17 < f13> once things get more stable, I definitely agree that rpms are the way to go 20:17 < dgilmore> abadger1999: ok, just curious as to how we meet the requirement thatthe live code is available 20:17 < 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 < skvidal> f13: nor does it provide the unity of system 20:17 < f13> skvidal: correct, it is not a perfect solution. There are none 20:17 < smooge> could we ship them as conaries? 20:17 -!- fbijlsma [n=fbijlsma@xxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #fedora-meeting 20:18 < skvidal> I think we'd end up making our very own 'stow' type of system 20:18 < mmcgrath> abadger1999: you can do that in the test environment if you want :) but not in production 20:18 < skvidal> which is just implementing another package system 20:18 < dgilmore> f13: i have to say its maybe easier from a developer standpoint but not from a sysadmin perspective 20:18 < 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 < abadger1999> Those are the benefits. 20:18 < f13> dgilmore: from a sysadmin perspective, does it matter much when its entirely driven by puppet? 20:18 < abadger1999> (as I see them). But there's definitely cons. 20:19 < mmcgrath> abadger1999: but once it's in production it's not about them 20:19 < dgilmore> f13: i think so 20:19 < ricky> Even in puppet, it would add a good deal of complexity. 20:19 < f13> mmcgrath: so we're only talking about once in production? 20:19 < f13> but a test instance in development wouldn't have to play by the same rules? 20:19 < mmcgrath> well I'm talking a minimum of once it's in production. 20:19 < mmcgrath> I'd prefer it in staging. 20:19 < mdomsch> agpl doesn't seem to note any difference 20:19 < 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 < mmcgrath> on the publictest servers I don't have a preference since so much actual development goes on there. 20:20 < mmcgrath> abadger1999: I'd hope they'd be developing on their workstation, not in production is all. 20:20 < abadger1999> mmcgrath: If we're sticking with rpms over scm, I definitely want rpms in staging. 20:20 < dgilmore> abadger1999: right do same thing across the board 20:20 < mmcgrath> just so I'm clear who's advocating the tarball method, who's advocating rpms and who has no preference? 20:21 < mmcgrath> +1 rpm 20:21 * ricky likes RPMs in staging/production 20:21 < 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 < ianweller> +0 20:21 -!- kital [n=Joerg_Si@fedora/kital] has joined #fedora-meeting 20:21 < dgilmore> mmcgrath: i think tarballs should lead to rpms and we should use rpms 20:21 < f13> I'm advocating checkouts from a specific tag in scm at least during the time where changes are rapid. 20:21 < mdomsch> quoth agpl 20:21 < skvidal> +1 rpm 20:21 < f13> whether that time is restricted to pre-staging or not, I don't really care 20:21 < ricky> I think the argument here is that changes should be rapid in testing/development, not in staging/prod 20:21 < smooge> mdomsch, what difference 20:21 * mdomsch uses staging as a test platform 20:22 < mdomsch> rpm + patches from scm 20:22 < ricky> Currently, people are free to go from SCM on publictest machines though 20:22 < mmcgrath> ricky: and typically do 20:22 < smooge> mdomsch, nm.. figured it out 20:22 * ianweller certainly does :) 20:22 < skvidal> mdomsch: what does '+patches' mean? 20:22 < skvidal> mdomsch: do you mean patching the fs itself - or do you mean %patches? 20:23 < mdomsch> skvidal, most often, git-format-patch HEAD^; scp 0001-foobar.patch app1.stg 20:23 < skvidal> mdomsch: nod 20:23 < abadger1999> No preference -- as long as we do it across the board. 20:23 < f13> so, lets propose that once an app goes to staging, all modifications to the app must happen through rpms 20:23 < mdomsch> test; fix; repeat; cut version 20:23 < ianweller> if we go RPMs are we going to require that on pt servers 20:23 < smooge> ok stupid question time.. do changes to configuration files count as patches that need to be publci. 20:23 < f13> since one can easily generate a rpm with patches from git 20:23 < f13> before one does the actual full release 20:23 < mmcgrath> f13: I'd make an exception for emergency patches that require a ticket. 20:23 < skvidal> smooge: I don't think so 20:24 * abadger1999 agrees with mdomsch's use of staging 20:24 < f13> mmcgrath: why make an exception? It takes only a few minutes to generate a patched rpm 20:24 < 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 < mdomsch> I don't want to have to respin the RPM just to test a fix on staging 20:24 < skvidal> :) 20:24 < ricky> mmcgrath: What is the policy on testing hotfixes on staging? 20:24 < f13> mdomsch: apparently it isn't about your wants though. 20:24 < ricky> mmcgrath: Like when we were doing FAS testing there, I ran it off of a patched wsgi file somtimes. 20:24 < abadger1999> smooge: I agree with skvidal. configs are managed via puppet 20:25 < f13> mdomsch: if we go strict to just rpms in production, it seems that we want the same thing in staging 20:25 < mmcgrath> it's been my experience that in our environment, requireing a full rebuild of an rpm is a pretty high cost. 20:25 < mmcgrath> not everyone has access to the signing key for one thing. 20:25 < 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 < smooge> mdomsch, mmcgrath are we using staging for devepment or for integration.. or both 20:25 -!- thekad [n=kad@xxxxxxxxxxxxx] has joined #fedora-meeting 20:25 < 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 < mmcgrath> smooge: a little of both. It's really supposed to be for integration/staging. 20:25 < ricky> staging has been mostly for staging deployments and debugging issues (like FAS 500s) in an environment with close-to-prod data 20:25 < abadger1999> mdomsch: +1 20:26 < mmcgrath> but we don't have a fully functional development environment. 20:26 < smooge> so we need some .devel. boxes for everything? 20:26 < f13> mdomsch: isn't that what publictest instances are for? 20:26 < 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 < mmcgrath> f13: we don't have enough pt boxes though 20:26 < f13> ah. 20:26 < mmcgrath> many of them are being used for proof of concepts and things. 20:26 < ricky> smooge: devel mostly happens on pt machines or home machines right now 20:26 < 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 * smooge starts to look up .pt. boxes to figure out how many are needed 20:26 < 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 < mmcgrath> in theory, for a full environment, we'd need 20:27 < mmcgrath> 1 db server 20:27 < mmcgrath> 2 app servers 20:27 < mmcgrath> 1 proxy server 20:27 < mmcgrath> 1 bapp server 20:27 < mmcgrath> 1 releng box 20:27 < mmcgrath> 1 koji box 20:27 < 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 < mmcgrath> 1 cvs host 20:27 < mmcgrath> so that's a minimum 8 per environment. 20:27 < f13> mdomsch: that's a very strange interpretation of "public" 20:27 < mmcgrath> so if we do a full staging and devel environment that's 16 new boxes 20:27 < mmcgrath> err new hosts. 20:27 < f13> mdomsch: I wonder if they assume "staging" isn't on the internet 20:28 < f13> where ours is 20:28 < 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 < 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 < mdomsch> the only "users" of the staging server is us 20:28 < mmcgrath> abadger1999: are we discussing this for legal obligations or just to get our policy figured out? 20:28 < f13> mdomsch: except that the staging servers are accessable by the entire world. 20:28 < jwb> i missed something. how did agpl get involved here? 20:28 < mdomsch> therefore: rpms only in production; rpms + patches in staging. 20:28 < 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 < f13> jwb: we're talking about re-licensing all of Fedora web apps as agpl 20:29 < mdomsch> f13, they are? 20:29 < mmcgrath> thekad: not reliably 20:29 < f13> jwb: and if we do, there are things we have to consider 20:29 < jwb> ok.... 20:29 < f13> mdomsch: Hrm, I was under the impression that they were. 20:29 < ricky> technmeg: We usually don't want real data on development 20:29 < jwb> why agpl? 20:29 < 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 < abadger1999> thekad: staging is supposed to be more secure than devel. So separate db servers. 20:29 < mmcgrath> :) 20:29 < f13> jwb: moksha alreasy is agpl 20:29 < thekad> abadger1999, gotcha 20:29 < mdomsch> mmcgrath, app1.stg isn't reachable outside FI, right? 20:29 < abadger1999> jwb: Largely because moksha/community switched to it. 20:30 < mmcgrath> mdomsch: correct 20:30 < ricky> mdomsch: It isn't, but the staging proxy server is 20:30 < abadger1999> jwb: Here's some additional justification: https://fedoraproject.org/wiki/Infrastructure_Licensing 20:30 < ricky> So it's similar to the prod setup 20:30 < f13> mdomsch: I stand corrected 20:30 -!- j6k [n=j6k@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit 20:30 -!- tibbs [n=tibbs@fedora/tibbs] has quit "Konversation terminated!" 20:31 < mmcgrath> lets take a step back and look at the hot fix we did for mirrormanager last week. 20:31 -!- lxo [n=aoliva@xxxxxxxxxxxxx] has joined #fedora-meeting 20:31 < 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 < mmcgrath> Pretend mirrormanager was AGPL. 20:31 < mmcgrath> abadger1999: would we have not been able to do what we did? 20:31 -!- mizmo [n=duffy@xxxxxxxxxxxxxx] has quit Read error: 110 (Connection timed out) 20:31 < smooge> f13, lets table that for mmcgrath's stuff then we will discuss proposal 20:31 < abadger1999> mmcgrath: Where's the ticket for that? 20:32 < jwb> abadger1999, thanks 20:32 < abadger1999> Let's look at it and see what we might need to do differently. 20:32 < mmcgrath> .ticket 1524 20:32 < zodbot> mmcgrath: #1524 (Hot Fix - mirrormanager) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1524 20:32 -!- mizmo [n=duffy@nat/redhat/x-4bd73725e762e35e] has joined #fedora-meeting 20:32 < abadger1999> So mirrormanager --- we have a base of an rpm that's available from the repo on http://infrastructure.fedoraproject.org/ 20:32 < mdomsch> include srpm 20:32 < abadger1999> We don't have a patch in the ticket... 20:33 < 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 < mdomsch> abadger1999, you have a pointer to the patch 20:33 < f13> (and then have something on MM that points to the ticket queue to look for changes) 20:33 < abadger1999> Right. Partial instructions on how to generate a patch 20:33 < f13> you have a pointer to the patch that was reversed. 20:33 < abadger1999> <nod> 20:33 < f13> now, I don't think anybody would sue us over the minor nit pick 20:34 < mmcgrath> abadger1999: ok, now take this same scenario 20:34 < mdomsch> especially as the patch is public 20:34 < mmcgrath> and lets say that it wasn't a revert. But I had to add a line of code. 20:34 < f13> mmcgrath: you'd generate a patch file, attach it to the ticket 20:34 < ricky> Attaching the patch sounds reasonable to me. 20:34 < mmcgrath> and that alone, would make me legally compliant? 20:34 < f13> (or reference the commit upstream) 20:34 < mdomsch> or commit the patch to MM upstream, with a pointer to the commit 20:35 < f13> mmcgrath: provided that the mirrormanager site has some link to the ticket queue 20:35 < mmcgrath> mdomsch: it dawns on me that I actually have commit access in MM and should have done that ;-) 20:35 < abadger1999> mmcgrath: I'd say that we need a patch, rather than just hte line of code pasted in the ticket. 20:35 < abadger1999> (as the patch tells where in the code to apply it). 20:36 < 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 < abadger1999> We'd also need to point people at the patch. 20:36 < abadger1999> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&keywords=%7EHOTFIX&order=priority 20:36 < zodbot> abadger1999: http://tinyurl.com/nglq4f 20:36 < f13> an dhas the shasum of the patch which won't change when applied upstream 20:36 < abadger1999> I thought that would do us... but it's not quite enough :-( 20:36 < abadger1999> We need two keywords per hotfix. 20:37 < abadger1999> Hotfix Appname 20:37 < 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 < f13> mmcgrath: right. MirrorManager would have to have a link to wherever the patch is posted. 20:37 < mmcgrath> holy fuck do I hate AGPL 20:37 < ricky> :-( 20:37 < abadger1999> That way mirrormanager can say infrastructure.fedoraproject.org rpm/srpm + URL that finds just mirrormanager hotfixes. 20:37 < f13> be it the infra ticket queue, the MM ticket queue, or the MM upstream repo 20:37 < davivercillo> :P 20:37 < jwb> mmcgrath, heh. and i thought i was the only one 20:38 < f13> mmcgrath: hate or not, it's actually making us be much better about our patch management. 20:38 < abadger1999> mmcgrath: well, we haven't relicensed anything yet -- now's the time to holler if it's not going to fly. 20:38 -!- fbijlsma [n=fbijlsma@xxxxxxxxxxxxxxxxxxxxxxxxxx] has quit "Leaving" 20:38 < f13> the infrastructure ticket could have been moved to MM"s trac instead 20:38 < mmcgrath> how will the actual implementation of this "linking to bug fixing" work? 20:38 < ricky> f13: That makes them harder for us to track though :-( 20:39 < abadger1999> mdomsch: Re: or commit the patch to MM upstream, with a pointer to the commit 20:39 < mdomsch> MM is the upstream project. It doesn't need a link to all the downstream implementations thereof. 20:39 < abadger1999> mdomsch: I don't think that's enough. 20:39 < thekad> f13, having moved to MM's trac and referencing that trac on f-i's trac would work? 20:39 < f13> ricky: rather, a ticket with the patch could have been filed at MM site. 20:39 < ricky> A central web area where we store current patches to our apps? 20:39 < mmcgrath> is that a legal question? 20:39 < abadger1999> mdomsch: Unless there's a branch dedicated to what we deploy. 20:39 < mmcgrath> mine I mean. 20:39 < mdomsch> The downstream implementations need a link to the code they're running: that can be "pointer to upstream version" plus patches 20:39 < abadger1999> mdomsch: ie, a patch against HEAD might not apply to what we have in production. 20:39 -!- cyberpear [n=james@fedora/cyberpear] has joined #fedora-meeting 20:40 < f13> mmcgrath: probably a legal question 20:40 < mdomsch> abadger1999, rpmfusion uses MM now too. I'd need a separate branch for them too? 20:40 < mmcgrath> Ok 20:40 < mdomsch> repeat for other folks wanting to run MM 20:40 < mmcgrath> so I think here's what we generally agree on. 20:40 < mdomsch> and then give those downstream users commit rights on my repo? 20:40 < mdomsch> uh, no thanks. 20:40 < 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 < f13> no other details. 20:40 < f13> mdomsch: why would they have commit access? 20:40 < f13> mdomsch: they can post patches in tickets just like everybody else 20:40 < f13> you can choose to apply them if you want. 20:41 < f13> but that's not a matter for us 20:41 < mdomsch> f13, for abadger's suggested "FI deployment branch" 20:41 < f13> lets forget that MM is done by one of us 20:41 < mmcgrath> so I think we agree, you make a change. Put the patch in fedora-infrastructure trac right? 20:41 < abadger1999> mdomsch: Yep. So I don't think the "pointer to scm commit" is going to work well. 20:41 < mdomsch> mmcgrath, I agree. 20:41 -!- mcepl [n=mcepl@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has left #fedora-meeting [] 20:41 < 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 < mdomsch> abadger1999, it _can_ work for apps we own; but none other. 20:41 < abadger1999> f13: Note that I talked to spot and specifically brought up this point. 20:41 < mmcgrath> Should we ask legal about the "linking app back to bug tracking" bit? 20:41 < 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 < ricky> **page 20:41 < 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 < mdomsch> f13, right 20:42 < 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 < ricky> It wouldn't be too hard to setup a directory containing all currently applied live patches 20:42 < mmcgrath> abadger1999: did spot say that was a hard requirement? 20:42 < smooge> ricky, we send them to a src.rpm file? 20:42 < mmcgrath> Does oracle ship any products similar but with a less confusing license? 20:42 < f13> abadger1999: nod. I think it depends on how 'exact' we have to be in offering the source 20:42 < ricky> smooge: Well, I'm just talking about live patches here, not package changes 20:42 < mdomsch> corresponding == exact 20:43 < f13> then Fedora Community will be out of compliance the moment we apply a patch 20:43 < f13> since their pages only point you to fedorahosted, not even the git repo 20:43 -!- jeff_hann [n=arares@xxxxxxxxxxxx] has quit Remote closed the connection 20:43 < f13> you have to go somewhere else once you get to fedora hosted to get to the source code 20:43 < abadger1999> f13: Yeah -- I'm a bit worried about that actually. 20:43 < ricky> OK, so are we basically waiting on legal advice about the linking requirements at this point? 20:43 < f13> well the page tells you how to get it 20:43 < 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 < abadger1999> f13: Since even git repo != what we have deployed without additional instructions 20:43 < ricky> Because otherwise, it doesn't seem to be moving forward all that much 20:44 < jwb> make a pi icon that you can click and it just starts spewing the live source 20:44 < abadger1999> Can we eliminate some things? 20:44 < f13> IMHO it should be enough to point to A) upstream source, B) any changes we make to it. 20:44 < jwb> like the agpl? 20:44 < jwb> sorry, i should shut up 20:44 < f13> A) can be the upstream source repo, B) can be a ticket query that shows any active hotfixes 20:44 < abadger1999> jwb: No that's valid. 20:45 < mmcgrath> abadger1999: and you talked to spot specifically about having our applications point directly to trac? 20:45 < jwb> abadger1999, perhaps. but i have little vested in this 20:45 < f13> (and I guess hotfixes will have to remain active if they are only in our rpm and not the upstream source) 20:45 < abadger1999> Proposal #1 -- Don't use AGPL as license. 20:45 < abadger1999> mmcgrath: No -- just whether we have to provide any hotfixes that go onto our servers. 20:45 < f13> I really don't want to get into banning software due to it's free license 20:45 < abadger1999> We didn't talk about how to provide them. 20:45 < jwb> f13, bannign? 20:46 < f13> banning that is 20:46 < abadger1999> f13: Not quite what we're saying 20:46 < f13> sure it is 20:46 < mmcgrath> we ban software based on free licenses already :) 20:46 < abadger1999> f13: This is about how we license our stuff. 20:46 < f13> define "our stuff" 20:46 < abadger1999> f13: Not about third-party stuff. 20:46 < mmcgrath> "Don't use AGPL as license" meaning FAS, mirrormanager, etc. 20:46 < f13> is Fedora Community "our stuff" or third party? 20:46 < ricky> Proposal #2: Central directory containing all patches linked directly on website footers as well as source? 20:46 < abadger1999> If we write it 20:46 < f13> define "we" 20:46 < ricky> (That's if the trac ticket thing doesn't fly) 20:46 < abadger1999> f13: That's actually a problem 20:46 < mmcgrath> f13: he's saying "don't apply AGPL to our software" not "don't use software that is under AGPL" 20:46 < 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 < dgilmore> f13: things written with fedoraproject use intended 20:46 < abadger1999> Fedora Community acts like a third party but wants in-house treatment. 20:47 < abadger1999> We have to shift that one way or another. 20:47 < ricky> Agreed 20:47 < f13> jwb: because the AGPL actually ensures that the source code for the web service you're using is actually available 20:47 < f13> unlike other licenses where you can patch it to hell and back and never be required to provide your changes 20:47 * 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 < dgilmore> abadger1999: right i view it as third party due to the way that things have been done 20:48 < jwb> f13, i don't think that is really causing Fedora any pain 20:48 < f13> mmcgrath: define "distribution" 20:48 < jwb> whereas using AGPL seems to... 20:48 < abadger1999> jwb: What f13 said and that Community is using it -- which means that sharing code with community is harder. 20:48 < thekad> mmcgrath, +1 20:48 < 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 < mmcgrath> f13: don't have to, thats for legal to decide 20:48 < mmcgrath> as well as what day of the week it is ;) 20:48 < f13> Lets look at koji code 20:49 * abadger1999 notes that we're at 46minutes. 20:49 < 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 -!- cyberpea1 [n=james@fedora/cyberpear] has joined #fedora-meeting 20:49 < 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 < f13> we'd want those code changes, particularly as they're a compeditor 20:49 < ricky> **none 20:49 < dgilmore> f13: they could 20:49 -!- sharkcz [n=dan@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit "Ukončuji" 20:49 < dgilmore> f13: as koji is currently licensed 20:49 < f13> with the way that koji is licensed now, they can do just that, and we have no recourse 20:49 < thekad> yeah, nine are too many 20:49 < 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 < ricky> thekad: :-) 20:50 < dgilmore> f13: they do have to post there code for there customers 20:50 < f13> if it were AGPL, they'd be required to make those changes available. 20:50 < f13> dgilmore: not as a webapp 20:50 < 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 < abadger1999> dgilmore: They're not distributing hte web ap.. only letting people use it. 20:50 < 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 < dgilmore> f13: right. 20:50 -!- RadicalRo [n=radical@xxxxxxxxxxxxxx] has quit "Leaving." 20:50 < abadger1999> mmcgrath: Yes. 20:51 < f13> mmcgrath: practical very often gets in the way of opensource licensing 20:51 < mmcgrath> we've got some decisions to make. 20:51 < abadger1999> Although doing practical things has always been illegal. 20:51 < jwb> mmcgrath, burdensome at best. illegal at worst 20:51 -!- cyberpea2 [n=james@fedora/cyberpear] has quit Read error: 110 (Connection timed out) 20:51 < abadger1999> This just hits us in a place where we haven't considered before. 20:51 < f13> the burden really only seems to be on A) making the site footer link to places we put source 20:51 < 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 < 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 < f13> the rest of it is really just good practice (posting patches to tickets for hotfixes we make) 20:52 < ricky> abadger1999: Oh :-( that's starting to get pretty annoying then. We can currently do that with GPLv2? 20:52 < abadger1999> ricky: That was an example of something that's illegal now. 20:52 < mmcgrath> abadger1999: "now" as in the AGPL world or now as in like right this second? 20:53 -!- lxo [n=aoliva@xxxxxxxxxxxxx] has quit Connection timed out 20:53 < ricky> Oh, OK. 20:53 < 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 < abadger1999> mmcgrath: right this second 20:53 < abadger1999> GPL (any version) not compatible with CC (any variant) 20:53 < f13> abadger1999: define "link to javascript"? 20:54 < 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 < mmcgrath> s/things/thinks/ 20:54 < skvidal> mmcgrath: she would think "I have hired people to do this for me" 20:54 < 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 < f13> but I could be on crack, so blah. 20:55 < smooge> ok how about this.. can we dual license? 20:55 < abadger1999> smooge: Nooooooo ;-) 20:55 < mdomsch> f13, I'd love to to get more info on that if so... 20:55 < mdomsch> really. 20:55 < abadger1999> Query -- is there anything else to announce/discuss today? 20:56 < abadger1999> I've got nothing else but this. 20:56 < mmcgrath> abadger1999: I don't think so. 20:56 < mmcgrath> we spent literally the whole meeting on this. 20:56 < ricky> Yeah, we're almost at the 1 hour mark on just this 20:56 < abadger1999> Okay -- we have 6 minutes -- shall we list our questions for spot? 20:56 < mmcgrath> which is a strong indication.... we've bitten off quite a bit here. 20:56 < mmcgrath> abadger1999: yeah 20:56 < mmcgrath> #topic Infrastructure -- Questions for legal 20:56 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Questions for legal 20:56 < ricky> 1) Explain the linking requirements 20:56 < mmcgrath> 1) Do we have to link the application to the ticket 20:57 < mmcgrath> 2) Is it really "absolutely critical" that fedoracommunity be AGPL 20:57 * mdomsch has another meeting; thanks all. 20:57 < ricky> mdomsch: See you later 20:57 < mmcgrath> mdomsch: laters 20:57 < f13> 3) Is linking to a list of tickets with patches to the application enough to cover "modifications" 20:57 < smooge> 4) Do config changes count as code changes if the config file is marked as being AGPL 20:57 < 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 < 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 < smooge> we need one more 4 20:58 < jwb> btw, i'm not against AGPL as a whole. but it seems like lots of work for little gain here 20:58 < 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 < davivercillo> bye 20:58 < smooge> bye 20:58 < mmcgrath> jwb: I'm not either, I just want someone else to use it, not me :) 20:58 < ricky> davivercillo: Thanks for stopping by, sorry we didn't get a chance to discuss anything else 20:59 < mmcgrath> Ok, any other questions? 20:59 < abadger1999> davivercillo: Thanks for being here -- we can talk some other day in #fedora-admin 20:59 < mmcgrath> davivercillo: take it easy, see you next week. 20:59 < jwb> abadger1999, dual license might not be so bad 20:59 < 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 < davivercillo> thanks ! 20:59 < jwb> abadger1999, stuff in staging is $not_agpl. stuff in production is 20:59 < ricky> would that double the requirements we have to hold up? 20:59 < f13> honestly, I think it wouldn't take much work on our part to comply with AGPL 20:59 -!- davivercillo [n=daviverc@xxxxxxxxxxxxx] has left #fedora-meeting [] 21:00 < skvidal> f13: I think I agree w/you 21:00 < abadger1999> jwb: Is that question 6) 21:00 < jwb> abadger1999, actually. scratch that 21:00 < ricky> I agree with f13, but there's still the question of how worth it it is for the work 21:00 < f13> provided legal responds well to our questions, such as just linking to tickets. 21:00 < abadger1999> Okay 21:00 < skvidal> ricky: same question could be asked of the GPL - but surely we value what we get from it 21:00 < f13> ricky: I think it's very little work we wouldn't/shouldn't already be doing. 21:00 < 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 -!- cyberpear [n=james@fedora/cyberpear] has quit Connection timed out 21:00 < mmcgrath> Ok all we're at time. 21:00 < f13> jwb: I was corrected, staging isn't "public" 21:00 < mmcgrath> anyone have anything else? If not we'll close the meeting 21:00 < abadger1999> 6) Do we need to link to the source from every page of the app? 21:01 < jwb> f13, so hotfixes are the largest concern then? 21:01 < f13> jwb: yes 21:01 < ricky> Staging is web-accessible, ubt we do not necessarily consider it public 21:01 < smooge> close 21:01 < ricky> *8but 21:01 < ricky> **but 21:01 < ricky> So let's make that 7) Does staging count if it's web-accessible 21:01 < jwb> f13, hm. my concerns are lessened but not completely 21:01 < f13> ricky: uh, mmcgrath earlier said it wasn't public. 21:01 < jwb> confused as to how it's not public 21:01 < ricky> https://admin.fedoraproject.org/community/ 21:01 < ricky> That's the type of public I'm talking about 21:01 < 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 < ricky> app1.stg is not publicly accessible, but the proxy server that serves the app is 21:02 < mmcgrath> https://admin.stg.fedoraproject.org/community/ is I think the link you want. 21:02 < abadger1999> jwb: We're trying to divide it on the term "users". 21:02 < f13> <mdomsch> mmcgrath, app1.stg isn't reachable outside FI, right? 21:02 < f13> <mmcgrath> mdomsch: correct 21:02 < mmcgrath> app1.stg isn't 21:02 < jwb> abadger1999, maybe that's a question for legal too 21:02 < ricky> mmcgrath: Oops, thanks 21:02 < mmcgrath> it's through a proxy server 21:02 < f13> er. 21:02 < f13> that's a symantic 21:02 < abadger1999> jwb: Okay.. care to phrase it for me? 21:03 < f13> if the world can get to the site, it's public 21:03 < f13> and AGPL would apply 21:03 < ricky> jwb: My #7 is that exact question 21:03 < jwb> ricky, oh, ok 21:03 < jwb> abadger1999, then whatever ricky said :) 21:03 < mmcgrath> Ok guys we're going over, anyone have anything else? 21:03 < f13> so it looks like staging /would/ have to account for AGPL 21:03 < mmcgrath> abadger1999: you have everything you need to keep you busy? 21:03 < abadger1999> mmcgrath: For weeks and weeks ;-) 21:03 < 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 < abadger1999> Close it up and lets continue on list 21:04 < mmcgrath> Ok, if no one has anything else I'll close in 10 21:04 < mmcgrath> #endmeeting 21:04 -!- zodbot changed the topic of #fedora-meeting to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule 21:04 < zodbot> Meeting ended Thu Jul 16 21:04:24 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 21:04 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.html 21:04 < jwb> f13, so if staging is public, ew 21:04 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.txt 21:04 < mmcgrath> Thanks for coming everyone 21:04 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.log.html
Attachment:
pgphTGJKboY6z.pgp
Description: PGP signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
