[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
[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:08] mmcgrath: Lets get started.
[15:08] mmcgrath has set the subject to Fedora Infrastructure -- New 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: jcollie: how's publictest1 been treating you with the whole git
[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
[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
[15:16] mmcgrath: does this need to be updated -
[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
[15:17] abadger1999: The requirements section of that page is okay. the rest is not so
[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
[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
[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
[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
[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
[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
[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
[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] 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
[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
[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
[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
[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] mmcgrath: jcollie:
[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
[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
[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.
[15:45] rayvd: heh
[15:45] mmcgrath: RFR's aren't going to get done without people, so lets take step
[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
[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
[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
[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
[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
[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)18.104.22.168.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
[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
[15:59] paulobanon: +1
[15:59] * ricky suspects that most "lack of people" problems stem from little or
[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
[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)22.214.171.124)
[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
[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
[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
[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
[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"
[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
[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
[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
[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