On Concerns about a Fork
People have asked me about Bluetile because it essentially ships with its own branch of XMonad. The concern, of course, is that we don't want to ship a fork that's so closely aligned without good reason. The less code we need to ship and the fewer packages, the less room there is for error, less load on our servers, and less for the user to worry about. I asked myself the same thing, but in the chance that bluetile could turn out to be its own thing entirely, i originally started the package review as a kind of wait and see what could happen approach.Even so, i had some of my own concerns. One of the patches Jan, the Bluetile developer, ships helps improve Gnome compatibility. Without it, XMonad is very hard to configure with Gnome. I repeated these concerns to him, but Jan's reaction is that he was intially unsure that all his patches would be accepted by upstream. I've noticed over the past couple of days on the XMonad mailing list, Jan has been pushing his patches one by one to upstream. So far, they are being accepted one by one, sometimes as is, sometimes with comments. Although i don't know exactly how far Jan has to go, it looks he's building a pretty good relationship with upstream, and i feel pretty confident the bluetile bits will all eventually find their way upstream.
Consider it another open source success story.
2 flames:
Hey, this is Jan. Thx for your continuing packing effort!
I think it's important to clarify something for those, who think of Bluetile as a fork: It's not!
xmonad is the core of a tiling window manager, xmonad-contrib is a bunch of addons. Bluetile is an integrated solution, that uses the core and various addons to build one specific tiling window manager - one with a gentle learning curve. It just uses a slightly modified core and some extra pieces, that are not (yet) in xmonad's mainline. But even if that changes and Bluetile can use xmonad's mainline some day, the need for Bluetile will not go away.
So the question is not: Should we package Bluetile even though it's a fork. It is: Should we package Bluetile while it still depends on forked versions of the supporting libraries.
And that's a good question to ask of course. The Debian maintainer of the xmonad packages has already said, that he would like to wait until the modifications are merged back. And I can totally understand if Fedora decides to do the same thing. On the other hand I'm of course excited to see Bluetile packaged as soon as possible to see if it has the potential to gain some traction. It might still be quite a while until the merging process is completed.
Speaking of which: Indeed, I'm pleasantly surprised how well the merging process comes along right now. However, it's just contrib stuff at the moment. The one patch to the core I submitted so far - the mentioned Gnome compatibility improvement - has not been accepted yet. It has not been declined either though - so we will see. :-)
Cheers!
Right, i should be more specific.
There's a fine line between a fork and a branch. Bluetilebranch does border a bit on it, since you're basically shipping it almost under a separate name.
I've said before, i think bluetile is a great piece of software, and i'm more willing to do the work to get it in, even if i have to resort to a couple of tricks. Packing it made me think about how we do a few things with packaging in Fedora, and since it wasn't too much trouble, it proved that we were on the right track too.
Keep it up!
Een reactie posten