Originally posted by brosis
View Post
Announcement
Collapse
No announcement yet.
Wayland/Weston Gets Forked As "GH-Next"
Collapse
X
-
Originally posted by timothyja View PostAgain 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.
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.
Comment
-
Originally posted by Delgarde View PostThat'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.
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.Last edited by timothyja; 25 March 2013, 08:08 PM.
Comment
-
Originally posted by timothyja View PostMaybe 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 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.Last edited by blackiwid; 25 March 2013, 08:12 PM.
Comment
-
Originally posted by blackiwid View PostI 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.
Comment
-
Originally posted by blackiwid View PostThe 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.
Comment
-
Originally posted by timothyja View PostThis 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
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.
Comment
-
Originally posted by blackiwid View Postif 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.
"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."
Originally posted by blackiwid View PostBut the kernel devs also dont integrate all stuff
"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'."
Comment
-
Originally posted by Siekacz View PostDo you see what just happened on #wayland? Wayland dev's just are destroying the project from inside.
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'.
Comment
Comment