5 ms·
> Weston, the reference Wayland compositor, is a test-bed. It's for the development of the Wayland protocol, not for being an actual desktop shell. We could hav
by AnIrishDuck 14y ago
> Weston, the reference Wayland compositor, is a test-bed. It's for the development of the Wayland protocol, not for being an actual desktop shell. We could have forked Weston and bent it to our will, but we're on a bit of an automated-testing run at the moment, and it's generally hard to retro-fit tests onto an existing codebase. Weston has some tests, but we want super-awesome-tested code.
I'd accept this as reason alone to go with Mir, assuming it's correct. My experience with window managers on linux has been riddled with constant bugs and regressions that are the hallmark of software that isn't adequately tested.
And he's absolutely right. If code isn't designed ahead of time to be modular and decoupled (testable), you're going to have a hell of a time refactoring it later to get good test coverage.
I'm not asserting Weston is these things. But, accepting what Christopher says here, Canonical might actually be justified in creating Mir. I'd especially be interested in hearing if someone can refute the mentioned point.
- ibotty 14y agokwin will be its own wayland compositor, gnome's mutter will be its own compositor. why didn't canonical create unity as its own wayland compositor? (in other words: criticizing weston is a strawman)
- deleted 14y ago[deleted]
- SEMW 14y agoThe section the GP quoted was not the entire article. Rogers went on to end the quoted paragraph with the rhetorical question "We don't want Weston, but maybe we want Wayland?", and went on to address that question in the rest of the article. Whether or not you agree with the chain of reasoning, pretending he never wrote anything other than a single step in it, and calling that a "strawman" on the grounds that it isn't a whole chain, is a little silly.
- lmm 14y agoHe's wrong. Refactoring existing code to make it testable is not easy, but it's a lot easier than rewriting it from scratch, and more effective too.
- fingerprinter 14y agoReally? Wrong? Perhaps you meant to say "it depends on the circumstances, the goals and current state of the other projects, but in my experience refactoring is a bit easier than rewriting"? If not, wow...blanket statements are rarely ever true.
- Ziomislaw 14y ago"If not, wow...blanket statements are rarely ever true." - this blanket statement is not true :) and yes, it is much easier to start from _something_ than from nothing
- fingerprinter 14y agoIf you'll notice, I didn't write a blanket statement. ;) I used the word "rarely". Agree that sometimes it is easier to start from something, but not always. Or, did you forget about Wayland and X? I mean, we are talking about that right now ;)
- AnIrishDuck 14y ago> yes, it is much easier to start from _something_ than from nothing I disagree. I have worked on multiple projects where the code base needed to be nuked from orbit and redone. You use the old code as a guide (which is what I'm assuming they're doing with Mir), but by the time you're done it's an entirely different codebase. It gets especially fun when you run into code that is almost certainly buggy; without tests to tell you what the old developer was looking for, you have to make an educated guess about fixing it. This kind of rewrite is far beyond a typical project fork. I don't know enough about Wayland or Weston to competently state if that's necessary here. I can just tell you I have done something like this before. Perhaps you're lucky enough to work with only disciplined, competent programmers. I have not had such luck in the past.