In-Fighting Continues Over Mir On Non-Unity Ubuntu

[Akka]

Upstart is not only used on Ubuntu. Debian still uses it and Red Hat, Centos, etc. too. OpenSUSE has it in their repositories. Chrome OS does use Upstart too.

If I remeber correct Debian got systemd before they got upstart, default is sysvinit. A succceful device with upstart is amazons kindle.

[intellivision]

- when you have adopted those patches upstream, the upstream devs must take care of them, no more the canonical's devs.
- because Mir is a canonical solution, how the upstream can check if future development break the Mir compatibility or add regression without properly testing? So the kwin devs must install ubuntu only for check that?

Wrong. So wrong. It never becomes 'just' upstream's job, Canonical would be under a commitment to assist in testing and bug fixing.
If the code would be unmanageable, they could easily rip it out. Canonical also retracted the statement saying Mir would be protocol agnostic.
If you're going to make a point, at least get your facts straight.

[mrugiero]

Wrong. So wrong. It never becomes 'just' upstream's job, Canonical would be under a commitment to assist in testing and bug fixing.
If the code would be unmanageable, they could easily rip it out. Canonical also retracted the statement saying Mir would be protocol agnostic.
If you're going to make a point, at least get your facts straight.

First, it's hard to get anything straight if they keep changing their versions. Not trying to start a flamewar, just pointing it out. I had a lot of confusion about the subject because of this, until someone from my LoCo send me a few links to a G+ notes series about it.

Also, it's not 'just' upstream's job, OK, but still, they need to test before making any changes. Who will do that? And what makes you think there will be such commitment? I'm not sure I read anything about that. I'm not even sure if Mir devs are willing to write this patch, and Kubuntu maintainers already stated they don't have the means. And that's pretty much everyone that could be interested in making such port.

I give you the point that it's easy to rip out (at least, if they use a somewhat modern version control system, it should be easy), but what's the point on accepting them in the first place, then?

[Delgarde]

I give you the point that it's easy to rip out (at least, if they use a somewhat modern version control system, it should be easy), but what's the point on accepting them in the first place, then?

Well, no - even on a good VCS, it's hard. It's not just a matter of reverting the original commits that merged the patches - it's about untangling all the subsequent changes that have been made to the entire project over the time between those original commits, and when someone decides to drop the unloved Mir support....

[intellivision]

Well, no - even on a good VCS, it's hard. It's not just a matter of reverting the original commits that merged the patches - it's about untangling all the subsequent changes that have been made to the entire project over the time between those original commits, and when someone decides to drop the unloved Mir support....

Even then, if your code is written well and with modularity in mind this would be even less of an issue. I have no idea what the current state of KWin is at the moment so I can't attest to whether this would be appropriate for that particular project.

[Delgarde]

Even then, if your code is written well and with modularity in mind this would be even less of an issue. I have no idea what the current state of KWin is at the moment so I can't attest to whether this would be appropriate for that particular project.

Sure, if the code is well structured, that makes it easier. It probably isn't all that clean (in this respect, at least), since until Wayland came along, there was never a requirement to support anything but X. The question is how much restructuring they've now done to support Wayland.

[TheBlackCat]

Sure, if the code is well structured, that makes it easier. It probably isn't all that clean (in this respect, at least), since until Wayland came along, there was never a requirement to support anything but X. The question is how much restructuring they've now done to support Wayland.

A lot, the whole system has been modularized.

The problem is that the kwin time has been burnt several times by people adding great new features, but then not maintaining them. The kwin developers were ultimately left with no choice but to drop those features, resulting in a lot of outcry from users about regressions.

The kwin team now has a strict policy of not accepting any code they are not willing to maintain themselves. This is not an attack on Mir, it was a policy long before Mir was announced. But they are not going to change it for Mir.

Just think about this in practice. kwin accepts Mir patches. Kubuntu uses kwin patched with Mir. Mir developers stops maintaining the Mir backend. kwin developers drop Mir backend. Kubuntu dies overnight. Do you really think there won't be attacks against the kwin developers from Kubuntu users? Given the outcry when much smaller features were dropped, it is pretty much certain there will be. Why should the kwin developers set themselves up for that?

[dh04000]

The kwin team now has a strict policy of not accepting any code they are not willing to maintain themselves. This is not an attack on Mir, it was a policy long before Mir was announced. But they are not going to change it for Mir.

Just think about this in practice. kwin accepts Mir patches. Kubuntu uses kwin patched with Mir. Mir developers stops maintaining the Mir backend. kwin developers drop Mir backend. Kubuntu dies overnight. Do you really think there won't be attacks against the kwin developers from Kubuntu users? Given the outcry when much smaller features were dropped, it is pretty much certain there will be. Why should the kwin developers set themselves up for that?

With that reasoning, kde shouldn't accept patches or software from anyone. Even many of the people whom on the project, becuase they may leave and stop maintaining that peice of software. If they won't accept software from the MIR dev's, the ones best able to develop and maintain this particular peice of software as MIR developes, and most moivated to see it included, then they might as well close thier doors to any outside inclusions. Becuase that's exactly what they are doing.

Please read 3 time more responding, think atleast 60 seconds, and take deep breathes while counting backwards from 10 before responding to this post.

[TheBlackCat]

With that reasoning, kde shouldn't accept patches or software from anyone. Even many of the people whom on the project, becuase they may leave and stop maintaining that peice of software. If they won't accept software from the MIR dev's, the ones best able to develop and maintain this particular peice of software as MIR developes, and most moivated to see it included, then they might as well close thier doors to any outside inclusions. Becuase that's exactly what they are doing.

Please read 3 time more responding, think atleast 60 seconds, and take deep breathes while counting backwards from 10 before responding to this post.

A few problems with your reasoning:

1. I said "kwin", not "kde". They are not the same thing. kwin, being a core piece of the KDE workspace that is extremely complicated and hard-to-understand, needs different standards than a less central part of the software compilation, so the rules are different.

2. There is no rule that they won't accept patches at all, just that they won't accept patches they aren't willing to maintain. So if someone creates a patch that improves an existing part of kwin, or even creates a new part that they are willing to maintain, the patch can be accepted. It is only if the patch adds new parts that they aren't willing to maintain that will be rejected.

3. There is a difference between an established member of a project with a history and demonstrated reliability submitting code and someone with no history with a project and a track record of suddenly abandoning projects submitting the same code.

4. This is their decision, not mine. If you think it is stupid tell them that. I am not sure what you think lecturing me will accomplish.

[erendorn]

With that reasoning, kde shouldn't accept patches or software from anyone. Even many of the people whom on the project, becuase they may leave and stop maintaining that peice of software. If they won't accept software from the MIR dev's, the ones best able to develop and maintain this particular peice of software as MIR developes, and most moivated to see it included, then they might as well close thier doors to any outside inclusions. Becuase that's exactly what they are doing.

Please read 3 time more responding, think atleast 60 seconds, and take deep breathes while counting backwards from 10 before responding to this post.

Did you "read 1 time more posting" your message?

Their policy is "kde doesn't accept patches that they would not accept to maintain themselves". That addresses your first two sentences (as to why some software are accepted).
As for the rest, yes, Mir devs are the best suited to support Mir stuff. Nobody questions that. The problem is that they are the only ones. Both the only one able to, and the only one interested in it.

So, as long as this is the case, what prevents Canonical from maintaining external patches, and what are the drawbacks for not having them upstream?