Wayland/Weston Gets Forked As "GH-Next"

[FreeBooteR69]

Wait, wasn't Ubuntu doing exactly that?

---

Personally I find this idea huge waste of effort.

It would be a lot nicer, if the guy just did one single post describing all contributions he made, time and effort it took to submit and reason why there were not accepted.

That would place the ironsights exactly on the problem.


Instead ... effort has split, and we have just another graphics system,.. wonderful for confusing beginner contributors and distro developers.
I am not criticizing him though, its still a decent decision.

So who's time and effort is he wasting? Is his time and effort yours?

[Delgarde]

Again as I said in my initial post I totally understand where he is coming from. Your last sentence highlights the huge problem with FOSS currently and is what's causing his and others such as myself frustration. Unlike the pretty picture of community based open source projects that is told to young software developers at bed time the real landscape for most FOSS projects is a bunch of commercially backed gatekeepers who like you say have their own priority which is working on what their employer tells them to. This makes sense why would you pay someone to review patches that don't directly benifit your company, but highlights the need to balance projects better with both community and commercial maintainers.

That's one way of looking at it, sure. But it's also true that projects can't just meander along in every direction, accepting every patch that comes their way. People are already complaining that Wayland is slow to progress - do you think they'd be moving quicker if they were less selective - if they wasted their time merging in stuff that's in the "nice to have" category, but somewhat disruptive to the ongoing work on the "must have" stuff?

You're seeing it as a commercial thing, but it's just basic project management. You can't do everything at once, even if people are willing to help.

[Siekacz]

Do you see what just happened on #wayland? Wayland dev's just are destroying the project from inside.

[timothyja]

That's one way of looking at it, sure. But it's also true that projects can't just meander along in every direction, accepting every patch that comes their way. People are already complaining that Wayland is slow to progress - do you think they'd be moving quicker if they were less selective - if they wasted their time merging in stuff that's in the "nice to have" category, but somewhat disruptive to the ongoing work on the "must have" stuff?

You're seeing it as a commercial thing, but it's just basic project management. You can't do everything at once, even if people are willing to help.

This is going to be my last post on the matter because you continue to miss my point. You can get things done faster if you have more contributors, its much quicker to review a patch than it is to write and debug everything yourself. Turning away people willing to contribute who could be upskilled enough to become maintainers themselves is just madness. You talk about basic project management then say you cant do everything a once. My point is that some opensource maintainers are trying to do just that, they are trying to take the full load on themselves rather than spreading the load. Basic project management is delegation of tasks and not trying to do everything yourself, the sign of a bad manager is someone who tries to do all the work of the team on there own and does not properly utilise the available resources.

What I'm seeing as a commercial thing is that the "must have" stuff is decided by the maintainers and their commercial backers so the "must have" for them might be very different from what's must have for you and me. A perfect example is a Glib patch that I wrote so that the GTK filechooser would finally respect .hidden files this also removed the need for separate code in Nautilus to handle the files (or any other GTK based filemanager for that matter). The patch sat there for a while and I received feedback from the devs but it wasn't until another commercially backed dev was trying to implement the same feature in a more hacky way that the maintainers said hang on we have this patch here and BAM it was committed.

Maybe I'm just a cynical idealist by I really believe FOSS projects could benefit greatly by fostering would be contributors better, while having more community only maintainers to help focus on contributions that are not on the radar of the commercial maintainers.

Edit: To directly answer your question yes I think it is a great investment to looking at the patches of would be contributors even if they are just nice to haves. Boosting a projects manpower by sacrificing a small amount of short term time will pay off greatly in the long term as I've said continually its about project management and managing all available resources effectively not just turning people away because you think you can do it faster/better on your own.

[blackiwid]

Maybe I'm just a cynical idealist by I really believe FOSS projects could benefit greatly by fostering would be contributors better, while having more community only maintainers to help focus on contributions that are not on the radar of the commercial maintainers.

I mean I would be glad if somebody would help me with my small projekts, but as example I programmed a curses based youtube-playlist-generator-mplayer-wrapper ^^ and somebody would send me patches to make it a grafical thing that is very mouse-focused, I would not patch my programm too. maybe I would add a additional script, but only if it would not change my api to the functions. If I then would change the api of my functional code I am not shure that I would want to make additional changes for the other tool. So in fact it would be better to make a fork of my thing. and if possible we would work together on a lib-backend-stuff and use it for our both things.

I even think myself if I will change the interface another time, have some prototypes and even with that I think of forking my own project. because its just simpler if you want to release it, to not have 20 clients updated to new apis and have tests in a folder for 20 clients and its also more decoupled if you have a seperate lib-do-backend-stuff.

