| |||||||||||||
Canonical Goes It Alone with UnityCanonical Goes It Alone with UnityPosted May 15, 2010 13:55 UTC (Sat) by paulj (subscriber, #341)In reply to: Canonical Goes It Alone with Unity by drag Parent article: Canonical Goes It Alone with Unity
As long as they stick with improving something then I am happy about it. Let the kernel heavy hitting, GNU userland stuff, and other stuff get done by people with much more expertise and desire. Canonical is better off expending there resources on something like this then anything else on the OS. Except those others then take great delight in bashing Canonical for not having, say, kernel-fs expertise.
(Log in to post comments)
Canonical Goes It Alone with Unity Posted May 15, 2010 15:47 UTC (Sat) by arjan (subscriber, #36785) [Link]
the expertise question is something else.
if you want to provide commercial support to server customers, you need to have expertise for basically all pieces in your stack. That doesn't mean you need people to develop proactive there (although that helps), but you need at least enough involvement that you can fix bugs....
... at least rather than filing them in fedora bugzilla (that was hillarious)
Canonical Goes It Alone with Unity Posted May 15, 2010 15:54 UTC (Sat) by ewan (subscriber, #5533) [Link]
Seriously? Have you got the bug number for that?
Canonical Goes It Alone with Unity Posted May 15, 2010 15:56 UTC (Sat) by arjan (subscriber, #36785) [Link]
Canonical Goes It Alone with Unity Posted May 15, 2010 18:17 UTC (Sat) by AlexHudson (subscriber, #41828) [Link]
Why is finding and filing a bug similar/the same as one you found elsewhere suddenly "bad practice"? Isn't it good they pointed out the fault also applies to Fedora?
Canonical Goes It Alone with Unity Posted May 15, 2010 19:32 UTC (Sat) by seyman (subscriber, #1172) [Link]
> Why is finding and filing a bug similar/the same as one you found elsewhere suddenly "bad practice"?
Because filling in bug reports against 200+ distributions is an immense waste of time, both for the reporter and the people doing triage on the 200+ bug trackers. Once you're able to reproduce the bug with an unpatched upstream, I think it's safe to consider all distributions to be suffering from the problem and filing a bug upstream should be the only thing you need to do.
Note that Fedora has a policy that all upstream bugs should be taken care of in the upstream bug tracker. That's why bugzilla.redhat.com has an UPSTREAM resolution and that's why this bug was closed with this resolution. The only thing filing it accomplished was wasting people's time.
Canonical Goes It Alone with Unity Posted May 15, 2010 20:38 UTC (Sat) by paulj (subscriber, #341) [Link]
Kees also filed an upstream bug and the very first line of his Fedora bug report points to the kernel.org report, which points again to the Ubuntu bug.
I see your point that the posting to the Fedora bug-tracker was redundant and perhaps wasting people's time, so far as Fedora's processes go. However, it does NOT seem like Kees was trying to sneakily get RedHat to work on Canonicals' bugs. All it looks like is that he's trying to raise awareness amongst the relevant technical people about a fairly serious ext4 performance regression, in an open, technical manner.
So the "Go fix your own vendor bugs, nyeeh nyah!" responses still don't sit quite right with me.
FWIW, I'm a general free Unix/Linux user. The logos and branding on my preferred Linux distro say "Fedora", but the software I use is maintained by engineers/hackers from a *variety* of vendors, including Canonical.
Canonical Goes It Alone with Unity Posted May 16, 2010 4:18 UTC (Sun) by jspaleta (subscriber, #50639) [Link]
While I would never assume that Kees had anything but the best intentions when posting a duplicate to the Fedora issue tracker, its advisable to read over the timing of comments in the launchpad bug to get a feel for what's going on.
2010-03-21 : Launchpad bug filed 2010-04-14 : Comment from Ted Ts'o https://bugs.launchpad.net/ubuntu/+source/linux/+bug/5436... 2010-05-04 20:36:58 kernel and Fedora bug filed.
I would dare say that Ted's comment actually sort of encouraged, indirectly, Kees to do the additional posting in the hopes of getting Red Hat engineering resources interested in solving the problem on a mutually beneficial timescale.
Though I do sort of have to wonder why it took 3 weeks after Ted Ts'o to confirm it was happening with an upstream kernel for the upstream kernel report to be filed...and only after the Ubuntu specific workaround was found to be insufficient.
-jef
Canonical Goes It Alone with Unity Posted May 16, 2010 9:12 UTC (Sun) by paulj (subscriber, #341) [Link]
The reason it took 3 weeks appears to be because that's around how long it took Kees to come up with a general-case demonstration of the bug. You really have to stretch a bit to argue that Kees was acting in any way other than as someone trying to work out the technicalities of the bug, and just trying to get other technical people interested in the problem, on that basis alone. And if you look at the upstream bug various people (from various vendors) discussed it.
Isn't part of the benefit of Linux that it provides a way for commercial organisations to work semi-mutually to further the interests of *shared* code.
Again, these accusations appear less than solidly founded. It surely can not be good to start creating an atmosphere where people are afraid to talk to other developers of a project about a bug just because they work for a different vendor.
Canonical Goes It Alone with Unity Posted May 17, 2010 0:50 UTC (Mon) by bryce (subscriber, #16388) [Link]
"Again, these accusations appear less than solidly founded. It surely can not be good to start creating an atmosphere where people are afraid to talk to other developers of a project about a bug just because they work for a different vendor."
If you're looking at this and merely seeing evidence at attempts to collaborate, well that's hardly fun and interesting. Try harder to blur the facts around to support some sinister conspiracy theory. That is a LOT more interesting, and sells a lot more ads. This whole talk about thinking from solid foundations is plain silly; everyone knows better than to do that.
But whatever you do, DON'T just go talk to the developer directly to get the actual facts. That makes it a *lot* harder to maintain all the lovingly crafted anti-Canonical memes we've got. Next you'll be saying Kees contributes to upstream or some other madness like that.
Canonical Goes It Alone with Unity Posted May 15, 2010 16:41 UTC (Sat) by paulj (subscriber, #341) [Link]
It isn't. Drag was suggesting different distro vendors could specialise in different areas. If a vendor specialises in a higher-level of the software stack, they will be dependent on those vendors who specialise in lower parts of the stack - marketing disaster.
I wonder can someone acquire sufficient expertise in some area of, say, the kernel fs to be able to quickly *fix* a problem without having or developing an inclination for developing that area. If they can't do that because their employer is focused elsewhere, they may move. I.e. a distro is either going to have to:
a) acquire its own broad-based expertise, replicating the expertise of every other major distro. I'm not sure this is scalable, but even if it is it may be wasteful.
b) work out agreements to get support from every other vendor
c) be at the mercy of those other vendors
Further, I have to say the public ridiculing by one vendor's employees of a another vendor for filing bugs with their *community* bug-tracker left a very bad taste in my mouth. Smacks of all the worst vendor tribalism of the old Unix war days.
If someone can replicate a bug on Fedora why shouldn't they be able to file them with Fedora if that's where the maintainers for that software are most focused on? Why should it matter /who/ files the bug? Shouldn't it be judged on its technical merit, as a record of fact?
Canonical Goes It Alone with Unity Posted May 15, 2010 18:36 UTC (Sat) by ewan (subscriber, #5533) [Link] If someone can replicate a bug on Fedora why shouldn't they be able to file them with FedoraBecause at the point that you can replicate it in multiple distributions it's clearly an upstream bug, not a Fedora bug. Besides which, I'm not sure that's the point - surely the problem is that Canonical is selling people contracts in which they agree to support Ubuntu, despite (apparently) not having the necessary expertise to actually do that. Would you buy a support contract from them if all they're going to do with the hard problems is file a bug with Redhat? That's an awfully expensive way to avoid having to deal with bugzilla.
Canonical Goes It Alone with Unity Posted May 16, 2010 10:36 UTC (Sun) by AlexHudson (subscriber, #41828) [Link]
Whether or not it's an "upstream" bug isn't really quite the point; having a distro-specific bug allows you to track the progress of that bug within the distribution and talk about when the fix was released for Fedora.
You wouldn't want to be doing this across the board, but to complain that someone has tested your distro for a bug and then filed it when they found it seems to be extremely bad manners to my mind.
Canonical Goes It Alone with Unity Posted May 20, 2010 7:59 UTC (Thu) by jschrod (subscriber, #1646) [Link]
"*all* they're going to do ... is file a bug with Redhat"?
AFAIR, Kees opened an upstream bug before. He included a link to that in his RH report.
FTR: I use neither RHEL, Fedora, nor Ubuntu on my company or personal systems; I use openSUSE. So I'm not partial about any party. But having read about that storm in the teapot, I side with Kees and find yours and others accusations distasteful, as they leave off a very important part of that picture: that a non-kernel developer wanted to raise awareness of a serious bug and went to great length to develop test cases and confirmed that it is an upstream bug by testing the problem on another distribution now gets flamed for all his activity.
Obviously he is only allowed do so after Canonical has hired more kernel developers. That's ridiculous.
Canonical Goes It Alone with Unity Posted May 26, 2010 21:32 UTC (Wed) by BackSeat (subscriber, #1886) [Link] Because at the point that you can replicate it in multiple distributions it's clearly an upstream bugNo. At the point when you can reproduce it with upstream source (as was the case here) it's clearly an upstream bug.
Canonical Goes It Alone with Unity Posted May 16, 2010 15:25 UTC (Sun) by acathrow (guest, #13344) [Link]
It depends on the motivation of the person filing that bug.
If the goal was to file the bug so Fedora could fix it then I'd say there was a problem. But the only person who knows the motivation is the person who filed the bz.
Canonical Goes It Alone with Unity Posted May 22, 2010 6:58 UTC (Sat) by riteshsarraf (subscriber, #11138) [Link]
Once upon a time there was a solo Linux vendor named Red Hat. Then, it did not have much competition. SuSE was small. Ubuntu was non-existent. Then came Novell and Canonical.
Novell changed the definition of "Linux Enterprise Product" and Canonical slapped all who said "Linux is not yet ready for Desktop".
In the early days, there was no problem because Red Hat served upstream and could not live without this "Community Users". These users were invaluable testers and bug triagers.
But things have changed now. Now, it is a TTM game. Every vendor, that finds a bug or a fix, preferably wants to keep it a secret until its release. All vendors effectively maintain forks and carry them for the entire lifecycle.
There does not seem to be a "Community".
There's also the war of "I be the upstream for everything I ship in my product". So, if you are not the upstream of something you ship, drop it, fork it, re-label it, re-invent it and then re-ship it.
It will be interesting to see how well and how long can the GNU/Lnux Community Model sustain going forward.
Canonical Goes It Alone with Unity Posted May 22, 2010 21:49 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
to many of us, redhat is not the 'early days' and while it grew huge, when it did so we remember problems of it not working with the community. the increased compeition of the last several years has improved redhat's behavior. the forks they carry for the kernel are significantly smaller than in the past for example.
Canonical Goes It Alone with Unity Posted May 22, 2010 21:56 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
There wasn't any 'forks' as such. Red Hat's model involves upstreaming code and backporting it for the most part and during the 2.5 days, it was larger and now it smaller. A major reason is the new 2.6 development model. Attributing it to competition when they seem to do significantly worse at upstreaming code seems odd.
Canonical Goes It Alone with Unity Posted May 22, 2010 22:02 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
during the 2.4/2.5 days there was real work being done at redhat that was not being upstreamed to the main kernel. There were very real fears that redhat was forking linux and going their own way. in the 2.6 development model they have moved away from that and are much better at getting their patches upstream and not doing things that make their kernel incompatible with the vanilla kernel.
I remember trying to run some commercial closed source apps and finding that they would only run on the redhat kernel, not on _any_ vanilla kernel because redhat had added features that were not upstream and never did go upstream
Canonical Goes It Alone with Unity Posted May 23, 2010 1:46 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Interesting claims but would be more credible with some references to specific features. Even more useful if you could show that the cause was not the development model.
Canonical Goes It Alone with Unity Posted May 23, 2010 2:05 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
anyone who tried to use Oracle in the early days of their 'linux' support will remember how it only would run on RedHat. I didn't pursue it far enough to figure out exactly which feature they depended on, but it was known at the time that it was a kernel issue, you couldn't replace the stock RedHat kernel with a vanilla kernel without applying redhat patches to it and have it work.
the new 2.6 development model was created specifically to address these sorts of problems.
I'm not saying that when RedHat implemented a feature they did so to deliberately lock users in to their flavor of Linux, but when the upstream developers went a different direction and didn't accept what they had already shipped to customers (and had companies like Oracle depend on) that's the effect that it had.
Canonical Goes It Alone with Unity Posted May 23, 2010 3:12 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
What you are saying now doesn't require a non-upstreamed kernel feature and since you didn't point out any specific feature, I don't think that was the cause. Red Hat upstreamed and backported several features from 2.5 series and maybe Oracle was depending on one of them. Since you aren't claiming that Red Hat was deliberating hoarding patches, it throws out the idea of competition having any effect. If you could show any case where upstream went in a different direction and that causing ISV's to depend on Red Hat specific features, I would be very interested to hear about that. In my understanding, there is no such case. If there was a pattern of such behavior, it should be trivial to point out a few of them.
Examples Posted May 23, 2010 15:26 UTC (Sun) by corbet (editor, #1) [Link] TUX is a clear example of a kernel feature shipped by Red Hat which was never upstreamed - or even attempted to upstream. I also had fun in the first revision of the driver book because there were RH-specific API features in their kernel.Whether competition has anything to do with any perceived changes is not clear to me, though. I suspect it has more to do with both the company and the communities it works in growing up.
Examples Posted May 24, 2010 18:30 UTC (Mon) by foom (subscriber, #14868) [Link]
A personal anecdote:
RH's non-upstreamed tux patches caused me pain recently(ish). Turns out TUX added a flag to the open syscall named O_ATOMICOPEN. It used the next available O_ flag value after those used in upstream kernels. That flag was not upstreamed. Upstream then added a flag to open called O_CLOEXEC. They (of course) also used hte next available flag value.
So, new binaries which attempted to use O_CLOEXEC (even when they attempted to test for its existence before using it) would fail badly when it returned some completely unexpected random error value...
Canonical Goes It Alone with Unity Posted May 17, 2010 22:06 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
Canonical Goes It Alone with Unity Posted May 17, 2010 22:07 UTC (Mon) by paulj (subscriber, #341) [Link] This blog post by Kees seems relevant.
|
|||||||||||||