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(a)c-67-175-200-175.hsd1.il.comcast.net] has joined
#fedora-meeting
20:02 < mmcgrath> .tiny
https://fedorahosted.org/fedora-infrastructure/query?status=new&statu...
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(a)82.162.141.18] 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(a)adsl-074-171-066-196.sip.aby.bellsouth.net] 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(a)p54B2CF21.dip.t-dialin.net] 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(a)189.187.93.83] 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(a)195-240-118-19.ip.telfort.nl] 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(a)150.187.40.27] 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(a)66.187.234.199] 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&statu...
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(a)p54B2CF21.dip.t-dialin.net] 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(a)49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] 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(a)188.24.37.69] 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(a)plz1-v-4-17.static.adsl.vol.cz] 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(a)193.254.32.144] 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(a)150.187.40.27] 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(a)146.164.31.95] 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...
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...
21:04 < mmcgrath> Thanks for coming everyone
21:04 < zodbot> Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting...