Re: Configuration Management SCM
On Sun, 2007-03-11 at 22:02 -0500, Mike McGrath wrote: > I'm ready to deploy the configs with puppet. Should we continue to use > CVS, upgrade to SVN or try to use something like hg (even though a > distributed SCM would have more negatives than positives IMHO for our > infrastructure. > > /me doesn't care, but does generally dislike cvs. One thing that has really bothered me lately about SVN is the lack of merge tracking. In an attempt to learn more about hg/git I've tried converting various SVN repos that I use to hg or git. It's very difficult to reconstruct the merge history (you basically have to guess/use heursitics based on log messages). So even though we wouldn't necessarily use the full "distributedness" of hg or git I'd say let's start with a SCM that's going to keep track of this sort of thing. Oh... I just thought of one way in which we might make use of the a distributed SCM to manage the Puppet configs. Someone who has some puppet/sysadmin skills, but who hasn't necessarily earned the trust yet to be given root access could contribute to the task of administering the Fedora infrastructure by checking out the Puppet configs, producing a patch and having it reviewed by the group. If the patch passes muster, one of the "core" admins would merge the patch into the Puppet config repository. Hopefully there wouldn't be any passwords store in the Puppet configs :). As to hg vs. git, I say let Mike pick his favorite and the rest of us will learn to deal with it. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Configuration Management SCM
On Sun, 2007-03-11 at 20:36 -0700, Ask Bjørn Hansen wrote: > > On Mar 11, 2007, at 8:19 PM, Jeffrey C. Ollie wrote: > > > One thing that has really bothered me lately about SVN is the lack of > > merge tracking. > > It's coming -- either in 1.5 or 1.6. > > Until then, svnmerge.py is a very good add-on for managing branches, > http://www.orcaware.com/svn/wiki/Svnmerge.py Yes, I've used it before. It's a useful tool if you are doing a lot of branching/merging in SVN (and can't switch to something else or can't wait for a version of SVN that supports merge tracking). Unfortunately, since it's not "built in" to SVN it either doesn't get used by a project or doesn't get used consistently (or correctly) by the developers. Also, since it's not built in, I doubt that there is support for it in other tools, for example gitk (for git) or hgk (for hg) can give you a graphical display of the merge history. My point is, that since we're starting this code repository from scratch, let's start with a SCM that already supports merge tracking natively. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Testers needed: mirrormanager
On Tue, 2007-03-13 at 12:47 -0500, Matt Domsch wrote: > > At this point, I'm looking for volunteers to try out the site, enter > their data, and let me know if something causes a python backtrace and > what you did to get there. My goal is to shake enough bugs out that > it can be used *LIVE* for the Fedora 7 launch. https://admin.fedoraproject.org/mirrormanager/publiclist/2/2 Gives me a 404 (linked from https://admin.fedoraproject.org/mirrormanager/publiclist/) Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Smolt I18N
I've started working on internationalization for Smolt. It's not ready to commit to the main smolt repository, as it's not complete and I'm sure I've committed some boneheaded mistakes because I've never done any internationalizing of code before. I've set up a separate Mercurial repository here. You can access it through the web here: http://hg.ocjtech.us/smolt-i18n or check out a copy of the code: hg clone http://hg.ocjtech.us/smolt-i18n Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Multiple CLA Implementation
On Thu, 2007-03-29 at 15:55 -0400, Warren Togami wrote:
> One Time Changes
>
> 1) Existing cla_done is cloned to fedora_cla.
> 2) dell_cla group is created, Matt adds whoever he wants. Remove
> dell_cla members from fedora_cla.
> 3) redhat_cla group is created, populated through various means.
> 4) Modify existing Fedora CLA signing process to join fedora_cla instead
> of cla_done.
So without ever having looked at the FAS schema before today, and never
having tested this code, I think that this will clone the cla_done to
fedora_cla and create the dell_cla and redhat_cla groups...
insert into project_group
(name, owner_id, group_type)
values
('fedora_cla',
(SELECT id FROM person WHERE username = 'admin'),
'tracker');
insert into project_group
(name, owner_id, group_type)
values
('redhat_cla',
(SELECT id FROM person WHERE username = 'wtogami'),
'tracker');
insert into project_group
(name, owner_id, group_type)
values
('dell_cla',
(SELECT id FROM person WHERE username = 'admin'),
'tracker');
insert into role
(person_id, project_group_id, role_type,
role_domain, role_status, internal_comments,
sponsor_id, creation, approval)
values
(select a.person_id, b.id, a.role_type,
a.role_domain, a.role_status, a.internal_comments,
a.sponsor_id, a.creation, a.approval)
from
role a, project_group b
where
a.project_group_id is (select id from project_group where name =
'cla_done') and
b.id is (select id from project_group where name = 'fedora_cla');
signature.asc
Description: This is a digitally signed message part
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: svn.fedoraproject.org instance for Certificate System
On Fri, 2007-05-25 at 10:44 -0700, Margaret Lum wrote: > > > > Project Info > > Project Name: Certificate System > > Target Audience: folks interested in Open Source PKI software > > Expiration Date (required): indefinite > > Description/Summary: This project is an enterprise-class Open Source > > Certificate System for Linux, supporting certificate management, key > > archival, OCSP support and smartcard life-cycle management. Since this is for code, wouldn't this make more sense as a hosted.fedoraproject.org project? Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
RFR: GIT Package VCS
With F8T1 fast approaching (it's currently scheduled to be released on 1 August 2007) we need to get cracking on a new VCS system. I've been working on converting the CVS repositories to GIT on some spare hardware that I've had laying around. I think that it's at a stage where input & testing from the community is needed to move the project forward. Therefore I'd like to request a test Xen host to move the repository over: http://fedoraproject.org/wiki/Infrastructure/RFR/GitPackageVCS More information about the repository I've been setting up can be found here: http://fedoraproject.org/wiki/JeffOllie/VCS/Git Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
On Wed, 2007-06-06 at 10:44 -0400, Jeremy Katz wrote: > On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > On Wed, 2007-06-06 at 09:17 -0500, Mike McGrath wrote: > > > I'm glad this is started back up. One thing that amuses me is back > > > before the F7 launch it almost seemed assured that we would all go with > > > mercurial. This line isn't so clear now, a lot of people have been > > > using git. It seems our future is either going to be A) do nothing and > > > continue with CVS or B) move to HG or Git. > > > > Yeah, definitely time to start this back up. > > And just to make things clear, it's time to start up talking about it, > investigating our options and getting some things rolling. But that > _doesn't_ mean we should rush things to just get them done based on an > arbitrary deadline. This is the sort of thing we're going to have to > live with for a long while, so it's better to have it take an extra > release cycle before rolling out and get it right. Otherwise, we'll > have a revolt on our hands :-) I agree and I disagree. Yes, we need to carefully consider our next step. On the other hand I think that we need to get off of CVS as soon as possible. From what I've seen while testing the conversion to GIT there seems to be corruption in some of the CVS repositories. It's most noticeable in large/active packages (the kernel is a notable example) but sometime small packages are affected. I don't think that it's had a major effect so far because I think that it's relatively rare that people go back and look at old revisions of the packages (probably because that's so difficult in CVS). You can see the effect of the corruption in my git repos thusly: git clone git://161.210.6.204/kernel cd kernel gitk devel origin/FC-6 If you scroll down (way way down) you'll see that the history of the FC-6 branch diverges much much sooner than it should at: 66b7d75c65cfc08a513b7e3a51b9e9661c79f793 2005-08-18 2.6.13-rc6-git10 rather than at: a81d311b742ee08174abb017b6b0caabaa369867 2006-10-12 Initialize branch FC-6 for kernel Compare that with: gitk devel origin/F-7 where you can see the histories diverge at: 80cedc3f9b0705ef0e38565d69869d7871c5c8b8 2007-05-18 Initialize branch F-7 for kernel Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
On Wed, 2007-06-06 at 13:50 -0400, Christopher Blizzard wrote: > On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > > > Right. I really don't think we want to just take our current system, > > switch out CVS, and end up with all of the same workflows. The change > > should be more about how do we improve workflows. That means thinking > > about things like: > > * How do we make it easier for a maintainer to rebase their package to > > a > > newer upstream? > > * How do we make it easier for a maintainer to develop, test, and > > create > > a patch to fix a problem that's being experienced in Fedora? > > * How do we make it easy to send these patches to the upstream of the > > project being worked on? > > * How do we enable downstreams to take our bits, track them and make > > changes as they need/want? > > * How do we better enable a user who has a problem with something we > > ship to be able to fix it themselves and get the fix back to us? > > > > Awesome stuff. This is the right way to go about the conversation, for > sure. I would love to add some stuff to this list: > > o How do we bring developers and consumers of technology closer > together? In a less market-ey speak way to put it: how do we let > software developers (not just maintainers!) get directly involved and > let them deal directly with the people who want to use it without the > maintainer as a mediator? > > o How do we deal with _more than just RPMs_ as a build and delivery > mechanism. (Trust me, this is coming.) > > o Do we want to move to a process where code is just in a repo and it's > built automatically instead of source + patches + spec file? When I first read these two posts, I thought "you guys are crazy", but then I thought about it a bit more and started thinking "Whoah! This could be really cool!" I think what is described here could certainly be done with Git (it'd probably work in another distributed SCM but I'm less famililar with those so I can't say for sure). It also occurred to me that this would be a very big change in how we manage packages so maybe some kind of hybrid approach would make the transition easier. So what about something like this: 1. We convert the package repository to a new SCM so that we can get off of CVS, but the process/workflow remains relatively unchanged. This I think that we could definitely have in place by F8. 2. We set up a parallel package repository that enables our new workflow. When a package maintainer is ready to move a package to the new workflow, building from the old-style repository is disabled and the package is built from the new-style one. > Also, we need to think in use cases instead of abstract questions or > about what technology we can use. For example: > > "A developer has made a patch that he thinks fixes a bug for one of his > users. He mails the user and says "here's a pointer to the patch - just > click on this button to try a build on your system." > > One of my goals that I've had for Fedora, one that's easy to understand > is, "one click to try any patch." > > What's required to make that happen? Realistically we probably need to > move to a source control system so that when the developer commits (or > is pushed in the git sense) the tag with that commit or change is > available to apply. Then the build system can just pull that tag, build > it and make it available to the user automatically. I think that this is more of a Web UI issue rather than a SCM issue. Koji will already build a package based upon a tag in CVS, it wouldn't take a lot of work to extend that to GIT or some other SCM (example patches for SVN are available in a ticket on Koji's bug tracker). What you would need is a Web UI that would: 1. Let users browse the packages and tags that are available in the SCM. 2. Or users could be directed to a particular package/tag by posting a link in bugzilla/mailing list post. 3. Be able to click on a button to request a build from Koji for a particular package/tag/release/arch. Since the build is going to take some time, users would need to supply an email address where a notification would be sent with a link to download the resulting packages. These packages would be cached for a while in case other people wanted to try out those packages as well. Packages built in this fashion wouldn't become part of rawhide or an update to a released package - that would still require action by the maintainer. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
IRC Log for Fedora Infrastructure Meeting (2007-06-14)
[15:06] mmcgrath has set the subject to fedora-infrastructure meeting -- Who's
here?
[15:06] xDamox: Me
[15:06] mmcgrath: PING ALL: who's here?
[15:06] G: I'm here
[15:06] mbonnet: yo
[15:06] cemc has joined the group chat ([EMAIL PROTECTED])
[15:06] G: I'm gonna have to disappear in 15-20
[15:06] jcollie: howdy!
[15:06] f13: I'm here.
[15:06] mmcgrath: abadger1999: you around?
[15:06] abadger1999: Yep.
[15:06] mmcgrath: allrighty then
[15:07] * lmacken !
[15:07] * wolfy grabs a viewing seat
[15:07] mmcgrath has set the subject to abadger1999 - Package Database
-
[15:07] mmcgrath: abadger1999: whats the word?
[15:07] abadger1999: We have progress
[15:07] abadger1999: Script to import pkgs is written and I'm finding all sorts
of problem with owners.list.
[15:08] mmcgrath: thats good at least
[15:08] mmcgrath: how bad is it?
[15:08] abadger1999: Mostly lack of EPEL owner information for EPEL branches
[15:08] lmacken: abadger1999: is there an owners API yet? If not, want some
help?
[15:08] abadger1999: lmacken: I'm using nottings owners.py.
[15:09] lmacken: abadger1999: ah, where does that code live ?
[15:09] lmacken: maybe i can stuff that into bodhi in the mean time
[15:09] abadger1999: Since the pkgdb will get rid of owners.list I'm not too
worried about an API.
[15:09] G: abadger1999: in that case dgilmore would be the person to poke I
think
[15:09] glezos has joined the group chat ([EMAIL PROTECTED]/glezos)
[15:09] lmacken: well, bodhi needs to know who owns what
[15:09] abadger1999: cvs-int:/cvs/extras/CVSROOT/admin/owners.py
[15:09] lmacken: thanks
[15:09] mmcgrath: abadger1999: if you do get together a comprehensive list of
stuff missing from EPEL send it my way.
[15:09] abadger1999: I have a few changes to what's checked in that I'll have
to add later.
[15:10] abadger1999: Will do.
[15:10] abadger1999: warren is going to work on koji syncing.
[15:10] tibbs has left ("Konversation terminated!" ([EMAIL PROTECTED]/tibbs))
[15:10] abadger1999: I'm going to do bugzilla sync and cvs acls sync this week.
[15:10] abadger1999: G (Nigel Jones) has started looking at the code and made
some changes to the way it looks.
[15:11] mmcgrath: cool
[15:11] G: (Minor to start with, just getting to grips with Turbogears and how
it works)
[15:11] abadger1999: So we're on track for next week or the week after.
[15:11] mmcgrath: abadger1999: anything else?
[15:11] abadger1999: That's about it.
[15:11] mmcgrath: abadger1999: the package db only contacts the database,
correct? Does it need any write access to a file system like koji or cvs?
[15:12] MrBawb has joined the group chat ([EMAIL PROTECTED])
[15:12] abadger1999: i think cvs acls can pull from the packagedb for now
instead of pkgdb pushing to cvs-int.
[15:12] abadger1999: koji I'm not sure about. warren's looking into it.
[15:13] mmcgrath: cool.
[15:13] mmcgrath: pull is better than push for security reasons.
[15:13] mmcgrath: same reason bodhi is deployed on app5 instead of in our
cluster.
[15:13] warren: you rather koji pull from packagedb?
[15:13] mbonnet: that's not really possible
[15:13] mbonnet: unless we have a cronjob that does the sync periodically
[15:13] mmcgrath: warren: if its filesystem stuff, yes. if its db stuff then
no.
[15:14] warren: abadger1999, it is all db right?
[15:14] abadger1999: mbonnet: How do you currently sync owners.list?
[15:14] warren: abadger1999, see /cvs/pkgs/CVSROOT/admin/owners-sync.py
[15:14] mbonnet: I believe the script is run by hand right now
[15:14] f13: yes, by hand
[15:15] * dgilmore is here
[15:15] f13: when we make changes to owners.list we run the sync script
[15:15] f13: less than ideal, but functional
[15:15] mmcgrath:
[15:15] abadger1999: Hmm... Is it just pushing into koji's db?
[15:15] dgilmore: abadger1999: EPEL owner information is in owners.epel.list
[15:16] abadger1999: if so it can be a cronjob or we can write a callback that
pushes the information from the package db to koji when it's updated.
[15:16] rdieter has left (Remote closed the connection ([EMAIL PROTECTED]))
[15:17] mmcgrath: abadger1999: we can figure it out. We should move on for the
meeting though.
[15:17] f13: abadger1999: it uses the koji API to do ownership adds/changes.
[15:17] f13: doesn't talk to the db directly
[15:17] abadger1999: f13: Sounds like it won't be a problem then.
[15:17] abadger1999: mmcgrath: And won't need to write to any filesystems.
[15:17] mmcgrath: abadger1999: excellent
[15:17] mmcgrath: k, moving on
[15:18] mmcgrath has set the subject to Config Management - mmcgrath
[15:18] mmcgrath: nothing majorly new here. I'm going through and making sure
our xen dom0's are setup properly.
[15:18] mmcgrath: I've also started forcing some packages to uninstall and some
services not to start (cups, gpm, etc)
[15:18] mmcgrath has set the subject to VCS - jcollie
[15:18] mmcgrath: jcollie: ping?
[15:18] jcollie: yo
[15:19] mmcgrath: jcollie: Are you still playing with VCS solutions?
[15:19] jc
Re: Fedora Magazine RFR
On Mon, 2007-06-18 at 14:08 -0400, Seth Vidal wrote: > On Mon, 18 Jun 2007, Stephen John Smoogen wrote: > > > I would like to add a +1 on this. > > > > Listen I realize that having flash will enhance how it is perceived > > and will allow more editorial control on layout. However, it would > > seem to undercut the core message of Fedora == Freedom. If you have to > > use propietary authoring controls to create that message... you have > > weakened the message. > > > > Until gnash (or something equivalnet) is shipped core in Fedora.. I > > would be concerned that any official Fedora product should be able to > > be used with only a Core product. > > +10. > > And let's not even START about the section 508 and flash issues. > > seriously, friends don't let friends use flash. A lot of what Flash can do can be done in SVG if you have a modern browser (FF 1.5+, dunno about the status of IE). Recently Nicu Buculei posted a demonstration web site done entirely in SVG[1]. Not that I'd really recommend it though, but it shows the power of SVG. The Totem Mozilla plugin does an excellent job of displaying embedded video as well. Even if gnash or swfdec become part of Fedora, they will always be playing "catch up" with a proprietary standard controlled by a commercial company. [1] http://nicubunu.blogspot.com/2007/06/authoring-svg-websites-with-inkscape.html Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Mon, 2007-06-18 at 21:04 +0200, Paulo Santos wrote: > +1 on the cleanup > > Regarding, changing the actually SCM, do we need anything that CVS > doesnt offer ? > If we do, then lets discuss options, if we dont, then let's stick with > it. Other than the fact that CVS sucks? Git would be my preference, Mercurial I could live with. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Tue, 2007-06-19 at 00:37 -0500, David Douthitt wrote: > Anand Capur wrote: > > It has the pros/cons of CVS, Subversion, Mercurial, Bazaar-ng, and > > git, also what we need in a system. > I vote for Subversion - just from the standpoint that many people will > know how to use it, and supporting it will be easier and finding people > to support it will be just as easy. Unfortunately, Subversion has two of the flaws that CVS has: 1) Merging is hard. 2) It's requires a centralized model of development that splits people into "committers" and everyone else. Non-committers have a much more difficult time contributing. Using a distributed SCM makes it much easier for people without write access to the main repository to contribute. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Tue, 2007-06-19 at 16:01 -0400, Jesse Keating wrote: > On Tuesday 19 June 2007 11:32:54 Mike McGrath wrote: > > 1) Modular ACL > > 2) email notification > > 3) Tagging > > 4) Anonymous read/check outs > > > > > > Can anyone think of anything else? > > I'd really like there to be offline support in a manner that allows > non-commiters to be able to clone, modify, and provide a repo back to us that > we can pull from. I'd like that as well. I've had the problem on a few occasions of wanting to submit a patch to a project, but Subversion was incapable of producing a patch that would reproduce what I wanted on the maintainer's systems. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 21:20 -0400, Christopher Blizzard wrote: > On Wed, 2007-06-20 at 16:06 -0400, Michael DeHaan wrote: > > > > However it does rely on the accessibility of those upstream repos. > > Shouldn't be a major issue. If it's down, no updates. > > Trust me when I say you don't want to do this. You always want to have a > local copy. For OLPC we have a jhbuild script that used to pull from a > lot of different repos and someone was _always_ down. We want coupling, > but we want it to be loose coupling. Yeah, just think SourceForge CVS... Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora Infrastructure IRC Meeting Log from 2007-06-21
[15:01] mmcgrath has set the subject to Fedora Infrastructure -- Who's here? [15:01] mmcgrath: Alrighty everyone. Who's here? [15:01] * abadger1999 is here [15:01] * skvidal is here [15:01] * xDamox is here [15:01] abadger1999 has left ( ([EMAIL PROTECTED])) [15:01] abadger1999 has joined the group chat ([EMAIL PROTECTED]) [15:02] mmcgrath: dgilmore: f13: ping? [15:02] * G is reattached [15:02] mmcgrath: Allrighty, lets get started. [15:02] jcollie: here! [15:02] mmcgrath has set the subject to Package Database -- abadger1999 [15:02] * riczho listens again. [15:02] mmcgrath: jcollie: yo [15:02] f13: here [15:02] f13: battling rawhide still [15:02] notting has joined the group chat ([EMAIL PROTECTED]/notting) [15:03] abadger1999: We're close [15:03] abadger1999: I have the importer almost done. [15:03] abadger1999: Had a late feature request from jeremy that I'm working on now. [15:03] * rordway is here for once [15:03] abadger1999: bz-sync is ~ half done. [15:03] jcollie: i think that we should all pitch in to buy f13 some authentic leather chaps for when he's dealing with rawhide [15:03] * jeremy is nothing but a trouble maker [15:03] mmcgrath: abadger1999: if you get sucked into feature creep, don't forget you can say no [15:03] abadger1999: warren hasn't had a chance to work on the koji sync so I may have to pick that up. [15:04] mmcgrath: well for now anyway [15:04] mmcgrath: abadger1999: so all in all you think we're in good shape? [15:04] f13: wow. [15:04] abadger1999: And I need to work out exactly what scripts need to be ported for new packages and package branches. [15:04] abadger1999: That should be it. [15:04] mmcgrath: when do you suspect we'll be able to promote it? [15:04] f13: jcollie: between you and jwb I'm wearing pasties and leather chaps. [15:04] f13: I'm deeply frightened. [15:05] * rordway hides his eyes [15:05] jwb: gah, scary [15:05] abadger1999: I'm hoping we can deploy it for cvsadmins to use next week. [15:05] * skvidal hides his brain [15:05] abadger1999: And then let the public start self-serving afte rthat. [15:05] mmcgrath: excellent. [15:05] mmcgrath: abadger1999: did we get the python-fedora timeout issue figured out? [15:05] abadger1999: Nope. I'm still looking for it. [15:05] craigt has joined the group chat ([EMAIL PROTECTED]) [15:06] mmcgrath: k [15:06] mmcgrath: abadger1999: anything else then? [15:06] abadger1999: I know that it's something involved with deep TurboGears stuff. [15:06] abadger1999: But beyond that [15:06] abadger1999: (Session cookie is being lost or something.) [15:06] mmcgrath: [15:06] abadger1999: That's it. [15:06] mmcgrath: cool [15:07] mmcgrath has set the subject to config management -- mmcgrath [15:07] mmcgrath: So puppet (i think) and RHN have started to conflict. [15:07] mmcgrath: I'm looking into it more. [15:07] skvidal: mmcgrath: put in some 'sleep 10' [15:07] mmcgrath: basically we're getting this - http://pastebin.ca/581690 [15:07] mmcgrath: Which I think is a 24 hour period average. [15:08] mmcgrath: something to keep an eye on though. [15:08] mmcgrath has set the subject to VCS choice -- abadger1999/jcollie [15:09] mmcgrath: So the conversation on what Infrastructure should use for its SCM kind of went crazy. Does anyone have any opinions that have not been discussed on the list? [15:09] jcollie: i think we defiitely need to go to a dscm... which one is up for debate [15:09] f13: lets do like puppet [15:09] abadger1999: What about the consolidate small projects into one hosted project idea? [15:09] f13: pick git, run with it. People will deal. [15:09] skvidal: f13: break rhn? [15:10] mmcgrath: abadger1999: thats not a bad idea really. I'd worry about Infrastructure having two homes though. [15:10] abadger1999: Hmm.. That's true. [15:10] mmcgrath: having said that, I'd be up for examining using trac's bug system as a replacement for OTRS. [15:10] * mmcgrath notes that we really haven't picked up and used OTRS. [15:10] f13: Trac does have the concept of a 'task' vs a bug [15:11] f13: well really, it has the concept of whatever kind of ticket we want to teach it [15:11] * dgilmore is here [15:11] jcollie: can trac create new tickets based upon an email? [15:11] * riczho doesn't particularly enjoy OTRS either. [15:11] mmcgrath: f13: the defaults look like "defect" "enhancement" "task" [15:12] mmcgrath: riczho: I think its just a bit of an overkill for what we need. [15:12] f13: jcollie: not sure. Maybe, may require some more advanced setup on the track host [15:12] f13: mmcgrath: yeah, the webadmin tab lets you create/remove ticket types at will. [15:12] mmcgrath: excellent, well lets discuss this then [15:12] jcollie: what about using bugzilla.redhat.com? i know it's the bugtracker we all love to hate but it'll keep things simpler [15:12] f13: or completely remove the ability to have tickets in that particular Trac instance [15:12] G: can't we just use a dumbed down version of Mantis, or a new Bugzilla 'Proje
Fedora Infrastructure IRC Meeting Log from 2007-06-28
[15:01] mmcgrath has set the subject to Fedora Infrastructure -- Who's here [15:01] mmcgrath: ping all, who's here? [15:01] * skvidal is here [15:02] * xDamox is here [15:02] * Bob-Laptop is not here but does not really count yet [15:02] mmcgrath: paulobanon, dgilmore, mbonnet__, mbonnet, abadger1999, f13: ping [15:02] * paulobanon is here [15:03] notting has joined the group chat ([EMAIL PROTECTED]/notting) [15:03] * abadger1999 is here [15:03] mmcgrath: allright [15:04] mmcgrath has set the subject to Fedora Infrastructure -- Ticketing System [15:04] mmcgrath: Lets talk about this and try to come to a conclusion today. [15:04] * mmcgrath notes the schedule - http://fedoraproject.org/wiki/Infrastructure/Schedule [15:04] mmcgrath: So here's my current concern. [15:04] mmcgrath: I'm getting a lot of emails for requests for stuff that anyone in the team could do. [15:05] mmcgrath: So as we discussed on the list the options are moving to a mailing list or trac. [15:05] mmcgrath: What do you guys think? (you don't have to be in the Infrastructure team to have a comment on this) [15:05] paulobanon: trac for me [15:06] skvidal: I can adapt to either - I think a list is easy - but if there's an rss feed for trac I'll accept that [15:06] mmcgrath: skvidal: good question. [15:06] mmcgrath: f13: does track have an rss feeder? [15:07] * mmcgrath thinks f13 is away. [15:07] skvidal: Indeed [15:07] abadger1999: trac has an rss feed for timeline. Not sure if tickets show up in timeline or not. [15:07] paulobanon: http://trac.edgewall.org/wiki/TracRss [15:07] mmcgrath: abadger1999: are you a trac fan or a mail list fan? [15:08] paulobanon: yes it support tickets [15:08] abadger1999: We need to have both a ml and ticketing system. [15:09] mmcgrath: k, so I'll work on getting a trac system setup and properly configured with Infrastructure for us to take a look at. We can decide to keep it and announce it hopefully next week. [15:09] paulobanon: sounds good [15:10] mmcgrath: ok, moving on. [15:10] mmcgrath has set the subject to Fedora Infrastructure -- Package Database [15:10] mmcgrath: abadger1999: how are you and G doing? [15:11] G: I've been a little bit on hold, I've got next week off, so I hope to dedicate a bit of time to it [15:11] mmcgrath: G: cool. [15:11] mmcgrath: G: where are you two currently running tests from? [15:12] G: Toshio created a hosted instance though (http://hosted.fedoraproject.org/projects/packagedb [15:12] G: err. test3 I think [15:12] mmcgrath: test3, k. [15:12] mmcgrath: k, moving on. [15:13] mmcgrath: Nothing new in configuration managemnt. [15:13] mmcgrath has set the subject to Fedora Infrastructure -- VCS choice [15:13] mmcgrath: jcollie: ping [15:13] jcollie: mmcgrath, wassup? [15:13] jcollie: oops [15:14] mmcgrath: I'm going to have some publictest1 space for you soon for http://fedoraproject.org/wiki/Infrastructure/RFR/GitPackageVCS [15:14] jcollie: on a phone call, but no progress since last week [15:14] jcollie: mmcgrath, thanks! [15:14] mmcgrath: jcollie: k, can you apply for the sysadmin-test group when you get a mment? [15:14] jcollie: sure [15:14] * mmcgrath will continue [15:15] mmcgrath has set the subject to Fedora Infrastructure -- Firewall system rewrite [15:15] mmcgrath: xDamox: how's all that going? [15:15] mmcgrath: and the new custom rules? [15:15] xDamox: mmcgrath, just got to get skvidal to check over this torrent policy [15:15] skvidal: xDamox: I did check it over [15:15] skvidal: is there a new one? [15:15] xDamox: the one in my home dir? [15:16] xDamox: on lockbox [15:16] abadger1991 has joined the group chat ([EMAIL PROTECTED]) [15:16] riel has joined the group chat ([EMAIL PROTECTED]) [15:16] skvidal: did you tell me about those before today? [15:16] skvidal: I looked at what we talked about before [15:16] xDamox: nope [15:16] skvidal: oh, okay [15:16] xDamox: I was going to email you tonight [15:17] MrBawb has joined the group chat ([EMAIL PROTECTED]) [15:17] skvidal: yes, continue with that plan [15:17] skvidal: [15:17] skvidal: thank you [15:17] mmcgrath: [15:17] xDamox: if your happy I can check them in to puppet and firewall will be done [15:17] * dgilmore is here [15:17] * abadger1991 back [15:18] mmcgrath: xDamox: excellent. [15:18] skvidal: cool-mo-dee [15:18] xDamox: [15:18] mmcgrath: xDamox: anything else? [15:18] xDamox: do you want any firewall rules applied to xen? [15:19] JSchmitt has joined the group chat ([EMAIL PROTECTED]) [15:19] xDamox: XEN are the only hosts without firewall rules [15:19] dgilmore: xDamox: yes but we need to work out what [15:19] xDamox: yea not a problem [15:19] mmcgrath: ahhh yes. [15:19] mmcgrath: So here's the problems to overcome. [15:19] mmcgrath: We'd like to be able to block traffic from the xen guests at the xen host. [15:19] dgilmore: xDamox: we have some guests we want almost no access to others inside the colo [15:20] mmcgrath: Note, the xen guests will move around so its probably smart
Re: Infrastructure SCM
On Mon, 2007-07-02 at 09:13 -0500, Mike McGrath wrote: > > git: +1 Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora Infrastructure IRC Meeting Log from 2007-07-05
[15:04] mmcgrath has set the subject to Fedora Infrastructure -- Who's here? [15:04] * abadger1999 stops coding for a minute and prepares for a meeting [15:04] * xDamox is ehre [15:04] fchiulli: frank is here [15:05] jcollie: hello... [15:05] f13: I'm somewhat here [15:05] mmcgrath: we'll be following http://fedoraproject.org/wiki/Infrastructure/Schedule as usual. [15:06] mmcgrath has set the subject to Ticketing System -- All [15:06] MrBawb has joined the group chat ([EMAIL PROTECTED]) [15:06] mmcgrath: So https://hosted.fedoraproject.org/projects/fedora-infrastructure/ is up. [15:06] mmcgrath: AFAIK, people have been testing with it. [15:06] mmcgrath: I like it quite a bit. [15:06] G: mmcgrath: looks good, but can we please put the header image on HTTPS? [15:06] mmcgrath: G: sure. [15:06] mmcgrath: f13: should we put just the login on https? [15:07] mmcgrath: we can leave it for now as is. [15:07] * skvidal is here - just grumbly [15:07] mmcgrath: Does anyone have any issues with me sending out a notification and migrating some items to it? [15:08] G: well yeah, just not a mix, some browsers *cough*IE*cough* don't like it [15:08] mmcgrath: [15:08] mmcgrath: I'll take that as a no. [15:08] paulobanon: im here [15:08] mmcgrath: paulobanon: yo [15:08] * warren here [15:08] f13: mmcgrath: we should just do all I suppose. Easier. [15:08] f13: I hate to auth via https then suddenly drop to non https [15:08] * mmcgrath does too [15:09] GeroldKa has joined the group chat ([EMAIL PROTECTED]/geroldka) [15:09] mmcgrath: So after the announcement and migration of old tickets I'll be removing a bunch of queues and things from OTRS. [15:09] mmcgrath: we still need to figure out what to do with [EMAIL PROTECTED] and [EMAIL PROTECTED] [15:09] warren: ah, OTRS is shutting down? [15:10] mmcgrath: I've thought about just having a filter that replies with something like "we've moved to a web based system, please go here" [15:10] mmcgrath: but I'll leave that up to those teams. [15:10] mmcgrath: warren: I'd like it to but we've committed to something at least for webmaster and logo. I'll have to work out something with them. [15:10] Rasther has joined the group chat ([EMAIL PROTECTED]/Rasther) [15:10] mmcgrath: We'll see, anyone have anything else on that topic before we move on? [15:11] mmcgrath: alllrighty [15:11] paulobanon: when _! [15:11] paulobanon: ? [15:11] paulobanon: [15:11] mmcgrath: paulobanon: hopefully by the end of the week. [15:11] paulobanon: k [15:11] mmcgrath has set the subject to Package Database -- abadger1999 [15:11] mmcgrath: abadger1999: whats the latest? [15:12] abadger1999: I'm lagging behind but I think I've just fixed the last issue for bugzilla sync [15:12] abadger1999: I also made a few changes that enable logging into the packagedb from the commandline. [15:13] mmcgrath: abadger1999: any chance for you to move your main testing to publictest1? [15:13] abadger1999: So I can jump right into writing a script to insert information from new completed reviews and branch requests in to the db. [15:13] abadger1999: I've been trying to complete the initial rollout so I didn't work on that but I can. [15:13] abadger1999: Does it use supervisor? [15:14] abadger1999: I'll need to make that port anyho. [15:14] mmcgrath: abadger1999: it doesn't have any tg on there yet at all. [15:14] abadger1999: mmcgrath: k. I'll see about setting it up. [15:14] mmcgrath: solid. [15:14] mmcgrath: anything else? [15:14] warren: one thing [15:14] abadger1999: Anyways -- all that's left is koji sync + the new branch/package script. [15:15] warren: Did we agree on where non-people accounts should be? [15:15] warren: We'll need a koji account (with a cert) for automated sync from pkgdb to koji [15:15] abadger1999: Ah. So I have a few non-people users in the account system living at 9900+ [15:15] abadger1999: But none of those are supposed to login to anything. [15:15] warren: although FAS accounts != koji [15:16] warren: so I'm a little confuse [15:16] warren: d [15:16] abadger1999: The koji account is slightly different. [15:16] * mmcgrath is too [15:16] mmcgrath: these accounts are a requirement for the pkgdb? [15:16] abadger1999: warren: Don't koji accounts sync from FAS? [15:16] warren: abadger1999, I'll ask f13 to confirm [15:16] abadger1999: mmcgrath: All owners in the pkgdb have to be in the FAS. [15:17] f13: yes [15:17] mbonnet: abadger1999: there's no syncing...users are created in koji on-demand, when someone with a FAS client cert logs in [15:17] f13: koji just allows in proper SSL certs [15:17] f13: and creates users on the fly IIRC [15:17] abadger1999: Ah. So you have to get a cert from the FAS. Once you have that, koji gives you permission to connect. [15:17] mmcgrath: yep [15:18] abadger1999: But doesn't actually share any information (like human_name_ with each other. [15:18] f13: correct [15:18] f13: koji's userdb is very very simple. [15:19] f13: username: permissions [15:19] ab
Re: Meeting Tomorrow
On Wed, 2007-07-18 at 21:25 -0500, Mike McGrath wrote: > 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 Here's a query that will list all of the open tickets that have the Meeting keyword: http://hosted.fedoraproject.org/projects/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Meeting Tomorrow
On Wed, 2007-07-18 at 22:04 -0500, Jeffrey C. Ollie wrote: > On Wed, 2007-07-18 at 21:25 -0500, Mike McGrath wrote: > > 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 > > Here's a query that will list all of the open tickets that have the > Meeting keyword: > > http://hosted.fedoraproject.org/projects/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority And of course there's a link to the query already on the front page! I added a "group by milestone" option to the query. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora Infrastructure IRC Meeting Log from 2007-07-19
[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 ([EMAIL PROTECTED]) [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: [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
Fedora Infrastructure IRC Meeting Log from 2007-07-26
[15:04] mmcgrath has set the subject to Fedora Infrastructure -- Role ca [15:04] mmcgrath: Who's here? [15:04] * skvidal is [15:04] jcollie: i am [15:04] * lmacken [15:04] jeremy has left (Remote closed the connection ([EMAIL PROTECTED]/redhat/x-2faba177d7c1624f)) [15:04] warren has left (Remote closed the connection ([EMAIL PROTECTED]/wombat/warren)) [15:04] marek: Marek Mahut [15:05] paulobanon: pong [15:05] * jbowes watches [15:05] mether_ has joined the group chat ([EMAIL PROTECTED] [15:05] * abadger1999 splits himself into two. [15:05] mmcgrath: Ok, we'll get started on the tickets. [15:05] * rayvd is he [15:05] mmcgrath: https://hosted.fedoraproject.org/projects/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority [15:05] mmcgrath has set the subject to Fedora Infrastructure -- Tickets [15:05] mmcgrath: first ticket [15:06] jeremy has joined the group chat ([EMAIL PROTECTED]/redhat/x-baaa30725c1d4645) [15:06] mmcgrath: #18. Scripts should produce no output. [15:06] MrBawb has joined the group chat ([EMAIL PROTECTED]) [15:06] paulobanon: rayvd: befora i forget request sysadmin-test group access for your Moin project (we continue in the meeting now) [15:06] mether_ has left (Read error: 104 (Connection reset by peer) ([EMAIL PROTECTED])) [15:06] mmcgrath: I've been working on #18, and aside from the mass mailing this morning its about done. [15:06] * rordway|m is here [15:06] rordway|m: well, somewhat [15:06] mmcgrath: Just make sure that when you guys automate something that you redirect any stdout to a log or /dev/null. [15:06] mmcgrath: rordway|m: yo [15:06] rayvd: paulobanon: thanks, will do [15:06] rordway|m: at OSCON, so I'm here as much as the wifi allows me [15:06] mmcgrath: next ticket #52 [15:06] mdomsch has joined the group chat ([EMAIL PROTECTED]) [15:06] mmcgrath: paulobanon: Proxy Caching [15:07] * vpv is here too [15:07] mmcgrath: what did you want to kno [15:07] paulobanon: mmcgrath: k so i want to know what can we deploy in PT1 [15:07] paulobanon: squid or mod_cache [15:07] paulobanon: to start playing/testi [15:07] mmcgrath: we can do both actually. [15:08] mmcgrath: Pick one, then the other. [15:08] paulobanon: start with squid then [15:08] mmcgrath: I'd *prefer* mod_cache, unless there's some horrible reason we shouldn't. [15:08] paulobanon: k start with mod_cache [15:08] paulobanon: [15:08] paulobanon: _almost_ anything to make u happy [15:08] mmcgrath: paulobanon: its totally up to you though. My only concern with squid is making it work in our current balancer setup. [15:08] jcollie: i think squid has more options for managing cache disk spa [15:08] paulobanon: jcollie: +1 [15:09] jcollie: er spa=space [15:09] mmcgrath: jcollie: my issue is, for example, right now if one of the mirrormanager servers goes down. It fails over automatically. [15:09] mmcgrath: I'm not quite sure how to do that (haven't thought about it) so its still a grey spot in my head. [15:09] mmcgrath: paulobanon: anything elseith that ticket? [15:09] paulobanon: if the cache is independentu wont have probs [15:09] paulobanon: one fails u have the other [15:09] mmcgrath: paulobanon: but how does mod_proxy_balaner know that? [15:10] marek: good point [15:10] paulobanon: in theory u just need to redirect your requests like this [15:10] paulobanon: proxy > cache > app [15:10] warren has joined the group chat ([EMAIL PROTECTED]/redhat/x-c809280b07cd9d56) [15:10] paulobanon: so if 1 app is down, the request will still go to the other [15:11] mmcgrath: paulobanon: well, if you can set it up as a proof of concept with failover, I'll be happy [15:11] mmcgrath: anything els [15:11] paulobanon: nop nothing more [15:11] warren: I'm back, sorry lost connection [15:11] mmcgrath: cool [15:11] mmcgrath: warren: no worries. [15:11] mmcgrath: I think we can skip ticket #14, its got a whole meeting for it. [15:11] mmcgrath: #31 [15:11] mmcgrath: ricky: ping? [15:12] ricky: mmcgrath: pong [15:12] mmcgrath: ricky: Anything to comment on ticket #31 "New Wiki" [15:12] mmcgrath: its got the meeting keyword so we're talking about it (feel free to remove it if there's nothing to discuss) [15:12] ricky: mmcgrath: Have we looked at zwiki, actually, or are the memory requirements too high? [15:13] ricky: It'd integrate nicely with Plone, and seems to fit our requirements feature-wis [15:13] mmcgrath: ricky: I'm not familiar with its memory requirements. [15:14] mmcgrath: ricky: if you've got something you'dike to try send it to the list, we'll pick at it [15:14] ricky: Sure, I'll try to formalize wiki evaluations a bit more on the wiki. [15:14] mmcgrath: cool [15:15] mmcgrath: ricky: anything else on the ticket? If not I'll move on [15:15] ricky: Not yet. [15:15] mmcgrath: cool [15:15] mmcgrath: next ticket # [15:16] mmcgrath: paulobanon: whats the word "Moin wiki optimizations" [15:16] paulobanon: k, so the RFRs where sponsored [15:16] rayvd:
Re: Fedora Infrastructure IRC Meeting Log from 2007-07-26
On Fri, 2007-07-27 at 18:15 -0700, David Lutterkort wrote: > On Thu, 2007-07-26 at 16:01 -0500, Jeffrey C. Ollie wrote: > > [15:30] mmcgrath: the problem is opening up access but still keeping some > > of the passwords/keys secure. > > [15:30] mmcgrath: like the web guys don't need access to the buildserver > > keys. > > [15:30] mmcgrath: and the build guys don't need the fedoraproject.org ssl > > key. > > [15:30] mmcgrath: that sort of thing > > Not sure if you guys know that or not (or if that applies to what you > guys discussed): puppet lets you define filserver modules that are per > node by putting something like > > [private] > path /some/path/%h > allow allow 10.8.34.0/24 > > in your fileserver.conf [1] for sensitive per-node data. The problem isn't client-side - the problem is giving people limited access to modify the puppet manifests and the puppet file server. I haven't yet thought of a good way to do that - we may just need to take a "trust but verify" style approach. That however might mean that we can't open up access as widely as we'd like. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Features for Fedora Project PBX 1.0
Testing has been going well, and people seem to like/want/need the service so I thought that we should nail down what features we want in the "Fedora Project PBX 1.0". Here's a list based on what I'd like to see and what I've gathered from IRC/email/voice conferences. 1) Permanent voice conferences for various Fedora subgroups. Conferences identified so far: fedora-board virtual-fudcon infrastructure art Other permanent voice conferences would be requested through a Fedora Infrastructure ticket. Larger conferences may need some sort of moderation system. Open question: should anonymous SIP callers be allowed to talk on the permanent conferences or should they be listen-only? Status: basic conferencing is working, moderation features are lacking in conferencing application and need to be developed. 2) Conferences should be able to be recorded. Status: in development. 3) Ad-hoc voice conferences. Anyone with a FAS account would be able to request an ad-hoc voice conference (optionally controlled via a PIN) through a web interface. Ad-hoc conferences would expire after a short time (24 hours?). These conferences would likely remain relatively small so moderation features would not be needed. Status: The web interface has not been started but Seth and I have the PBX side mostly working. 4) SIP accounts for anyone with a FAS account that requests them so that sip:@fedoraproject.org would forward calls to your softphone. IAX2 accounts would be available for "power" users. Numeric extensions will be assigned for those situations where it's more convenient to dial by number rather than name. Status - design is nearly complete, need to automate account creation and more testing. 5) Every SIP account would have voicemail. Instead of storing the messages locally, audio files will be forwarded to @fedoraproject.org. Status - testing the design, depends on automatic creation of accounts from FAS. 6) Access conferences and people from the PSTN (e.g. your cell phone). A US DID number will be obtained from an ITSP and forwarded to the Fedora Project PBX. DID numbers in other countries may be obtained if there is enough need and the costs are reasonable. Status: some testing has been done but a permanent ITSP needs to be identifed and an IVR needs to be developed so that all of the features can be accessed from the PSTN. 7) Documentation on how to set up Ekiga (for Gnome) and Twinkle (for KDE) needs to be developed. Other SIP clients will work, but you're on your own. Status: not started. 8) The PBX is currently running on publictest4 - need to identify permanent host and move the setup there. Firewall may need fixing up, puppet needs to be set up, and Nagios monitoring configured. Probably need a sysadmin-pbx group set up so that the appropriate individuals can manage the system. Status: not started. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Features for Fedora Project PBX 1.0
On Wed, 2007-08-08 at 03:41 +0530, Rahul Sundaram wrote: > Mike McGrath wrote: > > Rahul Sundaram wrote: > >> > >> Crazy idea: > >> > >> Voice support for end users by other end users. > > > > I'm not going to say no to this, but I am going to say that if this is a > > service we are serious about offering, it will take $$. Whereas the > > contributor only bridge can be made available now with our current > > resources. > > It will take $$ as in we need to talk to Max Spevack and get more funds > or we need to make users pay for the service? I can't see Fedora trying to make users pay for a support service like that, especially when it's staffed by volunteers. While it would take some resources, I don't think that it would be an extremely huge one. A server or two and some dedicated bandwidth would do it I think (so that downloads of Fedora Release N don't kill the quality of your VoIP connections). The idea has merit, I think that it's something more suited for Fedora Project PBX 2.0 though. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Infratructure Meeting Log for 2007/08/23
[15:02] mmcgrath has set the subject to Infrastructure -- Role call [15:02] mmcgrath: Who's here? [15:02] * lmacken [15:02] jeremy has left (Remote closed the connection ([EMAIL PROTECTED]/redhat/x-85aceb302d31e828)) [15:02] warren has left (Remote closed the connection ([EMAIL PROTECTED]/wombat/warren)) [15:02] * ricky [15:02] paulobanon: pong [15:02] * londo is here [15:02] * yingbull is here [15:02] mmcgrath: crazy, that happened at this same time last week (jeremy and warren logging off right as the meeting started. [15:03] * ricky is. [15:03] paulobanon: yup [15:03] abadger1999: yes [15:04] mmcgrath has set the subject to Infrastructure -- Tickets [15:04] mmcgrath: https://hosted.fedoraproject.org/projects/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority [15:04] mmcgrath: paulobanon: Ticket #52, whats up? [15:04] paulobanon: k so [15:04] paulobanon: im going with mod_cache all the way for now [15:04] jcollie: oops i'm here [15:05] paulobanon: we are currently using mod_cache_disk and _mem [15:05] paulobanon: and hopefully during the weekend or early next week start stress testing [15:05] paulobanon: and see what is improved, and what can be improved [15:05] paulobanon: thats it [15:05] mmcgrath: Cool, good to hear thats still making progress. Will we be able to implement for Fedora 8? [15:06] paulobanon: YUP [15:06] paulobanon: [15:06] mmcgrath: fantastic [15:06] paulobanon: thats the plan [15:06] mmcgrath: cool, anything else or we'll move on. [15:06] jeremy has joined the group chat ([EMAIL PROTECTED]/redhat/x-6c63cab4c75caa85) [15:06] paulobanon: move one [15:06] mmcgrath: k [15:07] mmcgrath: ticket #14 - Choose New VCS for Packages [15:07] mmcgrath: jcollie: any word? [15:07] jcollie: nope... semester starts next week [15:08] mmcgrath: k, no worries. We'll move on. [15:08] mmcgrath: ticket #31 - The wiki [15:08] * ricky doesn't have much to say about the wiki either [15:08] mmcgrath: ricky: should we remove the meeting notice on that ticket? [15:08] stahnma: I added a thought on the ticket [15:08] stahnma: but, it doesn't change the status [15:08] stahnma: [15:08] ricky: mmcgrath: Sure, I hope to be working on FAS2 for a while : [15:08] ricky: ** [15:09] mmcgrath: stahnma: feel free to talk about it. your concern was that we not automatically disclude PHP based wikis right? [15:09] stahnma: yes [15:09] abadger1999: yay! [15:09] paulobanon: \o/ [15:09] abadger1999: Err... Not pp [15:09] abadger1999: php [15:09] abadger1999: [15:09] stahnma: I just think that autocutting PHP is a bit short-sited [15:09] stahnma: it might not make it for other reasons [15:09] stahnma: but security for PHP is more of a rep basedon PHP apps, not PHP itself [15:09] stahnma: yes, it's very easy to code bad php [15:10] mmcgrath: One thing to keep in mind is that we don't have php anywhere else (or java for that matter) so it does make them less attractive. [15:10] stahnma: true [15:10] stahnma: that's a valid point [15:10] * ricky mentions cacti, just to be evil [15:10] mmcgrath: ricky: actually thats a good point. [15:10] mmcgrath: Though its on our noc machine [15:10] stahnma: it's also esy to write good PHP, if you try [15:10] stahnma: and I think mediawiki is awesome [15:10] stahnma: and secure...as secure as a wiki can be [15:10] * stahnma is done onthat one [15:11] mmcgrath: the other thing with the wiki is that its been taking a lower priority as of late. [15:11] paulobanon: lots of ppl working on other stuff [15:11] mmcgrath: stahnma: if you are interested feel free to review other wikis (and how to migrate from moin to them) post to the list. [15:11] abadger1999: stahnma: I'm not sure I'd agree with that. Look at the cve's for mediawiki, for instance. [15:11] paulobanon: and as a future moin is adding a DB backend also [15:11] ricky: Cool! [15:11] stahnma: abadger1999: fair enough, I am not all that educated on it [15:12] mmcgrath: ricky: mind if I remove the "meeting" tag from that ticket? [15:12] * paulobanon suggests adding it to FAS2 [15:12] mmcgrath: paulobanon: I'll do that now since its getting to crunch time. [15:12] * paulobanon is evil now... and run from ricky [15:12] ricky: mmcgrath: Sure. [15:13] mmcgrath: lets talk about that now actually [15:13] mmcgrath: Ticket #9 - Fedora Accounts System (LDAP) [15:13] mmcgrath: I know ricky has been doing a ton of work on it, whats the latest? [15:14] * paulobanon crashes lots of stuff... [15:14] ricky: Well my only change to the LDAP schema was to add a description field for groups- everything else was with the TG app. [15:14] paulobanon: ricky: u're using genshi or kid ? [15:14] ricky: I ended up moving the user/group sections out into different files/switching to genshi and doing some general template cleanups. [15:14] jcollie: didn't we need something for UIDs/GIDs? [15:15] abadger1999: Cool. So lots of cleanup it sounds like. [15:15] mmcgrath: j
Re: Off on Monday
On Mon, 2007-09-10 at 14:54 -0500, Michael Stahnke wrote: > Beacuse this is my favorite thread everor my Monday just isn't > going that well > > http://stahnma.fedorapeople.org/watertower.jpg -- it's the official > water tower used in the movie. (My GIMP skills suck) Here's a slightly better view: http://jcollie.fedorapeople.org/save_mcgrath.png Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Off on Monday
On Mon, 2007-09-10 at 15:14 -0500, Jeffrey C. Ollie wrote: > On Mon, 2007-09-10 at 14:54 -0500, Michael Stahnke wrote: > > Beacuse this is my favorite thread everor my Monday just isn't > > going that well > > > > http://stahnma.fedorapeople.org/watertower.jpg -- it's the official > > water tower used in the movie. (My GIMP skills suck) > > Here's a slightly better view: > > http://jcollie.fedorapeople.org/save_mcgrath.png And a higher resolution version: http://jcollie.fedorapeople.org/save_mcgrath2.png I just found my new wallpaper! Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fusion io solid-state storage
On Fri, 2007-09-28 at 10:57 -0400, Bill Nottingham wrote: > Ignacio Vazquez-Abrams ([EMAIL PROTECTED]) said: > > Just saw this, figured someone here might be interested. > > > > http://www.fusionio.com/ > > $30/GB. That's gonna hurt. It depends... If your application needs to be really fast but doesn't need terabytes of storage it might be worth it. Would mean extremely fast reboots too I suppose :). Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
VCS choice status
Apologies for dropping off the radar for the past few weeks, but things at work got busier rather than slacking off after the semester started (I got assigned several new high-priority projects - such is life when working in an understaffed IT shop) and I vastly underestimated how busy things would be in the evenings and weekends shuttling my kids back and forth to various activities. Anyway, things still are very busy with non-Fedora related stuff, but I thought that I owed it to the community to post this and get the discussion started again. It was my impression that there was very little consensus on what (if anything) should be done. There seemed to be three camps: 1) Stick with CVS as is. 2) Switch to another VCS, but the data in the repository would remain similar to what we currently use (RPM spec plus patches). 3) Switch to another VCS, but the data in the repository would radically change to an "expanded source" style repository. All three camps have vocal proponents as well as vocal opponents. My suspicion is that the "silent majority" is in the "stick with CVS" camp. My personal choice would be to switch to Git for the VCS but keep the repository data the same (spec file plus patches). I feel that switching to expanded source-style repositories is too radical of a change - we give up the notion of pristine source plus patches. Also, using an expanded source-style repository would mean that packagers would have to become much more familiar with the VCS since they would need to maintain various branches (vendor branch, branches for various patches). In any case, it's unlikely that I'll have significant amounts of time to work on a VCS conversion anyway so until someone else steps up to take charge of this project we'll have to live with what we have. Jeff P.S. I'll be in Chicago next week for a training class so if anyone in the Chicagoland area would like to get together some evening for drinks ping me on IRC or off-list. There's probably a couple of you out there that I should probably buy a beer so this could be your chance to collect! signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Php why must your apps suck so?
On Wed, 2007-10-24 at 11:22 +0200, Mirko Klinner wrote: > Hi friends of good infrastructure, > > 2007/10/23, Mike McGrath <[EMAIL PROTECTED]>: > Ok, so there's a ticket for a new news site, > > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/178 > > Fact: PHP apps have a poor track record. > Fact: There doesn't appear to be any viable Python CMS's > > After reading the requirements stated in the ticket I wonder if it > wouldn't be > the best idea to implement a little application like that in > TurboGears ? > I work with TurboGears on daily basis, so I guess it would take about > 4 weeks > to develop such a software, followed by another 8 weeks to test it and > bring it > to live. > > What do you think about that ? Not that I doubt your coding skills, but that would be another large set of unique code that Fedora Infrastructure would need to maintain. By using an existing CMS system FI gains from the experiences of everyone else that runs the CMS we choose. Plus by choosing an existing CMS we can spend those 4-8 weeks working on content and making a Fedora theme. Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
