This just in:
https://wiki.ubuntu.com/LTSUpgradesHowto
If anyone’s interested in trying LTS to LTS upgrades, follow the (short) instructions there, I have also posted this to the forums so discussion can take place there.
Archives par mot-clé : Development
Averatec users – watch out for Ubuntu Hardy alpha 5
I recently bought a new laptop so this isn’t as exciting as it would have been a feew weeks ago for me…
ATTENTION ALL REALTEK 8139 – based LAPTOP USERS (including Averatec)!
It seems this critical bug that provoked a solid kernel freeze (and prevented installing from LiveCDs) on Realtek 8139 -based laptops has a fix now and it will be available in Hardy alpha 5 if I understand well… So, watch out for that release and help us test it against this bug. I still remember all the time spent trying to just boot the thing.
Ubuntu and the Nokia N810 Internet Tablet
It’s been a few weeks already that I joined the Maemo contributor program, which entitled me to a good discount to get a Nokia N810 Internet Tablet.
While I’m proud I was chosen among 500 other contributors-to-be, it really was an ordeal to just get the device. I imagine it’s not easy to set this kind of program up, including coordinating discounts in differents currencies, inventory, shipping, etc. But this being Nokia and their third time running this kind of program, it’s very sad they chose not to tell when problems and delays occured, letalone the fact those happened in the first place.
Unfortunately the holidays came and went and the devices were available at full price for a good time before any contributor got their device. Combine that with dog-slow online stores filled with hungry Flash animations, rude customer service reps and it’s almost a miracle the N810 made it my door. I can’t see what the greater plan is in terms of building a contributor community. Maybe this is some kind of « Amazing Race » obstacle course, for sure the few remaining are the bravest.
Some of you will hunt me down and spam me with threaths and « die, ungrateful spoiled kid » messages, but in the end this won’t change my opinion that this is the worse consumer experience I’ve had in a long time, and I think it is unfair to just go about it like it doesn’t matter. I reminds me of the OpenMoko debuts. Who cares if a product is a precursor in technological freedom if it can’t even be delivered to developers on time ?
Now, going back to the topic of blogging about the N810…
As a full-time Ubuntu user at work and home, I am planning to report about everyday use with an emphasis on VoIP, free media formats use and support (or lack thereof) and generally its « level of freedom » in terms of applications and sync’ing. I don’t intend to write a single line of code – instead I chose to help with bug reports, documentation and some blogging.
For now I am just putting together any links directly related to Ubuntu or LInux in general at the Mobile Devices / Nokia page on the Ubuntu community docs wiki, and trying some of them. If anyone’s interested in contributing to that resource or just finding out about its updates, consider registering to the Ubuntu docs wiki site and subscribing to that resource.
I’d love to see Ubuntu installed and working on the Nokia devices, but just to be clear, I don’t intend to work on that nor do I have any personal or professional plans to do so. To be super-extra clear, I just want to see how well the open Internet tablet scores with Ubuntu – while making it better at it, hopefully. And no, this has nothing to do with Ubuntu Mobile.
Sad as it sounds, there may never be a « year of the Linux Desktop. Linux world domination by 2008 as Eric S. Raymond described it will most probably happen with mobile and embedded devices.
The bug reporting culture: 10 things to avoid, 10 things you can do
As a (relatively) long time Ubuntu user, occasional bug reporter and support analyst, I often deal with bug reporting and I feel your pain about bug reporting, Matt. This happens in many other free software projects, but I think Ubuntu’s popularity gives its problems more exposure, an opportunity to refine the process and maybe inspire others to learn from its mistakes and success.
Generally speaking it’s always nice if you can dedicate a few dozen minutes (around an hour I would say) to familiarize yourself with how bugs are reported in the project you’re participating with. In Ubuntu it’s the Bug Squad team – perhaps even join it. I view Bug Squad members as the little bee-workers that are front-line organizers and helpers in the fight against bugs.
Think about it. An hour or so is not that much to dedicate to learning and understanding how your contributions will (or not) affect Ubuntu. It will also give you tools and guidance to become helpful and efficient in any bug reporting. I am not saying everyone should join! But those of you who don’t join need to at least understand how a bug report is treated on the receiving end.
I’d like to contribute 10 things to avoid and 10 things you can do if you want to increase the chances of getting good results from bug reporting (meaning a fix or solution). Some of them come from the Best Bug Reporting Practices wiki page.
- Look for existing bug reports that match your problem. It saves a tremendous amount of time when several people do this. It helps confirming a bug and tying loose ends 🙂 Checking upstream and linking those is very nice too!
- When filing a new bug, mention the ID’s of all bugs that sound similar. use « Bug #XXX », this provides an automatic link. Someone can dupe them together later.
- Add missing data (including video, YES VIDEO, screen captures, logs) to an existing bug. In some cases more is better.
- Provide context. Consider what is unique about your system, and mention it. Is it brand new out of the assembly line ? Did it stay overnight outside at -40C ? Is your music collection that fails to import in Rhythmbox 40000 files big ? Did you just reinstall ?
- Itemize the exact steps that result in the issue. Can you reproduce it at will? This is perhaps the single most important thing. If no one can reproduce your bug, chances are no one will be able to fix it. Providing clear steps dramatically helps.
- Follow up on your bugs from time to time, even if they seem ignored. Kindly ask for a follow-up if/when appropriate.
- Report if the issue goes away or remains when new Ubuntu’s come out.
- Once you’ve reported a bug, or if you have a few that are important to you, give them visibility. Go to forums, mailing lists, or post them in your blog. Not everyone reads bug reports or knows an issue they have is being worked on.
- Use IRC. Live chatting with developers on #ubuntu-bugs or #ubuntu-devel and asking a few questions while writing your bug report may help getting better information (like which package the bug should belong to).
- Get confirmation (or rejection) as soon as possible. Befriend a developer, expose your bugs, use whatever means to have other people confirm or reject your bugs. Be proactive if you want your bug reports to get some « traction ».
Here are my don’ts:
- Do not assume your bug report is more important because you’ve put several hours thouroughly detailing it. I know because I have done that. In many cases I see such reports as a documentation available to others, so they don’t repeat my own mistakes.
- Don’t be rude. Whatever the frustration, it’s not helpful to the bug’s resolution. I personally find this is the hardest to do 🙂 When in doubt, read again the Ubuntu Code of Conduct, take a few minutes before ranting.
- Don’t cite external links with lenghty discussions – unless you summarize them in one or two sentence. – this multiplies exponentially the time required to assess a bug’s status, importance, etc.
- Do not assume « they must already know about this » – no one does. Making assumptions only adds delays while clarifications are obtained.
- Don’t add « me too » responses, unless you are giving more details that actually help confirming a bug in its early reporting. It wastes everyone’s time when reviewing a bug (not to mention emails generated).
- Don’t post bugs with only a brief description of the problem. « XXXX doesn’t work » will get rejected or will expire. A model number for hardware by itself is not enough detail.
- Don’t assume others will « just know » how the bug occurs. Sometimes non-technical details (like « the wireless connection always drop when I pickup my wireless phone ») provide important context.
- Don’t fire and forget. Abandoned bugs rarely get fixed. If you are not willing / able to subscribe to your own bug reports and provide feedback, additional information, and even ultimately test possible solutions, make it clear in the bug report or don’t file it.
- Don’t post bug reports in other languages than english. This may seem obvious but when you install Ubuntu for someone that will be using it in any other language than english, automatic bug reporting may kick in and give the false impression any reports can be filed in another language. Educate your non-English speaking Ubuntu « customers » about this.
- Don’t assume every issue is critical. Between fixing a screensaver that crashes Ubuntu (easily worked around) or fixing a RAID issue that affects all server installs, what do you think should get more attention ? Importance is relative. Not everyone’s emergency is someone else’s too.
- EXTRA: Don’t ignore guidelines and procedure. If you know a rule, don’t ask for exceptions!
Last but not least, if your bug concerns business needs and is stopping your business or your customer or any commercial activity, consider actually paying a developer or company to look into it. Part of Canonical’s support services includes bug escalation but there are many other ways to « financially speed up » a bug’s resolution. Citing business concerns in Launchpad to speed up a bug’s resolution is not what I mean here, but actually paying someone to go through the community process for you or your company / organization.
If anyone has other tips to contribute, I’d love to hear them. I am far from a bug reporting expert so I’d love to learn any new tricks and tips here 🙂
Joining the Nokia N810 maemo device program
A few weeks ago I applied to the Nokia N810 maemo device program, as I’ ve become more and more interested in mobile devices. I thought my profile would fit their description of candidates fit for the program.
My close friends know a thing or two about my obsession with mobility (and, consequently, VoIP). I often have enough in my backpack to set up shop (or office) most anywhere and colleagues often come to me with unusual requests for adapters, connectors or accessories that I locate quickly among my desktop chaos. Unless you have lots of free time you don’t want my advice on the subject (including what kind of backpack best carries it all).
Last week I got an email announcing I had been accepted in the program, which means I’ll be able to buy a (discounted) device! Living in Montreal will no doubt help as we have a large free wireless network provided by Ile sans Fil.
My application basically proposed to work and contribute in the following areas, from a non-developer, end-user point of view:
- Making the N810 work flawlessly with Ubuntu: syncing, access to data, etc.
- Look for language support problems
- Abuse the device’s VoIP and video capabilities
- Obsessively use and abuse Ogg Vorbis and Ogg Theora content
- Share the device with colleagues & friends and collect input about all the above
- Report bugs, document and review this device on my blog based on all the above
I was clear in my application I won’ t be doing any dev work, and I have never contributed to the maemo project before, so I am happy I got accepeted and hope I will make the best of it.