Add patch to global.pp
by Toshio Kuratomi
ricky and I were considering adding patch to global.pp and dennis
brought up that it might be a command used to do malicious stuff. So
what do you guys think?
Pros:
patch makes some things much easier to do. Want to cherrypick a change
as a hotfix? Many times patch is needed to apply the diff. Want to
replicate some changes from server1 to servers 2, 3, and 4? diff on
server1, patch on the others. Need to review a change that someone else
has done and then apply it? Read the diff they give you and apply it
rather than grabbing the whole file, doing the diff yourself, and then
applying it.
Cons:
patch is a commonly used utility that is often used to edit files. So
the principle of not installing things that aren't needed makes it one
more tool that an attacker won't have if they get remote execution on a
box they shouldn't. However, there's many other things that an attacker
can do if they gain remote execution. Rather than retrieving a diff and
applying that to a file, the attacker can just retrieve a file and then
replace the existing one; we have wget, curl, and scp installed. ed,
sed, perl, python, and other text processing tools are available. I'm
thinking if the attacker can gain the ability to execute a remote
command and they have permission to touch files that are going to cause
us harm, lack of patch isn't going to save us.
Other:
* patch doesn't have any deps that aren't already installed on one of
our boxes.
What's the consensus here?
-Toshio
14 years, 9 months
Relicensing Part II
by Toshio Kuratomi
Alright! So the last two weeks there wasn't much comment on:
https://fedorahosted.org/fedora-infrastructure/ticket/1524
https://fedoraproject.org/wiki/Infrastructure_Licensing
but I think people were either sleeping or didn't entirely understand
what the AGPL's requirements mean for us as this week we filled the
whole meeting with discussion[1]_.
We arrived at a few conclusions about options we did not want to explore
but got into a few questions that need answers from legal before we can
continue. Please clarify the questions or add new ones if you can think
of other things that we need to know from legal. Once that's done or
tomorrow (whichever comes first) I'll make sure that spot gets the list
so we can get some input and better consider our options.
Questions follow:
== What we decided ==
* Continue to deploy as rpms to production and as the basis of staging.
* In production, hotfixes need to have tickets in trac. Those tickets
may be required to contain patches applied to the server if we determine
that's the best course under legal.
- If that's not the best course, hotfix tickets still need to contain
an indication of what the hotfix does but this could be "I reverted
commit 12345" or "I changed three files to import simplejson instead of
json (python-2.4 compatibility)"
* In staging, we want to deploy with a base rpm and may add patches and
local changes on top of that to test things. When we get to the point
where we are satisfied, this needs to be turned into an rpm and be
deployed to production/installed in the staging env.
* In publictest, we want people to be able to deploy from SCM, make
local changes, etc. publictest are pure development machines.
== Explain the linking requirements ==
How the running app leads people to the source for the app is causing
the most concerns. Here's a list of questions. There's a lot because
we don't have a feel for what's allowed and not allowed yet.
Where relevant, assume that the running applications have rpms/srpms
present on infrastructure.fedoraproject.org, an upstream trac/scm
instance on fedorahosted.org, and that we are running with some number
of hotfixes to the live application.
* Do we need to link to the source from every page of the app?
* What are legal means of giving people access to the corresponding source?
+ Source repository at no particular version (assuming all of our
patches are applied to trunk -- and trunk might contain other changes as
well, including full or partial reversions of those changes in a later
revision)
+ Source repository at no particular version (assuming all of our
patches are applied to a branch that mirrors production)
+ Pointing exactly to source repository branch or tag of the exact
version we're running
+ Home page of the project (example: http://fedorahosted.org/fas)
+ Just a page specifically linking to the sources and all of the
patches we've applied
+ links to base srpm and page listing patches
+ links to base srpm and tickets in trac that have patches attached
+ links to base srpm and tickets in trac that point to commits in
SCM that are applied against different versions (HEAD vs the last
release, for instance)
+ A page linking to the sources and a page linking to any hotfixes
we've applied to any of our apps (ie, a query in infrastructure's trac
that gets all hotfixes for all of our apps).
+ I'm assuming these to be fine: tarball, srpm that matches what's
running, actual links to base tarball and to all of the patches
* Do config changes count as code changes if the config file is marked
as being AGPL?
- If yes, what do we have to do to make config files not be licensed
under AGPL? (We want to protect passwords, for instance).
== Related to Other Apps ==
Our original impetus for relicensing is so we can freely share code with
fedoracommunity. The cost of maintaining AGPL compliance with other
apps needs to be weighed against the cost of reinventing code in
fedoracommunity (or waiting for fedoracommunity developers to relicense
their code for use elsewhere *cough CSRF middleware cough* :-) ).
* Is it really "absolutely critical" that fedoracommunity be AGPL?
* Can we get a clarification of what the consequences would be if fedora
community stays AGPL but our apps stay as they are (GPLv2)?
== Related to Staging ==
We use the staging environment for both some development duties and
integration testing. Because of that we want to be able to deploy into
staging things that we aren't providing exact corresponding source for
at the moment. The staging environment is reachable by members of the
general public but we'd like to find out if we can consider it an
internal service that doesn't need to track every little change we make.
Here's the portions of the AGPL we think is relevant:
From the preamble:
"""
public use of a modified version, on a publicly accessible server, gives
the public access to the source code of the modified version.
"""
Section 13:
"""
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software.
"""
* Is the preamble legally binding/part of the AGPL or should we ignore
anything there?
* admin.stg.fedoraproject.org is accessible by the general public but it
isn't meant for the general public's use -- it's for developers to
collaborate on what will be on the production site,
admin.fedoraproject.org. Those developers collaborate over the internet
which is why it's available on the internet. Does this excuse us from
providing source to people who do not have shell access to the server
itself?
* Can we be just as liberal with what's running on the publictest
machines as we are with staging?
.. _[1]: Meeting Minutes
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting...
-Toshio
14 years, 9 months
Re: Cron <root@puppet1> run-parts /etc/cron.hourly
by Stephen John Smoogen
This script was stuck on the fact that hosted1 went down as it was
getting stuff this morning. So it was stopping others from completing.
Killed the git's and ten ran by hand to finish.
On Thu, Jul 16, 2009 at 3:52 PM, Cron Daemon<root(a)fedoraproject.org> wrote:
> /etc/cron.hourly/syncStatic.sh:
>
> /etc/cron.hourly/syncStatic.sh: line 23: 31157 Terminated /usr/bin/git clone git://git.fedorahosted.org/git/fedora-web.git > /dev/null 2>&1
>
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
14 years, 9 months
trac-git-plugin updated on hosted1/2
by Jesse Keating
This is a new upstream snapshot that fixes some of the ongoing issues
we've had with the git plugin. Some were already patched from a
different upstream, but I've had to throw those changes out in favor of
the actual upstream changes. I tested it a bit on hosted2 and couldn't
find any problems, but keep your eye open for any tickets related to git
plugin in hosted.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
14 years, 9 months
Meeting Log - 2009-07-16
by Ricky Zhou
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&status=as...
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&status=as...
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...
14 years, 9 months
About me
by Davi Vercillo C. Garcia
Hi everybody,
My name is Davi Vercillo C. Garcia and I'm from Brazil, Rio de Janeiro
- RJ. I'm 22 years old and I'm a undergraduate student of Computer
Science at Federal University of Rio de Janeiro. I always had
interesting on computers and networking, specially GNU/Linux. I've
used GNU/Linux at my workstations, desktops, notebooks and servers
(off course) since 2001. I started with Slackware and, after it,
Debian, Fedora, RHEL, Mandriva, CentOS, etc. Today, I'm using Fedora
11 (Workstation/Desktop) and RHEL5 (Servers).
I have some basic/intermediate experience with networking, clustering,
system administration and programming (C, Java and Python - my
favourite option). At this moment, I'm trainee on sysadmin at a hpc
lab at my university, called (NACAD) and I'm monitor of basic
programming call for Engineering courses at my university.
I would like to help Fedora community grow and keep moving... (Johnny
Walker ? =P)
PS: My English is not perfect,so please, ignore some mistakes, if it happens.
Thanks,
--
Davi Vercillo Carneiro Garcia
http://www.google.com/profiles/davivercillo
Federal University of Rio de Janeiro
Department of Computer Science
DCC-IM/UFRJ - http://www.dcc.ufrj.br
/"\
\ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML
X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
/ \
14 years, 9 months
Greetings
by Hjörleifur Jónsson
Hi
My name is Hjorleifur I am a 30 year old sysadmin and an avid Linux user
from Iceland currently living in Sweden.
I have been using Redhat/RHEL/FEDORA since Cartman(6.1) and probably every
release since. As well as other Linux Distros, NetBSD,FreeBSD etc.
I have experience in running production environment's for financial
institutions. Past roles I have held are Software developer (c++,vb,vb.net)
on windows ;). DBA Team Leader (Oracle and SQL Server),Infrastructure Team
Leader running VMware VI3 clusters, Linux, Windows, Hpux servers and
various application servers on thees platforms. And recently I have been
experimenting with Opensolaris.
The fields/technology's that interest me most are Cloud computing , clusters
hpc(though I do have not much experience there) and fail over, load balance
and virtualization.
I am interested in helping Fedora move forward and if can help that would
great.
With regards
Hjorleifur
14 years, 9 months
[PATCH] Re-enable rawhide compose.
by Jesse Keating
Massive rawhide for start of F12 finally finished.
Also increase the number of random chars for mktemp and ensure it worked
before continuing.
---
configs/build/rawhide | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configs/build/rawhide b/configs/build/rawhide
index eab9097..4a90bb3 100644
--- a/configs/build/rawhide
+++ b/configs/build/rawhide
@@ -1,3 +1,3 @@
# rawhide compose
MAILTO=jkeating(a)fedoraproject.org
-#15 6 * * * masher TMPDIR=`mktemp -d /tmp/rawhide.XXXXX`; cd $TMPDIR; git clone -n git://git.fedorahosted.org/git/releng; cd releng; git checkout -b rawhide-stable; LANG=en_US.UTF-8 ./scripts/buildrawhide $(date "+\%Y\%m\%d"); sudo -u ftpsync /usr/local/bin/update-fullfilelist fedora
+15 6 * * * masher TMPDIR=`mktemp -d /tmp/rawhide.XXXXXX` && cd $TMPDIR; git clone -n git://git.fedorahosted.org/git/releng; cd releng; git checkout -b rawhide-stable; LANG=en_US.UTF-8 ./scripts/buildrawhide $(date "+\%Y\%m\%d"); sudo -u ftpsync /usr/local/bin/update-fullfilelist fedora
--
1.5.5.6
14 years, 9 months
ASU
by Mike McGrath
anyone know anyone at ASU?
-Mike
14 years, 9 months
