I also loathe it, because every single time we get people saying "This Ubuntu release is the worst release ever!".
Ubuntu releases are always rocky around release time, because the first time Ubuntu gets widespread testing is on or after release day.
We ship software to 12 Million Ubuntu Users with only 150 MOTUs who work directly on the platform. That's a little less than 1 developer with upload rights to the archive for every 60,000 users. ((This number, like all other usage data, is dated, and probably wasn't even accurate when it was first calculated)) Compared to Debian, which (at last estimate in 2010) had 1.5 million uniques on security.debian.org, yet has around 1000 Debian Developers.
Debian has a strong testing culture; someone once estimated that around ¾ of Debian users are running
unstable or testing. In Ubuntu, we don't have good metrics on how many people are using the development release that I'm aware of (pointers welcome), but I'd guess that it's a very very small percentage. A common thread in bug reports, if we get a response at all, goes on as follows:
Triager: ((Developer, bugcontrol member, etc. Somebody who is not experiencing the problem but wants to help.)) "Is this a problem in $devel?"
User: "I'll let you know when it hits final"
Triager: "It's too late then. Then we'll want you to test in the next release. We have to fix it BEFORE its final"
User: "Ok, I'll test at beta."
Triager: "That's 2 weeks before release, which will be too late. Please test ASAP if you want us to have time to fix it"
Of course, there are really important bugs with hardware support which keep on cropping up. But if they're just getting reported on or around release day, there are limits to what can be done about them this cycle.
We need to make it easier for people to run early development versions, and encourage more people to use them (as long as they're willing to deal with breakage). I'm not sure whether unstable/testing is appropriate for Ubuntu, and I'm fairly confident that we don't want to move to a rolling release (currently being discussed in Debian, summary). But we badly need more developers, and equally importantly, more testers to try it out earlier in the release process.
To users: please, please try out the development versions. Download a LiveCD and run a smoketest, or check if bugs you reported are in fact fixed in the later versions. And do it early and often.
"We ship software to 12 Million Ubuntu Users with only 150 MOTUs"
ReplyDeleteWrong! You ship with 1000 Debian Developers + 150 MOTUs (maybe some DDs are also MOTUs, but you get the idea).
Ubuntu is made by DDs first and then by MOTUs and others.
Note the lead: "6ish months of work by Ubuntu (and by extension Debian) developers." Nevertheless, I've updated the wording of that sentence to be more clear.
ReplyDeleteNB: I'm both a DD and a MOTU.
"Your comparison sucks" ;)
ReplyDeleteIt can't be X users per Y developers with commits right. It's a non sense from a statistical point of view.
The work done in Debian benefits to Ubuntu directly (merge requests is just an example).
Hi Luke,
ReplyDeleteI know you guys work really hard on your releases but it seems like users who really try to go the extra mile to report bugs as early as possible get ignored by you guys.
For instance: 619841 bit me and others hard on Maverick. It was a system breaking bug for people who suffered from it and it was files almost immediately after it crept into your kernel version. Yet it didn't see any attention before the release. If September is too late to report bugs for an October release, then you shouldn't be making kernel changes in September.
Regards,
Alex
There's testdrive in the archive so that people can test the latest release or various other things in a virtual environment without taking the plunge of upgrading.
ReplyDeleteAnd do those 12M users use universe at all, by the way? And how much people are working on main? And how much people are paid to work full time on main?
ReplyDeleteSorry but a release that sucks is not the result of an insufficient number of developers. It is the result of bad design decisions. This was not the result of insufficient testing: everyone who tried the betas could see this would be the worst Ubuntu release ever.
ReplyDeleteSince the decision to pick Unity as the default desktop, you’ve been the laughingstock of developers. Now that it’s been released, you’re the laughingstock of users. Is it really a surprise? It always works like this in companies: your boss makes a bad decision, and you have to assume for it.
Sorry, but We ship software to 12 Million Ubuntu Users with only 150 MOTUs who work directly on the platform. is still plan wrong, when 60% (same footnote as yours apply here) of Ubuntu universe is sync'ed without a change from Debian.
ReplyDeleteMy worst experience with ubuntu and bug triaging is when people report a bug, you fix it, a new final release sees the light of day, months pass by, then people appear and starts claiming the bug still exists, refusing to tell which version of the software or even ubuntu they are running..... They demand a fix, while you try to explain that it's definitely already fixed.... finally they reveal and confess that they are infact running an ancient release which is not a LTS release......
ReplyDeleteThis is ofcourse only one story... most of these stories drown in the swarm of completely useless comments on launchpad which more seems like a chat forum then a bug reporting system.
Sorry Josselin but I respectfully disagree with you. I'm a developer (of a photo downloading app) and I really enjoy using Unity. I have been using it for some months and it's really grown on me to the point where it is painful to use anything else.
ReplyDeleteLuke one thing I personally find a bit challenging is that it takes a pretty high level of skill to be able to report a bug in the right way so that it has a fighting chance of being fixed. That is true even for things that are visible regressions or obvious bugs. For instance I reported this bug shortly after natty alpha 2: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/713478
But an obvious problem is that I have no clue as to what the cause is. So all I could do was report it against the kernel, which probably isn't all that helpful. Subsequently I wasn't surprised to see that it's not yet been fixed.
It is a problem with the way Ubuntu is developed - testing development releases is quite disruptive to a user, requiring a reboot with a live CD or USB, a working VM setup, spare hardware, or a risky upgrade of the main system to a probably broken development release. And the fact that once a release is out, it's instantly dead and bugs are never fixed in it means you can't take advantage of how regular users test and find bugs.
ReplyDeleteHi,
ReplyDeleteJust like Alex, I've had bug reports ignored for months on end.
Bugs in relatively importants things like mountall.
Whilst I appreciate that Ubuntu is inundated with bugreports, I've found that most of mine go into a void and are only looked at by developers after a release. Or two.
And I'm a bug reporter happy to test pre-release things and/or build from source if required.
I think an improvement would be to highlight the karma of bugreporters; presumably those with higher karma scores are more willing to interact with people and help to diagnose issues.
I think if you are just counting MOTUs inside the Ubuntu fenceline, you are missing a big part of the story.
ReplyDeletehttps://wiki.ubuntu.com/UbuntuDevelopers
Look at all those different teams with commit access that are not MOTUs.
Also you've sort of inadvertently implied that MOTUs handle everything from the kernel on up and are accountable for things like hardware regressions. Which is probably a bad thing to do, as you are laying tons of bugreports at the feet of the MOTUs that they don't have the authority to deal with. Already you've grown a couple of comments about hardware related bugreport handing.. that is absolutely outside the scope of anything MOTUs can redress. In all likelihood the packages the MOTUs are primary for in Ubuntu are probably the least problematic packages for users.. just due to the nature of the fact that MOTUs primarily shepard working packages from debian into Ubuntu. How many packages under MOTU mandate are considered release critical for Ubuntu? Any of them?
Can anyone actually get an accurate headcount the number of pepple with package commit rights for the packages that feed into an ubuntu release in launchpad? Without getting into the nuances of merges with debian... just taking the dozens of teams defined in launchpad who each have some sort of packaging commit rights to some section of the repository and making a simple union. Can launchpad even do that as part of high level project oversite for Ubuntu?
And related question how much of the Ubuntu binary packaging falls to MOTUs mandate versus how much has a deligated maintainer or team as per the wiki page I posted?
-jef
Test drive is a pretty handy tool. I wish more distros had something similar. Ubuntu is already pretty easy to test, as the development versions generally are fairly bug free. Fedora rawhide can be uninstallable for long stretches of time.
ReplyDeleteFrom my experience the bug thread looks like:
ReplyDeleteUser0: hey, there ia a bug
User1: i confirm
Developer: oh. Looks like a bug will fix it until release
Developer: we failed to fit it window, potponing until next release
Users: we have the bug! How to workaround?!
Users: anyone?
Developer: we failed to fix it.. Postponing it again to next release
...years passed..
Users: the bug is there for two-three LTS releases!!!
Developer: we'll fix it
Personally I've faces 5-10 bugs that were not fixed since 2010-2012...
So what is the point to run development releases if bugs are not fixed even for LTS?
What is point in long-term-support if there is no support?
I think it would be easier to test the next release if we released an installable image early in the release cycle — like we used to, and like the other Ubuntu flavours do.
ReplyDeletePerhaps we allow people to put up a bounty to get a bug fixed. If a bug is bothering me I can offer $50 to get it fixed (like voting for bugs usind $$) or get others to chip in a few dollars--payable at next release which includes fix and refundable if it regresses. Karma should be applied to those who don't pay up in a timely manner.
ReplyDeleteMostly I see this as a way to fuel money into the developer community already working on these things. It's unlikely someone new is going to fix a bug for a few $$ but that could happen too. We tend to like our Free software a little to free.