J5’s Blog

Wed 10 Jun 2009

The project I have been working on for a long time now has seen it’s first (beta) release. Meet Fedora Community, a consolidation of the various Fedora Infrastructure bits into one UI with a focus on usability. The unique thing about this site is that it doesn’t replace the other Fedora Infrastructure bits. It uses them as backends and mashes together the data into one view. For instance you no longer have to go to the bodhi update tool after checking on a build in koji. Instead you simply look at the build tool and if the package is able to be updated you will be presented with the option to do so. It will also point you to the correct log if an error happens in the build.

Right now it is geared towards Fedora packagers but in the future we hope to be adding a lot more functionality. Since the concept revolves around small applications running in a dashboard the possibilities are endless. Think live server status for sysadmins or up to date Fedora news for users. As always, because Fedora stands for Freedom and Community we will be emphasizing upstream collaboration which we owe a great debt for making all of Fedora possible, and Fedora Community’s code will always be licensed under AGPLv3 and compatible licenses.

To learn more you can grab the podcasts (in ogg vorbis format of course) or go to our project page.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

 

11 Responses to “Drink a glass of wine it’s release time”

1. Jef Spaleta Says:
   June 10th, 2009 at 6:02 pm

   KICK ASS!

   The package maintenance profile view is going to be super useful.

   Are there plans to try to tie in a view of recent bugzilla activity to the package maintenance profile summary view about my packages?

   This is pretty damn hot.

   I wonder, would a different dashboard organization view like this help spin maintainers?

   And have you talked to the transifex folk about this dashboard tech as a translations portal?

   -jef

2. J5 Says:
   June 10th, 2009 at 6:15 pm

   @Jef

   Ya we need to talk to the transflex people about providing us with an API for adding projects and querying which packages use transifex.

   We hope to add personalized dashboard pages so a user can create their own page and make it public. We need more apps and a configuration interface but dashboard apps have their own mini config language so the storage format is already written. The next step is refining the API and getting people to write apps which means we can expand the scope of Fedora Community a lot faster than just Luke, Maurine and I working on it.

3. Jef Spaleta Says:
   June 10th, 2009 at 6:22 pm

   So…how far can this dashboard concept be abstracted?

   Could we see the development of KDE plasmoid like desktop elements to move some of this dashboard functionality out of the browser window?

   Or as distinct element’s in moblin’s “m-zone” browser concept?

4. Max Says:
   June 10th, 2009 at 6:25 pm

   This is really tremendous, John. Congratulations!

5. J5 Says:
   June 10th, 2009 at 7:05 pm

   @ Max

   Thanks, it means a lot!

   @ Jef

   All of our apps are served off of /community/apps with a URI format (e.g. each app has a list of parameters they take). Right now you need to know the name of the apps and their params but we will be cataloging them and adding a config interface. Plazmoids, as long as they aren’t using khtml (webkit works but khtml just can’t handle the javascript) should work fine. Once we get live updates into Fedora Infrastructure via AMQP the plasmoids should update live. This all assumes Plasmoids use standard web technology.

6. Kevin Kofler Says:
   June 11th, 2009 at 1:33 am

   The site doesn’t work at all in Konqueror, it looks from your comment #5 that you’re aware of that, so how come you even consider it releasable? The site is completely useless in the default browser of one of our own spins, this is extremely embarassing, not to mention it won’t facilitate my workflow at all.

7. J5 Says:
   June 11th, 2009 at 9:13 am

   Sorry Kevin, but Konq’s javacript engine just doesn’t meet standards (It fails to run the simplest jQuery queries and doesn’t have any decent JavaScript debugger). The site works fine in WebKit but the Konq developers have decided not to move to WebKit. I will support standards but I’m not going to hold the project back when two of the three major open source browsers engines work fine.

   The KHTML devs are working on re-factoring WebKit into KHTML from what I hear, so it is there bug to fix. If a KHTML developer wants to look over our site and give us tips that will not cripple the functionality I will welcome that too but without a decent debugger, I’m not going to be able to do anything. But then again I hit resource limits using regex’s so I wouldn’t hold my breath.

   Perhaps instead of going on the assault you should consider helping out with the situation. Talk to the KHTML devs, debug and file bug reports so they can fix this issue. I remember talking to a bunch of KDE guys when these issues popped up on an even simpler version of our site, and they pretty much said it was an unfortunate situation but the KHTML guys had their reasons for not switching to WebKit but it shouldn’t hold our project back. I’ll do my part and talk to the KHTML developers who are attending the Desktop Summit in July.

8. Kevin Kofler Says:
   June 11th, 2009 at 3:42 pm

   Yet web developers all around the world make their sites work with things like IE 5 which are a lot less standards-complaint than Konqueror is… It’s the site’s job to work in the user’s browser.

9. Kevin Kofler Says:
   June 11th, 2009 at 3:43 pm

   I mean “standards-compliant”, of course.

10. Kevin Kofler Says:
    June 11th, 2009 at 3:45 pm

    Hmmm, why is my original comment held for moderation and my correction not?

11. J5 Says:
    June 11th, 2009 at 4:24 pm

    IE has a very good javascript debugger. Note we don’t work with IE either yet because I don’t have a windows machine though I might borrow my roommates. I would love to support Konq but they make it hard for me to help out. It is like saying I have to support Links because it is an open source browser that some people use. It is one thing if the issue is minor incompatibilities like we had with WebKit, it is quite another if you can’t even run a regex on 32k of data before Konq pops up a resource limit dialog. File a bug with them.

    I would agree with you if KHTML was the only open source browser engine but it isn’t. We have two that follow standards pretty good which has the added benefit that other standard complaint browsers just work.

    BTW we don’t lock you away from any of the data. You can still get to them in the individual tools such as koji, bodhi, pkgdb and fas.

    Perhaps I should do another blog posts similar to my Mozilla doesn’t support embedded browser posts. It is cited as one of the reasons some people in GNOME started hacking on WebKit though my original intention was to get Mozilla to start taking embedded seriously (which they eventually did). Lets be honest here, KHTML has a long way to go and they can not rely on others holding back until they catch up. As I said, I will have a talk with the devs and some of my KDE friends like Zack and Aaron at the Desktop Summit. We will see if there is some middle ground or if they can use FComm as a target to help fixing bugs in KHTML.

    As for moderation, I have elipses (…) blocked because a lot of spam comments and tracebacks are something like:

    John Palmieri had an interesting blog post “The project I’ve been working on…”