Loading…
Gorhill is a busy bee, what to do? #1419
8 participants
Very well said. I agree and disagree.
From what I have read, it sounds like gorhill created uBlock for his personal needs, and was very generous by choosing to share his creation with the world (thank you gorhill!). The issue tracker got tiresome for him (not uncommon for programmers to want to just program), and so the transfer and fork ensued.
As you mentioned, the primary disadvantage of two or more different forks (technically a master and forks) is that there is more workload to add the best features and bugfixes to each fork (especially if incompatibilities arise). Also, one fork can start to lag behind the other. It can be very difficult for users to know which is the best fork to select to suit their needs.
But there is an advantage to forks as well, especially since gorhill developed this tool for his personal use. The forking process allows other developers to include features that gorhill may not want, but that many people have been requesting. Immediately coming to mind is an improved UI, filter hit counting, shortcut keys / toolbar buttons for commonly used features, filter source indication in the log, ability to quickly toggle uBlock on/off, and discrete groups for the 'My filters' section.
Whether or not there are multiple uBlock's, I think most people will agree that removing non-bug site-specific filtering issues from the primary git Issue Trackers will serve everyone well. Since uBlock often is configured to combine multiple 3rd-party lists, a separate place to submit those (on git or elsewhere) would separate the wheat from the chaff and make everything easier.
Whether or not there are multiple uBlock's, I think most people will agree that removing non-bug site-specific filtering issues from the primary git Issue Trackers will serve everyone well.
I recommend Discourse for that.
@Gitoffthelawn It's true that forking allows alternative features to develop. And I strongly agree that Chris's GUI is cleaner and better laid out (especially the new local/global icons, re-ordered filter columns, removal of the cluttered site-specific feature blockers at the bottom of the main popup, etc). The issue is that Chris is 17 and is busy with school, and didn't deserve to be saddled with a massive open source project. Heck, I would jump in to help if I had any time. Because at the rate that Gorhill is pushing features and changes, it needs a whole team to keep up and merge the relevant changes into this version of uBlock. But why waste all that energy?
If the projects merge (even if it means losing a few of Chris's UI improvements), all those problems would vanish, and both of them can relax. I honestly don't think Chris can keep up for much longer, and that's no slight against Chris. He's a skilled coder, but nobody deserves to have their free time entirely consumed by this at age 17. Think of all the other things that should be going on in life at that point: School, family, friends, girlfriends, being outdoors and enjoying the summer, working on your future, and so on. It's not fair to Chris to let the situation continue like this.
@nyuszika7h Indeed, discourse is really good. I suggest setting up a separate forum for filterlists and insta-closing all filter related issues and referring the person to submit it to the separate forum instead.
In my opinion, step one to solving this mess would be for Chris to create a "uBlock Developers" GitHub Organization to manage this repository - and I honestly don't know why this hasn't been done yet. (Or why gorhill didn't do that instead of transferring the project...)
Add some other people to help clean up the issue tracker (I would volunteer, if needed) and (if they want) add gorhill and AlexVallat and give them commit access.
I don't see why uBlock needs to be a one man show and I don't think this was what was intended with the transfer.
If someone wants to be left alone, then he's free to do so on his local computer - even when one wants to work with git. There's no need to work on github.com. Just install a local copy of git (https://git-scm.com/) and you are done. No need to push to the web.
Don't get me wrong, it's great that this software got shared, thanks to all authors, but the "He wants to be alone" argument is just not valid.
I vote strongly for merging again!
The situation at the moment is annoying. Lots of end users might get confused about which adblocker they should use. Adblock Plus? Or Adblock? uBlock? uBlock Origin? μAdblock? (Yes, there is an extension called μAdblock to complete this confusing picture).
They all have similar goals.
So everything you can do to reduce diversity would be much appreciated.
Some suggestions:
- Instead of having two competing branches with one main contributor each, create branches "uBlock" and "uBlock experimental" where everyone of the development team has equal responsibility. This way it's clearer what's the difference between the two branches.
- Split uBlock into a core and an UI part. So that you can easily create a fork with a different UI but without the side-effect of diverging feature-wise.
I commend Chris for making his YouTube Video on this matter. It seems like the original developer had a problem with the oss idea and Chris will need a lot of help maintaining and improving the Project on his own. Even if this issue looks like general chat, it is a problem with the project's repository and future.
Split uBlock into a core and an UI part. So that you can easily create a fork with a different UI but without the side-effect of diverging feature-wise.
I absolutely love this idea. It makes perfect sense. Have a blocker core, and have a GUI on top, which would allow Chris to have a single, easily maintained repo with GUI changes.
I also love how easily this would be implemented. Take gorhill's version as the "master" branch, split that into MVC (Model, View, Controller), where view = the GUI, model = data storage/algorithms, controller = the glue passing values between the view (GUI) and model. It's a design pattern that evolved to simplify development and make it easy to create cross-platform software by simply swapping the view/controller to the appropriate platform-specific GUIs, while keeping the core (model) identical.
The GUI / controller would simply call the appropriate model-functions it needs for setting up whatever features it's using out of the ones available in the core, and then display the data in the way the GUI wants to.
The great thing that would come out of such a split of the uBlock core is that it would allow easy development of experimental GUIs with radical new changes, just to see if they make sense or not. It would also mean that there's a single, high-quality core to deal with, and two main GUIs with differing feature sets and design goals.
What's needed is @gorhill's blessing, since he's the original author and still the main developer and it would be pointless to try to go ahead without discussing with the master.
It seems like the original developer had a problem with the oss idea
That's quite a troll comment.
That's quite a troll comment.
Yeah, I reacted to that too, considering you've released the source on github, all commits are public, you collaborate with others, etc. You're open source all the way.
Anyway, Raymond... what's your thoughts on either A) merging (something that Chris has repeatedly expressed a desire to do; and simply throwing away any GUI changes you disagree with), or B) making the project MVC which decouples the GUI from the core, so that there's a single, shared blocker core which allows you and Chris to easily test out alternative GUIs. Unfortunately, C) do nothing, would mean that our young man Chris is soon going to burn out just as hard as you did. :/
I was looking at Gorhill's commit history and was shocked to learn that he's pushing on average 5-10 commits per day right now: https://github.com/gorhill/uBlock/commits/master
Feeling sorry for Chris who has to try to keep up with all of that and see what is relevant for merging. Especially since he's busy with school.
@gorhill Is it still out of the question to merge the projects again? Forking just divides the available programmers and wastes resources and leads to twice as much burnout. I know that you don't want to deal with the issue tracker, but how about letting Chris deal with responding to issues and you can sit back, relax and code? The slight division in features is still small enough to make merging easy. How about resolving this before it gets really tough?