I’m currently sitting in the departure lounge awaiting my flight to Chicago on route to Tempe… ready or not here I come! I’m arriving at 19:59 on United Flight 0702 from Chicago. So with luck I should be at the hotel by 9PM. Keep the beer cold and see you all soon.
Well its not long before I’ll be jumping on a plane to head over the pond to Tempe, Arizona to the latest and greatest FUDCon. This will be my forth FUDCon event. I always enjoy them. Its lots of fun catching up with friends and fellow contributors who’ll no doubt become friends. There’s always one thing I really don’t like about FUDCon…. its that there’s always too many awesome topics of discussion and sessions that I want to attend but they conflict with other sessions that I want to go to 🙂
So what do I want to discuss and see discussed at FUDCon Tempe? Well as per usual there’s lots so here’s a quick bullet list:
- Fedora Mobility: How to take it forward and who wants to achieve what, and how we all go about it. As devices get smaller and every company and their dog release tablets I think mobile devices will become more key to Fedora. It also fits in very well with a number of the Fedora Board Long Term Goals in particular I think it fits well for the help people control their content and devices and the Access from anywhere strategy.
- Sugar, OLPC and Sugar on a Stick: there’s going to be quite a few people from various OLPC and Sugar projects in attendance. Also the awesome adamw and the Fedora QA team is going to be there so there’s plans to extend the discussions we started at FUDCon Zurich. The OLPC project is arguably the largest deployment of devices based on Fedora. The OLPC OS that runs on their XO laptops is pretty close to a vanilla Fedora release and as the last of the XO kernel patches make it upstream you can run vanilla Fedora on them with few issues.
- Fedora ARM and secondary architectures: dgilmore, ctyler, PaulW will (I think) all be there and Fedora ARM is really starting to amp up with their awesome work! This also crosses over somewhat into OLPC and is hand in hand with Fedora Mobility. I suspect the discussions will revolve around getting Fedora 14 and rawhide building, ARMv7 + hardfp builds and ensuring ARM becomes a solid secondary arch.
- Cloud: This sort of stuff is part of what I do for my $dayjob and it interests me greatly! I just wish I had more time to contribute to the SIG.
- MeeGo Netbook UX: yes, this was a big FAIL for Fedora 14 and I need to blog on this. Looking much better for Fedora 15. Watch this space!
- IPv6. There’s been some interesting posts on using IPv6 with various ISPs with that other Linux based desktop OS. Why isn’t there the same for Fedora??
- Friends: One of the big ones of the four F’s of Fedora.
- There’s always lots of random hallway discussions.
There’s no doubt a number of things that I’ve missed. The other thought I have is what of my Mobility tech toys to bring along. I have my laptop obviously. My atom based netbook running MeeGo Netbook UX on rawhide, my XO 1.5 running Fedora 14, my Toshiba AC100 running Fedora ARM 13 but I don’t think I can pack 4 laptop/netbook devices 😛
I finally sat down on the weekend to try and get some OS other than Android running on the Toshiba AC100 I bought off ebay on a whim. The AC100 doesn’t look that different to your average 10.1 inch netbook except its extremely thin and and light and on the inside it has a Nvidia Tegra 2 SoC based on the dual core ARM Cortex A9. My initial plan was to get Ubuntu running on due to the instructions about doing that to be found on the net. After doing some reading and while part way through the process I decided that I would try Paul Whalen’s Fedora 13 ARM rootfs instead as the process of creating a linux rootfs is similar across all distributions! There’s still quite a way to go. For starters its currently a very base system and its currently running a 2.6.29 kernel for ubuntu based on the code released by Toshiba but its a start. Over the next couple of days I plan on getting networking up and from there X plus gnome. Once I’ve got that done I’ll put up a more defined process and add the details to the ARM wiki devices page.
Fedora 14 was the third release that I’ve been involved in the Fedora feature process and to be honest for most of the things that I do in Fedora I think its going to be my last. I’ve found all processes when involved with Moblin and then MeeGo to be generally unpleasant and stressful so now I basically don’t see the point. My life seems to getting more and more stressful, I’m getting more and more grey hair so I’m reviewing the things that are making me stressed and seeing how I can expunge them from my life.
Don’t get me wrong generally I think for core features such as systemd there needs to be a process but for things like KDE 4.5 what is the point. Its going to be there, and in the KDE case where its likely it will be pushed to Fedora 13 and Fedora 12 anyway is it really a feature of Fedora 14?
So a little bit of history of the problems I’ve had and why I don’t want to participate any more….
For Fedora 12 I introduced the Moblin 2.0 “Feature” and at worked my butt off to get it all into Fedora 12. There were many flames on the list regarding the feature by narrow minded people that hadn’t even bothered to try it. By feature cut off there was one or two minor packages in review but in general the interface was working but because it wasn’t “feature complete” it was decided that it would be dropped. Oh well there goes all that work without even bothering to ask me (the Feature meetings are pretty much impossible for to attend due to timing). That whole process was stressful but it got worse as the spin request was also dropped because the feature was dropped. It turned out that people actually wanted the Moblin feature so spot (from memory) proposed to ask FESCo to review the dropping of the feature and in discussion somewhere it was decided that it the feature would be complete enough to be worthy to accept.
Fedora 13 went along similar lines. I proposed Moblin 2.2 with a fall back to Moblin 2.1 if it wasn’t released in time. It was massively complicated by upstream dropping the 2.2 release and announcing the MeeGo project. Again the Feature was dropped even though Moblin 2.1 was working and basically complete. Admittedly we didn’t have Moblin 2.2 but then that didn’t exist! Some how the Feature being dropped escaped notice by the Spins process and we still ended up with an official Moblin spin albeit about 4 days late to the release due to some rel-eng issue that has long escaped my mind. The same major issue reoccurred though…. the process was stressful and still there were the vicious threads on the devel mailing list! The other interesting part of that process was that I actually started receiving hate mail! I can mostly deal with the, at times, pretty horrific threads on the devel list but personal hate mail took this to a whole new level! This was starting to go from stressful to truly unpleasant.
Fedora 14 was a change…. the feature wasn’t dropped! In terms of the random decision process that is taken to see if a feature is in fact complete it seemed that MeeGo 1.0 ticked all the boxes. It had issues, I knew it had issues and I had plans to address those issues to get it sorted in time for release. The one thing I hadn’t truly expected, although to be fair I should have, in this release process was my $dayjob absorbing essentially 100% of my awaking time. I spent the best part of two months working pretty much 7 days a week. In fact the only weekend I had off in that time was my pre-booked side trip to FUDCon Zurich. The other interesting point was that no one was testing it, I have no idea why as there was nightly spins. I know that because it seems at some point MeeGo UX broke in Fedora and no one logged a single bug report or sent a single mail to say so. In the end I made the decision to drop the feature from Fedora 14. I probably made this decision too late and that was my fault but these things happen. There was also a lot of uncertainty regarding the use of the MeeGo UX where it didn’t meet upstream’s (completely undocumented at the time we were investigating it) demands and policies. What didn’t change in this release cycle was the usual hurtful flames on the devel list and the personal hate mail continues. Of course the people are sending the hate mail because the MeeGo UX in Fedora doesn’t work and they don’t want to actually do any work to help fix the problems, they just want their feature and they want it NOW!
The other major problem I have with the feature process is that no one really seems to follow it properly. The major example of this was the Python 2.7 feature for Fedora 14. There was clearly work going on for Python 2.7 in Fedora 14 but it landed in the mainline development about two days before the feature process closed out. WTF!!! Here you go suckers…. my feature is 100% complete in time…. you spend the last couple of days of the feature process not polishing and testing your features but fixing and recompiling all the crap that I missed in my process….. there goes a week! That sucked. Fedora 14 was branched off rawhide at the alpha release. That is when major changes like python for Fedora 15 should land. That was the whole reason that Jesse proposed the early branch model! Then there’s over 6 months until the F-15 Beta hits for everyone to get it all fixed up. Between that and the five or six unannounced breakages of the evolution requiring dozens of new package builds, the gnome shell guys randomly pushing changes without bothering to check and see if it affects anyone else and then not even helping to fix the breakages.
So the worst thing I’ve discovered with features is not really the actual process but the barrage of “I’m right Jack” attitude as people rush to get their features marked off as 100% complete and the lack of care towards others needs and requirements. Oh and the flame wars on devel and the hate mail.
I feel that if there’s no expectation of a “feature” being there there will be two pluses…. people have no reason to flame me and if it happens to work there will also be a pleasant surprise when they discover it. The downside will be that as its not defined it won’t be there for marketing to use to promote Fedora. I agree that will be a problem but well in the “I’m right Jack” attitude of others…. that’s not my problem.
BTW there will be a separate post to cover the MeeGo UX in Fedora later before people ask.
As has been previously announced OLPC is planning on moving to an ARM processor to advance the XO platform. The major advantage is similar computing power while having a massive reduction in power usage so as to maximise runtime.
Chris Ball has just posted a XO 1.75 status update to the Fedora OLPC list to let us all know that the project is moving forward and by the end of a recent bringup event the board is now booting a linux kernel and what is presumably a hacked up version of Fedora 12. YAY!
The latest and greatest shiny release of Fedora is out. It looking to be a great release with lots of shiny new features and for the first time an officially supported Amazon EC2 AMI image. For those that want to go straight to the download click here but be sure to check out the common bugs to see if any affect you. The newly released Sugar on a Stick v4 (code name Mango Lassi) is based on this release.
Congratulations to Jared for his first release of Fedora as the new FPL and to everyone who has contributed to what looks to be another awesome release!
Welcome to this blog. I plan to use it as a place to write about technology and technology related aspects of my life. I work in IT and I’m also involved in the Fedora, One Laptop Per Child and SugarLabs projects in my own time as well so I live and work in all sorts of tech so why not write about my experiences about it as well!
It will cover aspects of my job, the aforementioned projects as well as random tech discussion of things that I’m interested in from Photography to Music as well.
My $dayjob is working as an Infrastructure Engineer for the European Enterprise Hosting division of a global company. It has its trials and tribulations but generally I get to play with a lot of big expensive bits of core IT infrastructure ranging from networks, virtualisation, windows and Linux, storage as well as security while travelling to a number of destinations around Europe on an all too regular basis. So its not always bad!