Re: Moin 2.0 (or as I call it, mediawiki)
Mike McGrath wrote: So I spent some time last night and produced this: https://publictest1.fedoraproject.org/wiki/index.php/FedoraMain Are the mediawiki access controls sufficient for our needs? iirc they are pretty limited compared to moin's, but I'm not sure to what extent we're using them. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Dial-in
The Board would like to set up a "town hall" style meeting for our first meeting in March, if possible. (The timeline is not strict, but I'd like to be able to start telling the community our actual timeline very soon.) We'd like to support call-ins so people can hear the Board's meeting publicly. I have no idea how many people would actually show up to listen, but let's assume it's in the 50-100 range, and maybe we're nearly right. Can we support this with our current Asterisk setup in Fedora? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug 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
TurboGears-1.0.4/SQLAlchemy-0.4 upgrade
Hello TurboGears application developers, We would like to upgrade the version of Turbogears and SQLAlchemy present on the Fedora Infrastructure app servers in the near future. There are a few details that make this an update that I would like to have people test heavily but overall it should be an easy upgrade for most people. Details: TurboGears 1.0.4 is an update that retains TG-1.0.x compatibility. We don't anticipate any problems with this portion. SQLAlchemy 0.4 is an incompatible update to SA-0.3.x. TurboGears-1.0.4 includes changes to allow us to use it with minimal porting. Most Fedora Web apps are using SQLObject so they shouldn't be affected by this update. python-fedora's tgfas, pkgdb, and smolt use SQLAlchemy. loupgaroublond has already ported smolt so porting tgfas and pkgdb should be all that is needed to enable this. I'll be testing ports of both of those this week. If anyone has another web app that should be accounted for by this update, please *holler loudly*. The two issues I anticipate: 1) FC6 is EOL but app3 is still FC6. I've had success using EPEL-5 packages on FC6/app3 for a few packages in the past but this could be a bit more involved as TurboGears has a lot of dependencies. Unless we can plan on obsoleting app3 before we upgrade we'll need to do some testing on publictest1 as well as publictest10 to be sure that the TG package and dependencies work on FC6. 2) Because python-fedora has to be ported to the new SA API I also want to update the code to use the latest TurboGears conventions. This will allow us to simplify the TG-Auth code quite a bit (I'll be able to get rid of about half of our code in favor of code that's carried in TG proper). However, there is the risk that some of the bugs that we fixed when creating our code will be reintroduced because of this. I'm thinking especially about the session bug where people would hit the login page and then not be logged in or hit the logout page but not be logged out. Since that bug was hard to reproduce reliably, I'll need other people to help test this. I'm getting the new python-fedora working on publictest10 right now and will be installing and testing the new stack on publictest1 soon (probably tomorrow.) I'll send a note for people to beat on it while I port over the packagedb. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: TurboGears-1.0.4/SQLAlchemy-0.4 upgrade
2008/2/11 Toshio Kuratomi <[EMAIL PROTECTED]>: > Hello TurboGears application developers, > > We would like to upgrade the version of Turbogears and SQLAlchemy > present on the Fedora Infrastructure app servers in the near future. > > There are a few details that make this an update that I would like to > have people test heavily but overall it should be an easy upgrade for > most people. Details: > > TurboGears 1.0.4 is an update that retains TG-1.0.x compatibility. We > don't anticipate any problems with this portion. > > SQLAlchemy 0.4 is an incompatible update to SA-0.3.x. TurboGears-1.0.4 > includes changes to allow us to use it with minimal porting. Most > Fedora Web apps are using SQLObject so they shouldn't be affected by > this update. python-fedora's tgfas, pkgdb, and smolt use SQLAlchemy. > loupgaroublond has already ported smolt so porting tgfas and pkgdb > should be all that is needed to enable this. I'll be testing ports of > both of those this week. Smolt should still work on SQLAlchemy 0.3, maybe with some very minor changes. +1 for upgrading applications, as the new SA is very slick, and TurboGears takes full advantage of this (like session creation strategies that can be customized at a TurboGears level, so they can be very intelligent about user sessions, or user threads, etc). Even so, there's no rush if we don't need to. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: TurboGears-1.0.4/SQLAlchemy-0.4 upgrade
On Mon, 11 Feb 2008, Toshio Kuratomi wrote: > Hello TurboGears application developers, > > We would like to upgrade the version of Turbogears and SQLAlchemy present on > the Fedora Infrastructure app servers in the near future. > > There are a few details that make this an update that I would like to have > people test heavily but overall it should be an easy upgrade for most people. > Details: > > TurboGears 1.0.4 is an update that retains TG-1.0.x compatibility. We don't > anticipate any problems with this portion. > > SQLAlchemy 0.4 is an incompatible update to SA-0.3.x. TurboGears-1.0.4 > includes changes to allow us to use it with minimal porting. Most Fedora Web > apps are using SQLObject so they shouldn't be affected by this update. > python-fedora's tgfas, pkgdb, and smolt use SQLAlchemy. loupgaroublond has > already ported smolt so porting tgfas and pkgdb should be all that is needed > to enable this. I'll be testing ports of both of those this week. > > If anyone has another web app that should be accounted for by this update, > please *holler loudly*. > > The two issues I anticipate: > 1) FC6 is EOL but app3 is still FC6. I've had success using EPEL-5 packages > on FC6/app3 for a few packages in the past but this could be a bit more > involved as TurboGears has a lot of dependencies. Unless we can plan on > obsoleting app3 before we upgrade we'll need to do some testing on publictest1 > as well as publictest10 to be sure that the TG package and dependencies work > on FC6. This is blocking on getting the transifex deps into EPEL. At this point I think we should stick them in infrastructure repo, some of the package owners have been contacted and been slow to respond I've added it to my list of things to do this week, hopefully we'll get transifex running on other boxes soon. Toshio, thanks for doing all of this. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Dial-in
On 2/11/08, Paul W. Frields <[EMAIL PROTECTED]> wrote: > The Board would like to set up a "town hall" style meeting for our first > meeting in March, if possible. (The timeline is not strict, but I'd > like to be able to start telling the community our actual timeline very > soon.) We'd like to support call-ins so people can hear the Board's > meeting publicly. I have no idea how many people would actually show up > to listen, but let's assume it's in the 50-100 range, and maybe we're > nearly right. > > Can we support this with our current Asterisk setup in Fedora? I've been thinking about this a bit and I'm not sure if "pure" Asterisk is the right tool for this. The Asterisk conferencing just isn't very efficient for handling a few talkers and many listeners, plus Asterisk doesn't always scale well. What I see is something like this: 1) Board members use a SIP client to dial into an Asterisk conference call. We'll need to make sure that board members have a properly configured SIP client as well as a decent microphone/headset (built-in mics on laptops need not apply). 2) Audio from the conference call is fed to a Flumotion (GPL and already in Fedora) streaming server where the general public can listen in. Totem (and plenty of other F/OSS apps in Fedora) should be able to stream the audio from the Flumotion server directly. For those who need to use another OS to listen in we could use Fluendo's Cortado Java applet (GPL but not yet in Fedora AFAICS). The key is figuring out how to get the audio from the Asterisk conference to the Flumotion server, but I'm sure that the Fluendo folks would be willing to lend a hand on the details. Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
