Used DBsize query
by Paulo Santos
Hey guys,
Since yesterday some of you were wondering how much space the DBs were
using, i searched the query that our DBAs use, for that information.
See if this is useful for anyone:
(this requires MySQL5)
SELECT
s.schema_name AS 'Schema',
IFNULL(ROUND((SUM(t.data_length)+SUM(t.index_length)) /1024/1024,2),0.00) AS
'Total Mb',
IFNULL(ROUND(((SUM(t.data_length)+SUM(t.index_length))-SUM(t.data_free
))/1024/1024,2),0.00) AS 'Mb Used',
IFNULL(ROUND(SUM(data_free)/1024/1024,2),0.00) AS 'Mb Free',
IFNULL(ROUND((((SUM(t.data_length)+SUM(t.index_length))-SUM(t.data_free))
/((SUM(t.data_length)+SUM(t.index_length)))*100),2),0)
AS 'Pct Used',
COUNT(table_name) AS Tables
FROM INFORMATION_SCHEMA.SCHEMATA s
LEFT JOIN INFORMATION_SCHEMA.TABLES t ON s.schema_name = t.table_schema
GROUP BY s.schema_name;
I also have one for oracle, much more complete...
Thanks,
Paulo
16 years, 4 months
Voting App Enhancement
by Toshio Kuratomi
If anyone wants to get their feet wet with some very simple python cgi
coding, we have a request to enhance the voting application we've been
using in Fedora::
https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/34
The request is to have a confirmation page after the voter has entered
their vote so they make sure that filled in ballot reflects their ballot
before they hit submit. If it doesn't, they have a button to take them
to a fresh ballot. There's a brief outline of what it would take to
implement -- someone could whip it off in a few spare night of coding,
testing, and debugging (Mostly spent in testing and debugging.)
Also, as noted in that ticket, we really need to have a new voting app
written (probably in TurboGears to take advantage of the work being done
with the rest of our web apps.) If anyone is interested in that, let me
know as well. We currently don't have anyone working on that so you
could definitely leave your mark.
-Toshio
16 years, 4 months
domain list
by Dimitris Glezos
We are trying to collect all the domains we are maintaining at the following
wiki page:
http://fedoraproject.org/wiki/Websites/DomainsList
The purpose is to use Google Webmaster Tools (or any other tool) to track down
our 404s, redirects, search strings, etc.
Please add any domain/system you know we have.
-d
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
16 years, 4 months
Fedora Infrastructure IRC Meeting Log from 2007-07-19
by Jeffrey Ollie
[15:06] mmcgrath has set the subject to Fedora Infrastructue -- Who's here
[15:07] mmcgrath: f13: paulobanon abadger1999 mbonnet quaid warren lmacken ricky xDamox skvidal: ping
[15:07] mmcgrath: who's here?
[15:07] skvidal: pong
[15:07] xDamox: pong
[15:07] mbonnet: mmcgrath: yo
[15:07] abadger1999: pong
[15:07] ricky: pong
[15:07] paulobanon: ping
[15:07] rayvd: here
[15:07] paulobanon:
[15:08] mmcgrath: Lets get started.
[15:08] mmcgrath has set the subject to Fedora Infrastructure -- New schedule - http://fedoraproject.org/wiki/Infrastructure/Schedule
[15:08] mdomsch has joined the group chat (n=mdomsch(a)cpe-70-124-62-55.austin.res.rr.com)
[15:08] mmcgrath: So, I moved a bunch of stuff off of the schedule
[15:08] mmcgrath: http://fedoraproject.org/wiki/Infrastructure/Schedule
[15:09] mmcgrath: Seems like a lot of what we talk about in the meetings is duplicate and a lot of the work is getting done by the relevent parties anyway.
[15:09] mmcgrath: As I mentioned on the list, if you want to talk about a specific ticket, just put "meeting" in the keywords.
[15:10] mmcgrath: Does this sound good or bad to the rest of you?
[15:10] * warren here
[15:10] paulobanon: +1
[15:10] xDamox: Sounds good to me
[15:11] warren: +1
[15:11] abadger1999: Sounds great
[15:11] mmcgrath: K, so I've got a few more items to add to that but just because its bigger issue stuff, don't think you shouldn't add to it.
[15:11] mmcgrath: So for now I'll move on.
[15:11] mmcgrath has set the subject to VCS Choice -- all (jcollie)
[15:11] mmcgrath: jcollie: ping
[15:12] jcollie: yo
[15:12] jcollie: oops we have a meeting don't we
[15:12] mmcgrath:
[15:12] mmcgrath: jcollie: how's publictest1 been treating you with the whole git thing?
[15:12] jcollie: pretty good... nice to have a fast network connection to the cvs servers
[15:13] mmcgrath: jcollie: can you give us an idea of what work you've done and what work you'd like to do?
[15:13] jcollie: however, i'm not sure how much further i want to got with code while the choice of vcs is undecided
[15:13] dgilmore: mmcgrath: /me is here
[15:14] * mmcgrath waves at dgilmore, new board member extraordinaire.
[15:14] jcollie: i think we've all shown that git or hg or svn is capable of doing "something better" than cvs
[15:14] dgilmore: mmcgrath: im just regular joe infrastructure guy
[15:14] mmcgrath: jcollie: well, thats good at least
[15:14] jcollie: personally i think it's time to pick one and roll with it
[15:14] mmcgrath: So the infrastructure team is going to have to push to have this done.
[15:14] mmcgrath: jcollie: do we know what is wanted in the next gen vcs yet?
[15:15] jcollie: i personannly pefer git but i'll work with whatever
[15:15] paulobanon: so start the (final) discussion on the list and decide in a few weeks max ?!
[15:15] mmcgrath: jcollie: would you mind contacting the sig and seeing about setting up an actual meeting for us?
[15:15] abadger1999: jcollie: We need that list of things we want. Proof of concept before absolute requirements is backwards.
[15:15] dgilmore: abadger1999: indeed
[15:15] jcollie: i think that the problem is that no one agrees and tends to favor whatever their favorte
[15:16] dgilmore: proof of concept should show what we want
[15:16] abadger1999: Well, I think the last discussion had some good ideas.
[15:16] abadger1999: But it also had objections.
[15:16] mbonnet: I think someone needs to design a package development/build/release lifecycle that uses the features of the new VCS, and is not doable with current CVS infrastructure.
[15:16] mmcgrath: does this need to be updated - http://fedoraproject.org/wiki/Infrastructure/VersionControl/
[15:16] mbonnet: if we can't show what the clear win of the new VCS is, there's not much point
[15:16] jcollie: i think that page it taking the wrong tack
[15:16] abadger1999: The question is can we meet all of those objections while getting the new features we want.
[15:16] jcollie: to decide pro/con you have to know what you want
[15:17] mmcgrath: jcollie: I tend to agree, looking at that page its clear it was designed in reverse.
[15:17] abadger1999: The requirements section of that page is okay. the rest is not so useful.
[15:17] paulobanon: so are the those requirements all thats needed ?
[15:17] abadger1999: paulobanon: No.
[15:18] jcollie: yeah we should edit out all the vcs comparisions
[15:18] paulobanon: cant we do a proof of concept based on that at least ?
[15:18] abadger1999: paulobanon: We have several proof of concepts based on that but then we started talking about exploded trees.
[15:18] abadger1999: And that changes things considerably.
[15:18] mmcgrath: <nod>
[15:18] paulobanon: hmmm
[15:18] mmcgrath: the issue here is the struggle between whats optimal and whats practical.
[15:18] jcollie: well, all that stuff is basic vcs stuff that can be done by anything
[15:19] mmcgrath: its hard to get people to talk about it without producing something for them to pick at. And its wrong to just make something without requirements.
[15:19] warren: We don't want to follow down the Ubuntu path where they don't make it easy to maintain split-out patches upon upstream, and they don't make it friendly to upstream inclusion.
[15:19] mmcgrath: jcollie: refresh the page.
[15:19] jcollie: yeah that's better
[15:20] jcollie: yeah, i think for now we need to put exploded trees on the back burner
[15:20] abadger1999: Ubuntu did a good job with their proposal page.
[15:20] jcollie: we can solve that problem later
[15:20] mmcgrath: abadger1999: link?
[15:20] jcollie: we should stick with tarballs+patches+spec files
[15:20] abadger1999: https://wiki.ubuntu.com/NoMoreSourcePackages
[15:21] abadger1999: jcollie and I are on a list where an actual implementation of that was discussed recently.
[15:21] mmcgrath: jcollie: I agree.
[15:21] abadger1999: jcollie: I somewhat disagree.
[15:21] jcollie: i like the idea but i think that it would be too radical for the rest of the community
[15:21] mmcgrath: abadger1999: how would you have it done?
[15:21] abadger1999: I think we do need to be able to generate tarball + patch + spec.
[15:22] mmcgrath: jcollie: in fairness though, if anyone is going to be radical... its us
[15:22] abadger1999: But I don't think that exploded trees are too radical.
[15:22] abadger1999: OTOH, I could be wrong
[15:22] mmcgrath: yeah, we can always try it before we buy it.
[15:22] jcollie: i kind of like the idea, it's others in the community that would scream bloody murder
[15:23] mmcgrath: ok, so what is the next step that we need to take?
[15:23] jcollie: it would also force people to become much more intimate with the version control system
[15:23] mmcgrath: finalize the requirements?
[15:23] abadger1999: Right. I think the community is pretty divided over whether that's doable or not.
[15:23] jcollie: yeah
[15:23] jcollie: and then work on a 1/2 scale prototyle
[15:23] xorAxAx has joined the group chat (n=xorAxax@moinmoin/coreteam/alexander)
[15:23] jcollie: er prototype
[15:23] abadger1999: We should probably come up with a few packages which are illustrative of different types.
[15:24] mmcgrath: ytalk, kde, kernel.
[15:24] abadger1999: Something with a ton of patches, soemthing else with one or two.
[15:24] jcollie: that'll mean having a test koji instance
[15:24] * mmcgrath is working on getting a full test environment.
[15:24] abadger1999: Then test out some different styles of management.
[15:24] jcollie: bodhi probably won't be affected much by change of vcs
[15:24] mmcgrath: Ok, just so we don't talk about this one the whole meeting.....
[15:24] mmcgrath: jcollie: what is the next thing you'd like to do with this?
[15:25] jcollie: koji instance
[15:25] mmcgrath: or abadger1999
[15:25] mmcgrath: for what?
[15:25] jcollie: i can come up with some test git repos easy enough
[15:25] jcollie: so that we can test patches to koji for getting packages out of a vcs other than cvs
[15:25] vpv has joined the group chat (i=vpv(a)kapsi.fi)
[15:25] abadger1999: jcollie: Do we need a koji instance? Can we just get to the point where we generate a SRPM from the vcs?
[15:25] xorAxAx: hi vpv
[15:26] abadger1999: If we can do that, then koji can do it as well.
[15:26] mmcgrath: We can always make koji work, I'd rather stay focused on what we want the vcs to do.
[15:26] mbonnet: jcollie: that seems like the last step. How about getting "make tag", "make clog", etc. working with another vcs?
[15:26] jcollie: yeah, but koji talks directly to the vcs
[15:26] mbonnet: jcollie: koji just checks out the sources and calls "make srpm"
[15:26] mmcgrath: but without knowing what the vcs will look like, what good would it do to have koji up and running?
[15:27] jcollie: that can go along in parallel... i dunno how long it's going to take to set up a test koji instance
[15:27] mmcgrath: welll, right now a long time. We don't even have the production koji instance on a box with enough ram yet
[15:27] abadger1999: I'd think a test koji instance will be a bit of pain.
[15:27] jcollie: from what i've seen, there are two basic way that it's going to look
[15:27] mbonnet: I think figuring out how the "common" dir works in other vcs's would be a good thing to look at
[15:28] mbonnet: and the tagging/branching structure
[15:28] abadger1999: So a stub would be better -- koji will grab an srpm from the source chekcout. So we need to get to the point where a source checkout can generate an SRPM.
[15:28] jcollie: i have scripts to produce one kind (looks a lot like we have now) the other kind (exploded tree) will take manually conversion of packages i think
[15:29] abadger1999: jcollie: I think we want to concentrate on the second kind.
[15:29] jcollie: one question that i have, do we really need to maintain the history?
[15:29] jcollie: if not our jobs just became SOOOO much easier
[15:29] mbonnet: I think people will scream bloody murder if we don't
[15:29] jcollie: we can keep CVS around read-only
[15:30] mmcgrath: jcollie: maintain the history of what exactly? upstream sources or our own?
[15:30] jcollie: the CVS history that we have now
[15:30] mbonnet: how hard is it really? git-cvsimport isn't sufficient?
[15:30] mbonnet: for example
[15:30] jcollie: it can get a bit ugly
[15:30] abadger1999: mbonnet: If we're exploding the trees then it might not map exactly...
[15:30] mmcgrath: mbonnet: well, interestingly what if what we come up with doesn't look anything like what the cvs currently is?
[15:30] abadger1999: Because we'll have a nonexploded tree history but everything after improt will be exploded.
[15:31] abadger1999: Maybe we shoould go history-less for the prototype?
[15:31] mmcgrath: jcollie, abadger1999: can one of you guys send an email to the sig and get them back together? We really need to get the group together.
[15:31] jcollie: yeah if we go with exploded trees i'm not sure how you'd really map the cvs history to the new style
[15:31] mmcgrath: otherwise people will call foul about not being involved.
[15:31] mbonnet: mmcgrath: yeah, fair point
[15:31] abadger1999: Since we're really trying to see if the exploded trees can address all the issues the people who don't like it have brought up?
[15:32] mmcgrath: guys? sig?
[15:32] abadger1999: I'll write an email to the sig.
[15:33] abadger1999: I'll ask for a good meeting time on IRC.
[15:33] jcollie: make it to -devel, let's give folks another chance to sign up
[15:33] abadger1999: to discuss what we should put into a prototype of exploded trees.
[15:33] mmcgrath: jcollie: I worry about being to vocal on the lists until we have something concrete because of the noise.
[15:33] mmcgrath: those people get crazy some times
[15:34] jcollie:
[15:34] abadger1999: k. I'll send something a little briefer to the list.
[15:34] jcollie: i'll work on a prototype exploded package repo along the lines of the ubuntu proposal
[15:35] abadger1999: jcollie: Do you want to stick an agenda on the wiki somewhere?
[15:35] jcollie: plus some work on converting the common dir to git
[15:35] jcollie: abadger1999, sure
[15:35] mmcgrath: ok, for now we'll move on.
[15:35] mmcgrath has set the subject to Fedora Infrastructure -- Sponsorship
[15:36] mmcgrath: those in the sysadmin-main group, we need to do a better job about sponsoring other people and projects.
[15:36] mmcgrath: This includes recruiting other members.
[15:36] warren: Package Maintainers have formal requirements for sponsorship
[15:36] warren: do we?
[15:36] mmcgrath: once sponsored package maintainers ignore their sponsors.
[15:36] mmcgrath: and vise versa.
[15:37] warren: sponsors are supposed to be the ones paying attention
[15:37] mmcgrath: "supposed"
[15:37] warren: they are responsible for the people they sponsored screwing up
[15:37] mmcgrath: warren: what are you suggesting?
[15:37] warren: it is a little easier in the case of package maintainers, because all activities (checkins) have mail
[15:37] mmcgrath: our activities, for the most part, have the same email.
[15:38] mmcgrath: but unlike package maintainers, we have a few different groups that people could belong to.
[15:38] warren: mmcgrath, stating the obvious of course, but aside from requirements for sponsorship, the sponsor should be responsible for the education and actions of the sponsored.
[15:38] mmcgrath: none of that does any good if we don't have sponsors though.
[15:38] mmcgrath: our problem is sponsors (sysadmin-main) not getting involved.
[15:39] mmcgrath: there's RFR's sitting out there waiting for people, and a lot of work to get done.
[15:39] mmcgrath: does anyone agree / disagree with that?
[15:39] paulobanon: agree
[15:39] skvidal: <nod>
[15:39] xDamox: agree
[15:39] mmcgrath: so how do we fix it?
[15:40] jcollie: first off who's all in sysadmin-main?
[15:40] kital has joined the group chat (n=Joerg_Si@fedora/kital)
[15:40] paulobanon: only a few
[15:40] rayvd: should RFR's be added to the ticketing system to make them more visible?
[15:40] mmcgrath: we've had a few new members in the last few months and I feel like they've all come to me. Which is fine, I just wish others would take more under their wing.
[15:40] nirik has left (Read error: 110 (Connection timed out) (n=nnnnkevi(a)scrye.com))
[15:41] rayvd: other than my post to the mailing list, not sure how anyone would even be aware of my RFR after a few days go by
[15:41] skvidal: :ausil,damian,jkeating,katzj,lmacken,mikeb,mmcgrath,notting,skvidal,spot,toshio,wtogami
[15:41] mmcgrath: jcollie: https://admin.fedoraproject.org/accounts/dump-group.cgi?group=sysadmin-main
[15:41] notting: hm?
[15:41] ixs: uhhhh. just a simple question: isn't that a bit illusional paying attention to what the sponsored person is doing? Most admins barely manage their own tasks in general, no way they can "monitor" someone else's work.
[15:42] skvidal: ixs: I track what mmcgrath checks in - if only to make sure we don't step on each other's toes
[15:42] mmcgrath: rayvd: it might, but its the rfr's requestor to find a sponsor. Doing it the other way around will never work.
[15:42] abadger1999: rayvd: That's true. There's a gap in the process between wrting RFR and getting RFR sponsored.
[15:42] * xDamox dammit gotta shoot can someone send me the logs
[15:42] mmcgrath: abadger1999: its listed on the RFR page who's job it is to get sponsored... its the requestor.
[15:42] GeroldKa has joined the group chat (n=GeroldKa@fedora/geroldka)
[15:43] ixs: skvidal: if that works, great. I don't know about the infrastructure in place at fedora. But judging by past experience... well, it's basically impossible really looking for mistakes colleagues do as one is busy itself...
[15:43] rayvd: people must not be too interested in sponsoring... or i guess i need to ping people directly.
[15:43] rayvd: which is fine
[15:43] jcollie: yeah, but most everyone posted something to fedora-infrastructure, how much more do they need to do?
[15:43] mmcgrath: RFR's is only one of the problems, we need to grow larger as a group. And to do that sysadmin-main has to start taking on people.
[15:44] jcollie: maybe everyone in sysadmin-main needs to post a link to their amazone wish lists
[15:44] mmcgrath: jcollie: they need to find someone and convince them to get interested.
[15:44] mmcgrath: otherwise its everyone feels like they should get what they want and we can't do everything.
[15:44] mmcgrath: if no one wants to do it, its not going to get done. Which is very open source
[15:45] tibbs has left ("Konversation terminated!" (n=tibbs@fedora/tibbs))
[15:45] paulobanon: can we create a new type in trac, to accomodate RFRs, that way it will have more visibility and they wont get unoticed
[15:45] mmcgrath: ok, so there's two things we're talking about here, RFR's. And people.
[15:45] rayvd: heh
[15:45] mmcgrath: RFR's aren't going to get done without people, so lets take step one.
[15:46] mmcgrath: how do we get more people.
[15:46] mmcgrath: Cattle calls have gone out in the past, had lots of people respond.
[15:46] paulobanon: give visibility to the
[15:46] skvidal: mmcgrath: I have another perspective, though
[15:46] notting: press gangs?
[15:46] paulobanon: notting: heh
[15:46] skvidal: mmcgrath: can we make it possible to do more with what we have?
[15:46] mmcgrath: skvidal: have at it.
[15:46] ixs: notting: won't work. you'll need people who are passionate about that stuff.
[15:46] skvidal: what things keep us from handling rfrs more quickly?
[15:46] skvidal: what are the barriers?
[15:47] mmcgrath: skvidal: people and physical resources.
[15:47] paulobanon: sometimes resources, i would say
[15:47] mmcgrath: and sometimes just bad ideas.
[15:47] skvidal: mmcgrath: people is a function of efficiency, right?
[15:47] mmcgrath: it can be.
[15:47] poelcat has left ( (i=slick@fedora/poelcat))
[15:48] skvidal: well, let me give a couple of examples - it took me far longer than it should have to get fedorapeople setup - some of that was infrastructure and adapting b/c it was outside of the colo
[15:48] skvidal: some of that was me not being as efficient
[15:48] skvidal: but that's just it
[15:48] skvidal: so how much of our issues are ones that can be handled by streamlining xen deployment?
[15:48] jcollie: is there some way to script a "insta-xen-guest"? seems like having a way to quickly set up a basic xen guest would help
[15:48] jcollie: heh jinx
[15:48] skvidal: it's not bad, now
[15:49] skvidal: but as we become more xen/kvm-centric it would be good to get better
[15:49] mmcgrath: skvidal: the xen deployment is about as streamlined as its going to get. Last time I build app1 it took me 5 minutes of work and a 15 minute wait.
[15:49] skvidal: mmcgrath: fair enough - then what's beyond that?
[15:49] paulobanon: we can always, open the sponsorship to sysadmin, and keep the deployment under the sysadmin-main group
[15:49] mmcgrath: having the sysadmin-main people talk to non-sysadmin main people.
[15:49] jcollie: what's the difference between sysadmin and sysadmin-main?
[15:50] mmcgrath: jcollie: shels
[15:50] skvidal: and sudo
[15:50] skvidal: iirc
[15:50] paulobanon: only in some places
[15:50] mmcgrath: skvidal: Trac has helped a lot, and as we move our code into git we will get help there from pepole but we've already had that.
[15:50] paulobanon: im not sysadmin-main, and i have shells and sudo in some of them
[15:50] skvidal: <nod>
[15:50] mmcgrath: a lot of the stuff in the tickets for example are just grunt work that needs to get done.
[15:51] skvidal: agreed
[15:51] mmcgrath: and its not even boring mundain gruntwork, its like, research, engineer a solution grunt work
[15:51] skvidal: but boring gruntwork is quick
[15:51] mmcgrath: it is.
[15:51] skvidal: which is, for me, one of the major points
[15:52] skvidal: if I can stream through 5 things in an hour that's much more enticing than 1 thing for 5 hours of not-quite-progress
[15:52] mmcgrath: but some things take 5 hours.
[15:52] skvidal: absolutely
[15:53] skvidal: I'm just explaining that maybe we're not doing as badly as we think
[15:53] skvidal: we have a lot of stuff to do
[15:53] mmcgrath: ahh, I think we're doing great.
[15:53] skvidal: but we're getting a bunch done
[15:53] mmcgrath: I just think we could be doing better if some of the sysadmin-main people would sponsor others.
[15:53] skvidal: or if we had others to sponsor
[15:54] abadger1999: So maybe the problem here is just sponsorship. If so, what do we need?
[15:54] abadger1999: More sponsors?
[15:54] abadger1999: Clear criteria for when to sponsor someone for which group?
[15:54] mmcgrath: we need the sponsors we have to actually take on people
[15:54] mmcgrath: even if every sponsor just had one, it would be better then what we have now.
[15:55] skvidal: how good are we getting at delegating access to specific tasks?
[15:55] paulobanon: Infrastructure "mentor" program
[15:55] abadger1999: I have two... one of the sponsorees isn't doing anything, though
[15:55] skvidal: s/tasks/servers/
[15:55] mmcgrath: abadger1999: time to kick him out
[15:55] mmcgrath: skvidal: I've been pretty good about it in the past. Especially where research is involved.
[15:56] * rayvd has a work meeting in 5 minutes. should take < 20 mins
[15:56] skvidal: ie: what if sysadmin-main were for spinning out xen instances and large-scale infrastructure pieces
[15:56] skvidal: and we had sysadmin-app1, etc groups
[15:56] skvidal: that people could live in
[15:56] skvidal: off in their own little world
[15:56] mmcgrath: skvidal: we do already.
[15:56] skvidal: then why not subdivide along those lines
[15:56] ke4qqq has joined the group chat (n=chatzill(a)64.89.94.194.nw.nuvox.net)
[15:56] jcollie: maybe what we need to do begin with is to create a xen guest for them and give the requestor root access
[15:56] mmcgrath: we already do, but none of the sysadmin-main people are putting people into those groups.
[15:56] skvidal: jcollie: no
[15:57] skvidal: mmcgrath: ah - then instead of sysadmin-main sponsors we need to delegate better to the subgroups
[15:57] paulobanon: sysadmin-web, etc
[15:57] jcollie: well then how is anyone but someone in sysadmin-main going to get anything done?
[15:57] skvidal: jcollie: letting a developer who wants a 'web server' xen instance have root access is just asking for a rooted box, imo
[15:57] warren: mmcgrath, is it written down anywhere what access exactly giving membership to sysadmin groups enables?
[15:58] warren: mmcgrath, I personally am not sure, and sometimes I don't want to risk it for that reason.
[15:58] mmcgrath: So what I'm hearing is we need a documented process and sub groups?
[15:58] warren: yes
[15:58] warren: and requirements/expectations for the sponsor
[15:58] mmcgrath: and once the process is documented, the sponsors will take on people?
[15:58] warren: (sponsor is responsible for education and actions of the sponsoree)
[15:59] warren: mmcgrath, I don't know, but better to define it and see.
[15:59] abadger1999: yeah. What criteria should there be for me to sponsor Person into group Bar.
[15:59] paulobanon: +1
[15:59] * ricky suspects that most "lack of people" problems stem from little or no documentation.
[15:59] mmcgrath: Ok, I'll start working on that then.
[16:00] abadger1999: Also areas of responsibility -- I am more comfortable sponsoring people who want to help develop something I'm working on a TG app that someone wanting to sysadmin.
[16:00] mmcgrath: abadger1999: you've been pretty good about this btw.
[16:00] mmcgrath: I'm not talking about anyone in particular here, just in general trying to figure out how to grow past the point that we're at right now.
[16:00] mmcgrath: Ok, our time is about up, I'll open the floor right now
[16:01] nihed has joined the group chat (n=nihed(a)41.224.237.251)
[16:01] abadger1999: thanks -- but there have been people you've had to sponsor because they didn't come to me as well...
[16:01] mmcgrath has set the subject to Fedora Infrastructure -- Open floor
[16:01] * paulobanon votes to continue the meeting for an extra 30mins, best meeting ever IMHO
[16:02] paulobanon: Caching
[16:02] abadger1999: skvidal would agree with you:
[16:02] abadger1999: (01:06:58 PM) ***skvidal loves meetings
[16:02] abadger1999: (01:07:00 PM) skvidal: yay meetings!
[16:02] skvidal: whoops
[16:02] skvidal: I forgot to close the tag
[16:02] skvidal: </sarcasm>
[16:02] skvidal: there you go
[16:02] mmcgrath: we can keep going if you guys want?
[16:02] abadger1999: paulobanon: Did you have something serious to say about caching?
[16:02] paulobanon: yup
[16:02] jcollie: i thought that #fedora-admin was an endless meeting
[16:02] vpv: rayvd wanted to say something about the Moin RFRs but he's away right now...
[16:03] paulobanon: what are we looking for while caching in the proxies
[16:03] mmcgrath: thats true
[16:03] mmcgrath: rayvd: ping?
[16:03] drago01: "rayvd has a work meeting in 5 minutes. should take < 20 mins"
[16:04] mmcgrath: doah.
[16:04] mmcgrath: k.
[16:04] mmcgrath: should we continue this disussion in #fedora-admin?
[16:04] rdieter has left (Remote closed the connection (n=rdieter(a)sting.unl.edu))
[16:04] paulobanon: why not
[16:04] abadger1999: Sounds good.
[16:04] vpv: basically the point is, we would really appreciate the resources for the two Moin projects
[16:04] vpv: but we can definitely talk about this on -admin
[16:04] jcollie: can moin be run standalone as a user?
[16:05] vpv: yes
[16:05] jcollie: say, on port 8080?
[16:05] bpepple has left ("Ex-Chat" (n=bpepple(a)adsl-75-42-221-131.dsl.wotnoh.sbcglobal.net))
[16:05] jcollie: why not use publictest1 then?
[16:05] vpv: yes, that's exactly how I'm doing it on my development machine
[16:05] jcollie: set things up so that the "live" moin content can be rsync'd to publictest1
[16:06] vpv: but me and rayvd, we need to run different versions
[16:06] mmcgrath: vpv: you should be able to run localized versions of moin independently. we've done that before (though it was scary
[16:06] jcollie: yeah, just run it out of a hg checkout in your home directory
[16:06] vpv: that shouldn't be a problem, if we could run our on 8080 and 8081 or whatnot
[16:07] jcollie: just make sure that publictest1 has enough disk space
[16:07] abadger1999: rayvd's RFR needs python2.5... So it needs to be an F7 base
[16:07] mmcgrath: we can always add space to publictest1.
[16:08] jcollie: hmm publictest1 is a fc6 system
[16:08] abadger1999: Unless he's already finished his profiling and is going to do some coding now.
[16:08] bpepple has joined the group chat (n=bpepple(a)adsl-75-42-221-131.dsl.wotnoh.sbcglobal.net)
[16:08] mmcgrath: abadger1999: just curious, if he needs python2.5... what good will it do us since we're running moin in 2.4 environment?
[16:08] jcollie: yeah but you need to keep doing the profiling to know if you're making progress
[16:09] * mmcgrath notes thats a reason to find a sponsor to help coordinate that stuff
[16:09] jcollie: iirc python2.5 is just for the profiling
[16:10] mmcgrath: ok, we should really close the meeting and head over to #fedora-admin to discuss the sponsorship thing.
[16:10] mmcgrath: vpv can you bring this up at the next meeting?
[16:10] mmcgrath: normally they don't run long like this
[16:10] paulobanon: VCS is a big thing...
[16:10] vpv: mmcgrath: hopefully, if I can be here then
[16:10] paulobanon: its a monster!
[16:10] mmcgrath: Ok, if no one has anything else we'll close in 30
[16:12] mmcgrath has set the subject to Meeting Closed
16 years, 4 months
Meeting Tomorrow
by Mike McGrath
I've moved all of the schedule items off to the ticket system. If you'd
like to discuss your ticket in the meeting add the word "meeting" to the
keywords section of your ticket. The schedule from now on will be more
about some of the big picture items. (Though currently its blank. I'll
fill some out before the meeting tomorrow) Additionally feel free to add
things yourself.
http://fedoraproject.org/wiki/Infrastructure/Schedule
-Mike
16 years, 4 months
fedorapeople.org is now available
by Seth Vidal
Hi Everyone,
fedorapeople.org is now available for general use.
What is fedorapeople.org?:
It is a site where fedora contributors can upload files for sharing
out with the world. It is perfect for uploading specfiles, srpms,
patches, etc, etc. Each fedora contributor has 150M of quota-controlled
space. Users can upload using scp, sftp or rsync. Once uploaded into the
users public_html directory the files are available via http at:
http://your_username.fedorapeople.org/. To connect to fedorapeople.org
just use the ssh key you uploaded to your fedora account and then you
can login via ssh to: fedorapeople.org
What fedorapeople.org is NOT:
- it is not a place for you to upload confidential or
copyright-violating files.
- it is not a shell for you to login and stay logged into
- it is not a place for you to run your favorite proxy of whatever kind
- it is not a database server
- it is not a mail server
- it is not a run-my-favorite-cgi-server
- it is not a blog server
We've tried our best to minimize and secure the services. Don't make a
lot of unreasonable requests asking for us to undo that. :)
For reasonable requests please file put them in the fedora
infrastructure ticketing system:
http://fedoraproject.org/wiki/Infrastructure/Tickets
Let us know what breaks,
-sv
16 years, 4 months