So I totaly understand when a developer dont want additional work for something he dont want to have.

The bigger, and the more complex a tool is, it gets more difficult to make often releases. More Code = more (potential) for bugs. If you dont want to break something you have to make bigger patches the more code you have.

[timothyja]

I mean I would be glad if somebody would help me with my small projekts, but as example I programmed a curses based youtube-playlist-generator-mplayer-wrapper ^^ and somebody would send me patches to make it a grafical thing that is very mouse-focused, I would not patch my programm too. maybe I would add a additional script, but only if it would not change my api to the functions. If I then would change the api of my functional code I am not shure that I would want to make additional changes for the other tool. So in fact it would be better to make a fork of my thing. and if possible we would work together on a lib-backend-stuff and use it for our both things.

I even think myself if I will change the interface another time, have some prototypes and even with that I think of forking my own project. because its just simpler if you want to release it, to not have 20 clients updated to new apis and have tests in a folder for 20 clients and its also more decoupled if you have a seperate lib-do-backend-stuff.

So I totaly understand when a developer dont want additional work for something he dont want to have.

The bigger, and the more complex a tool is, it gets more difficult to make often releases. More Code = more (potential) for bugs. If you dont want to break something you have to make bigger patches the more code you have.

I never said a project should just accept any changes. My point is you should encorage people who are interested in your project, tell them clearly if somethings not acceptable such as api changes. Most importantly put a proirty on giving feedback and integating the patches that are a good idea and improve the project.

[timothyja]

The bigger, and the more complex a tool is, it gets more difficult to make often releases. More Code = more (potential) for bugs. If you dont want to break something you have to make bigger patches the more code you have.

This is a separate issue. Patches can often mean less code, as lines are removed and replaces with better code. If you need to make bigger patches to work around your code it sounds like poorly designed code to me. There are plenty of methodologys and design patterns to avoid this type of thing happening. Not to meantion unit tests, etc

[blackiwid]

This is a separate issue. Patches can often mean less code, as lines are removed and replaces with better code. If you need to make bigger patches to work around your code it sounds like poorly designed code to me. There are plenty of methodologys and design patterns to avoid this type of thing happening. Not to meantion unit tests, etc

yes its maybe poorly designed code, but if you have designed your code perfectly you make no api changes in the future, you only add stuff.

So even on the linux kernel, sometimes they replace a part and as example they need to change than all drivers to work with the new abi.

if its very simple each retard can do that changes, but still you have to search through the files etc.

But the kernel devs also dont integrate all stuff, k their goal is to support as much as possible devices, and if there is somebody who is willing to manage the stuff and the quality of the code is good enough, they integrate it.

But they will not integrate wayland into the kernel, if somebody things thats a good idea. its a bit like what this guy wants to do.

I mean ok go ahead, fork it, its no big deal. But dont blame the x-server-replacement-guy that he want not integrate a full window-manager.

Weston is for him only a toy to demonstrate stuff and to test stuff. its a bit like a unit test. not really but kind of ^^

if somebody wants to make a real windows-manager out of weston go ahead fork it... but why does he also fork wayland now, I dont really get it.

[timothyja]

if somebody wants to make a real windows-manager out of weston go ahead fork it... but why does he also fork wayland now, I dont really get it.

He explains in his post to the list: http://lists.freedesktop.org/archive...ch/008131.html

"The key point to understand is, that this is not a new protocol in its
own right. It *is* the wayland protocol, with a few minor additions
that make it possible to do new interesting things."

and

"Again, to make it clear, Northfield only adds some very basic and
necessary protocol that does not exist in Wayland, such as minimize.
It is the same in every other way except the new name."

But the kernel devs also dont integrate all stuff

Again I was never said they should integrate every patch, but should give feedback to willing contributors. Which is talked about in his post also.

"I am making it my own personal goal to acknowledge patches within 24
hours from the time of submission. This acknowledgement will indicate
a clear 'yes' or 'no' as to whether or not the patch(es) are desired
for inclusion to the relevant repositories. In either case, I will try
to include a clear reason for 'no' or possible additional comments for
'yes'."

[renox]

Do you see what just happened on #wayland? Wayland dev's just are destroying the project from inside.

Uh? You know not all of us spend our time monitoring #wayland, reading the wayland's mailing list is time consuming enough :-)
The emails doesn't show that "Wayland dev's are destroying the project from inside", there are some disagreements of course but that's 'normal'.