Re: F10?
On Mon, 2008-05-19 at 23:44 -0400, Ricky Zhou wrote: > On 2008-05-19 10:27:52 PM, Mike McGrath wrote: > > All in all I feel it was a good release. So my question to the team, what > > would you all like to see over the next 6 months? > * New wiki :-) > * More/better documentation ^ This is where Jef Spaleta's role-based SIG idea, and the Docs team's new direction, might be helpful. If we can get one or more people from Docs hooked up with this team to help, all the work can/should be done on the wiki. Mike and I have talked in the past about the fact that Fedora has a world-class infrastructure and the team to support it. If we can get the details down on "paper," we add substantially to the proposition that Fedora is much more than just a distro. We can have a blueprint for any similar project, or open-source business startup, or anyone who wants to bootstrap their own community, to go from zero to sixty in terms of supporting that community with the tools they need for communication, coding, and presence. Certainly that could take more than six months, but it's a great time to get that off the ground. -- 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
Re: F10?
On Mon, May 19, 2008 at 10:27:52PM -0500, Mike McGrath wrote: > So F9 is out the door and we had a very exciting last 6 months. Here's > the short list: > > * FAS2 > * /mnt/koji migration and deployment > * Backup system up and running > * Collaboration servers brought up (gobby and asterisk POC) > * UTC switch > > The focus for this last release was mostly around sanity. Cleaning up > some configs, things like that. We actually did a very good job of that. > > All in all I feel it was a good release. So my question to the team, what > would you all like to see over the next 6 months? Here are some things I'd like to get done: - Signing server (sigul) - Solidify our SELinux deployment. I'm sitting down with Dan Walsh this week to churn through our logs and fix as much stuff as possible. Brett Lentz (Wakko666) has also been doing a great job of writing test cases and pushing some crucial puppet SELinux changes upstream. - Get our logging situation under control. - Get bodhi into the app cluster, and give it the ability to kick off mashes on our releng boxes. luke ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: F10?
Things I'd like but probably can't work on myself: * GeoIP/DNS based proxying. I'm in Europe and request admin.fedoraproject.org I get the European app server. I'm in the US I get PHX or tummy. - This might make it possible for us to have app servers around the world. We'd still have latency from database calls having to get replies from PHX but for calls between apps all requests would stay in the same colo. Things I'll have a hand in: * New python-fedora API with exception-like error handling client-side and more standardization server-side. - Porting all our web apps to the new architecture. * Optimize db calls within TG applications to make them as snappy as possible. I can do this for SQLAlchemy but SQLObject isn't flexible enough. Any page which is for viewing data and is returning multiple records is potentially a good candidate. * OpenID auth provider for our TG apps (if it's faster/better than our current jsonfas provider). We don't gain any features from an OpenID provider unless we want to allow other OpenID servers to authenticate our users. * pkgdb: I'm going to concentrate on refactoring existing pkgdb code. I'm hoping mapleoin will keep up the good work he's been doing adding new features. * New koji db server. * Moving TG apps from supervisor to mod_wsgi -Toshio ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: F10?
On Tue, May 20, 2008 at 09:15:28AM -0700, Toshio Kuratomi wrote: > Things I'd like but probably can't work on myself: [...] > * Optimize db calls within TG applications to make them as snappy as > possible. I can do this for SQLAlchemy but SQLObject isn't flexible > enough. Any page which is for viewing data and is returning multiple > records is potentially a good candidate. Speaking of stuff I'd love to see happen, but don't have the time for :) - Port bodhi to SQLAlchemy luke ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: F10?
On Tue, May 20, 2008 at 1:54 PM, Luke Macken <[EMAIL PROTECTED]> wrote: > On Tue, May 20, 2008 at 09:15:28AM -0700, Toshio Kuratomi wrote: >> Things I'd like but probably can't work on myself: > [...] >> * Optimize db calls within TG applications to make them as snappy as >> possible. I can do this for SQLAlchemy but SQLObject isn't flexible >> enough. Any page which is for viewing data and is returning multiple >> records is potentially a good candidate. > > Speaking of stuff I'd love to see happen, but don't have the time for :) > - Port bodhi to SQLAlchemy Depends on how complicated your stuff is already. If it's mostly just a bunch of tables, and the oddball query, I can probably do it in about a day. If it's alot of complicated composite tables with composite keys, custom data types, custom rules, and massive dependencies, then it could take 2-3 days. Let me know when you need help. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
MyFedora Documentation
http://fedoraproject.org/wiki/MyFedora/ is pointing to some new documentation I started writing. Right now all I have is the plugin design document (http://fedoraproject.org/wiki/MyFedora/PluginDesign) but will be adding the plugin tutorial tomorrow and the widget tutorial will be written the week before FudCon when Toshio and I lock ourselves in a room and flesh out the design for the widget system that started at the last FudCon. Others are encouraged to comment on the design and send suggestions and I will be working during FudCon to get people interested in developing content or working on the backends. -- John (J5) Palmieri <[EMAIL PROTECTED]> ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: F10?
On Tue, May 20, 2008 at 02:18:53PM -0400, Yaakov Nemoy wrote: > On Tue, May 20, 2008 at 1:54 PM, Luke Macken <[EMAIL PROTECTED]> wrote: > > On Tue, May 20, 2008 at 09:15:28AM -0700, Toshio Kuratomi wrote: > >> Things I'd like but probably can't work on myself: > > [...] > >> * Optimize db calls within TG applications to make them as snappy as > >> possible. I can do this for SQLAlchemy but SQLObject isn't flexible > >> enough. Any page which is for viewing data and is returning multiple > >> records is potentially a good candidate. > > > > Speaking of stuff I'd love to see happen, but don't have the time for :) > > - Port bodhi to SQLAlchemy > > Depends on how complicated your stuff is already. If it's mostly just > a bunch of tables, and the oddball query, I can probably do it in > about a day. If it's alot of complicated composite tables with > composite keys, custom data types, custom rules, and massive > dependencies, then it could take 2-3 days. > > Let me know when you need help. Cool. Give me a week or so to finish up some major bodhi changes that I have underway, and the releng2 migration. I've created a ticket so we can track this task, and I'll let you know when it's safe to dive in. https://fedorahosted.org/bodhi/ticket/202 Thanks! luke ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Red Hat Bugzilla 3.2 Upgrade Beta 1
Hi, I'm passing the following information on for the team that maintains the Bugzilla instance Fedora runs in. It provides a peak into the upcoming Bugzilla update and an opportunity to evaluate it in a test instance. Check it out. John Greetings, The Red Hat Bugzilla team is happy to announce the first beta release of the next version of Red Hat Bugzilla. The next version will be based on the upcoming upstream 3.2 code base soon to be released. https://partner-bugzilla.redhat.com Along the way to the final release, we will be deploying several beta releases that will be used for obtaining user feedback and for finding bugs in our code changes. Red Hat has made substantial customizations to our current 2.18 based Bugzilla system that have been ported to the new release. Several of which we are working on having them accepted by the upstream community which will help in future bug fixes and lower maintenance. We are also hoping to use the upgrade process as a stepping stone to becoming more active in the future road map of Bugzilla itself by providing help with bug fixes and enhancements and taking part in future discussions. Areas of focus for beta1: Ajax optimizations: Speedup one component/version/milestone population on the advanced query screen due to large volume of data for some products such as RHEL and Fedora. Speedup of the show_bug.cgi page by reducing amount of HTML needed to download by not loading all components unless you want to change the value. Needinfo actor support: Using the flags functionality, we are able to specify whom additional information is being required of for a report. In the current 2.18 release a combination of a bug status called NEEDINFO and needinfo flag were used. In 3.2 only a needinfo flag is being used and the bug status will be removed. Guided bug entry: Modified stock guided bug entry page used to help non experts report bugs with proper information. UI enhancements: Upstream Bugzilla developers have done extension work on streamlining the show_bug.cgi page. The page should have a cleaner less cluttered feel as well as show only editable fields for the values the user is allowed to change only. One of the more noticeable things is the removal of the "Bug Status Change" area and moving it up to the basic bug information area. External bug references: Ability to add links to outside bug trackers. XMLRPC API: The Red Hat Bugzilla system was one of the first Bugzilla installations to utilize XMLRPC extensively. Upstream as of 3.0 has a new framework for providing Web Services to clients to manipulate Bugzilla data. We have worked to help the upstream to add features to this framework to support similar functionality to what we have had in operation for some time. Some of the core functions are there such as Bug.get(), Bug.create(), Bug.search() and Bug.update() which can be used to do most things needed. Some of the operations available in our version are not yet available so we are also providing most of the old 2.18 API so that your applications and scripts should continue to work properly for the time being. Please try your scripts against the test Bugzilla system to make sure they are working properly. Let us know if there are any errors such as data not being returned in the proper format, certain methods missing, or bugs in general. New methods available (Note: these are subject to change before final release): 1. Bug.get() - Can be used to get all attributes of one or more bug reports. 2. Bug.create() - Can create a new bug report in the system. 3. Bug.update() - Can update most attributes of one or more current bug reports. 4. Bug.search() - Search the database for bugs matching search criteria similar to advanced search UI. Also supports quicksearch keywords and reloading of saved searches saved in the Bugzilla UI. 5. Bug.get_activity() - Retrieve full history of one or more bug reports. 6. Bug.add_comment() - Can add a comment to a current bug report. 7. User.login() - Can take a username and password as parameters that will return cookies that can be used for all subsequent XMLRPC method calls. (Note: required to use the new methods such as Bug.*) 8. User.create() - Create a new user if you have proper permissions. 9. User.get() - Get information about one or more current users if you have proper permissions. 10. User.update() - Allows updating of email, real name, disabled, etc for one or more current users. 11. Product.get_products() - Get information about one or more products in Bugzilla. 12. Component.get() - Get information about one or more Bugzilla components. 13. Component.create() - Create a new Bugzilla component for a specific product. 14. Component.update() - Updated the attributes of one or more Bugzilla components. Old methods ported to 3.2 (for backwards compatibility): 1. bugzilla.runQuery() 2. bugzilla.getBug() 3. bugzilla.add
