Moving the Gitx project into its own Gitx organization

[nanoant]

@rowanj I would like hereby ask to move project to its own organization which may (in future) let other developers to join the GitX effort. Also we would have nice gitx.github.io page and so on and so on. Probably we could ask also @pieter and other forks developers to join.

WDYT?

[xpe]

@nanoant Can you find Rowan and other maintainers of other forks and contact them directly to see what they think? This sounds like a good idea to me, but they are doing the hard work, so I'd defer to them.

[xpe]

See also #259, Project Status, which goes into some detail about getting more hands on deck.

[pieter]

Let me know if there's something I can do

Sent from my iPad

On 11 mei 2014, at 23:06, David James notifications@github.com wrote:

See also #259, Project Status, which goes into some detail about getting more hands on deck.

— Reply to this email directly or view it on GitHub.

[nanoant]

I am pasting below mail which I have sent to you February.

Hello Pieter, Rowan, German and Eric,

I want to propose you all moving the project into GitX github organisation so it is possible to: (1) have sevaral maintainers (commiters) for organization (2) have github pages gitx.github.io (3) have central dmg downloads (4) reduce userbase fragmentation (5) fullfill dream of Eric :>

The following steps can be taken:

(1) Since Pieter is original author, he could create and own the organization (2) He can transfer original GitX project repo into GitX organization (3) He can make other authors as either owners or commiters (4) All other forks may shutdown with commits removing all files except README.md informing users that project has been merged into one at gitx.github.io (5) All forks may issue Sparkle update pointing to single gitx.github.io version

WDYT?

Final question why I am rising this. Actually I have already submitted several changes to Rowan fork, and I have more pending. And I am willing to update GitX on daily basis as well, as I am actively using it everyday.

[sugarmo]

:+1:

[claybridges]

@rowanj Hey, I sent you an email on this. I just wanted to check if you got it. Thanks.

[claybridges]

@nanoant Looks like there is already a @gitx user on github, though very inactive. Absent permission, etc. I'd figure that would preclude creating a GitX project with that id, but I don't know. GitX-org?

[claybridges]

Clearly, since I've raised this issue myself (#259), I'm :+1:. @rowanj's achievements are many, but the sad and confusing history of single-dev GitX instructs on the way forward.

[nanoant]

Let us try to contact @gitx and see if he wishes to give the name to our project, there's an option just to rename user, then creating organization should be rather straightforward.

[nanoant]

Well, after short investigation I can tell this user has not set any traces how to contact him up. Maybe I we try to contact GitHub crew and ask if they can rename this user?

[nanoant]

Thanks to amazing GitHub team @gitx was recovered and now it is an OSS organization with all previous fork authors being owners of it.

I have also migrated @rowanj website to Jekyll which should be available within couple of minutes (GH having some problems with hooks today) at gitx.gitlab.io.

So... next steps would be @rowanj moving his gitx project to @gitx organization account, since it is most recent and having issues open, so to keep these on new account it is best to move it rather than clone it.

Finally @pieter & @laullon would be gently requested to push some README.md only commits (removing all other files) pointing to new gitx.github.io.

Now waiting for @rowanj feedback! Of course he may be on holidays, since it is a summertime. But I think there is no rush.

[claybridges]

@nanoant Great work. Kudos & thanks.

[ngrilly]

@nanoant Thanks a lot Adam for having worked out that!

[sugarmo]

@nanoant Great work! Looking forward to the new @gitx.

[nanoant]

@rowanj Can you please update us with status of moving to @gitx organization? I hope this whole effort won't go to waste.

[claybridges]

Based on the evidence so far, it doesn't look like @rowanj will address this further right now. Some background:

• I create an issue (#259) on this in October 2013.
• @nanoant created this issue in January 2014.
• @nanoant sent email to Rowan and all of the major GitX release owners on this, quoted above, in May 2014.
• I've sent two unequivocal email pleas to Rowan for addressing this in the last month.

Rowan seemed to express some enthusiasm for a gitx/gitx project in the October 2013 thread, but since then, at least on github, crickets.

I think enough time has passed. I'm sorry to see things go this way, but it's probably time to schedule a fork of rowanj/gitx to gitx/gitx, and move efforts there. For obvious reasons, a project transfer would be much more desirable, but it's time to get the ball rolling regardless.

I suggest a date of 25 August for the fork.

Thoughts?

[tiennou]

Okay, I've been working on and off on cleanup and fixes and... stuff, y'now, so I'll give my thoughts.

I don't really care about the organization thing, I just want bug fixes and features ;-). Right now my only pain point that it causes is that there is a truckload of issue cleanup to do and I can't do anything about it because I'm not authorized to ;-). On the other hand, I can write code and PRs, and I trust @rowanj to merge them when they're nice and clean. This fits my bill.

We are now considering Yet Another GitX fork, which I feel like it already happened too much in GitX's history, and I really don't want to have to set up Yet Another GitX Sparkle Update Feed, and telling all users that this new fork is The One True GitX yadda-yadda. I. Don't. Like. That. Idea.

So here's what I'm thinking before we end up forking again :

1. we have to make sure all the current fork maintainers are agreeing to consider their current version "deprecated" (or whatever), but state obviously that there's a new org-supported version available that should be considered actual. This poses a problem given the breadth of big/small differences there are between version — I'm now using GitX (R) after being through GitX, then GitX (L), a little GitX (B), and I'm not even sure what's supported/missing in each anymore ;-).
2. we have to consider whether to choose GitX (R) as the new "base" GitX, or one of it's more feature-packed brethren. I'm a little sorry to say this but maybe it would be better to start from one of the more feature-packed version and work backward by porting the changes here to it — I imagine we'd have some work to do with bringing the code up to speed, but at least the features would be here. And this brings us to...
3. we have to decide how to handle libgit2. I'm wearing my architect hat here, but even though I like the idea of using library calls instead of NSTasking stuff, I'm wondering about how to handle compatibility on things that libgit2 doesn't handle yet — right now only the commits and branch are using that, the rest just passes CLI arguments around — and it's IMHO painful to reason about some things because GitX is built as a CLI-wrapper-with-a-GUI, not a Git "client" which libgit2 allows us to be (hope that makes sense). This also means that's there's C code to write ;-).

[claybridges]

@tiennou: Clearly, having put a little effort into trying to make the smooth transfer to an org happen, I hate to see yet another fork as well. But how long shall we wait?

The reason GitX has has such a crazy and confused history so far is the single-dev model. In the long run, solving that is far more important to the future of GitX than, e.g. which version to base it from. Having solved that, there will presumably then be an authoritative place to sort all the issues you bring up, including a path for clearing up issues more quickly. Right?

[tiennou]

Right, but I'm mostly concerned about the featureset we'll base ourselves on, since if feature blah is missing, people will continue using their dedicated fork. Maybe I'm going a little over-the-top about that whole "base" thing though, and we should base ourselves on GitX (R), so @rowanj can merge in our changes and still distribute new version. It just means a little more porting/rewrite work.

[claybridges]

GitX needs an org. It has advanced, and then floundered, too many times, in the hands of single developers. Any one person, working for free, will eventually run out of interest or bandwidth for handling what needs to be done next.

I don't really care about the detritus of forks left behind in the wake of such a move, because I am betting that GitX under an org will shortly become clearly superior. Having created a presumably community-driven version of GitX, let begin the technical arguments about what the future direction will be. If consensus cannot be made, then I guess the org will be a failure, and renames, or futher splintering, will be inevitable. But it's time to run that experiment, because the single-dev model has failed again and again to provide a long-term stable path.

I suggest rowanj/gitx is the GitX version with the most traction right now, and for that and probably many other reasons, the best starting point. Presumably, that's why this discussion is occurring here. If you think differently, give me a repository/branch you want to use and why. Regardless, I suggest we get past this ASAP, because at this point, it's far more important to start and move than it is to sit and think about how to move.

[claybridges]

@nanoant: Are you prepared to do this? Haven't we waited long enough for this to happen?

[tiennou]

Ok, let's use GitX (R) as a base then. It was just me bickering on some points ;-).

[nanoant]

Lack of single response from @rowanj is dissapointing. I wish to believe he has missed our mails that went into his spam box.

I am not eager to take any actions as I am right now on vacation. I'll be back on Sep 1st then we take next steps

[pipelineoptika]

@rowanj is currently extremely busy with work and life. I can't speak for him on this matter, but I do know he continues to be very interested in moving GitX forward.

I'll try and ping him at work tomorrow. I'm currently on holidays for another week and a half.

[claybridges]

@pipelineoptika If you have an inside line, please give it a shot. Transfer beats fork, handily.

Based on @nanoant's schedule, it looks like the soonest an "ok, time to give up" fork would happen is 1 Sep.

But I have found this frustrating. I absolutely do not want to sow bad feelings regarding this, but will note that you were saying "@rowanj is busy" almost a year ago (https://github.com/rowanj/gitx/issues/259#issuecomment-26763094). A transfer would take all of, say, 15 minutes? A reply of "Sorry, busy, will handle in three weeks." considerably less time. It seems like it takes the threat of a fork to get action.

I benefit daily from @rowanj's work on this (and @pieter's, and @laullon's), and I do not forget that. But I thought -- and maybe I am misremembering this -- that part of the promise of GitX-dev is that it would not fall into the kind of benign neglect that the other GitX forks have.

Which I guess just underlines why getting past the single-dev bottleneck needs to happen.

Thanks for looking into this, and I certainly wish @rowanj the best with his new digs.

[pipelineoptika]

A couple of things.

First, "threat of a fork"? Sorry, but if you want to fork, please go right ahead. Nobody is stopping you. There's no threat there. @rowanj doesn't care a whit if his fork isn't the official one. He'll probably keep working on it regardless, as it does a). what he wants, and b). is going in the direction he's headed.

Second, this fork is maintained by @rowanj, when time and circumstances permit. He's always pleased when people submit patches and improvements, but fundamentally this has been a sandpit for making a better GitX client for his personal use. If you're unimpressed with the pace of change or his maintenance, then I urge you to fork. Do not waste your time asking @rowanj to transfer control over his personal for-fun-and-research fork over to another organisation. This is why forking exists. This is why forking works. "One fork to rule them all"? I respectfully disagree.

[rowanj]

Yeah, @pipelineoptika is basically on the money with this.

I'm glad that so many are benefiting from my work, but I don't have the time to run an organisation and review code as often as people can submit it. That doesn't change with having a GitHub organisation; and I can have collaborators on rowanj/gitx just as easily.

I use GitX daily as my SCM GUI of choice, and scratch whatever itches when I have the time to straighten it out. I have been working (sporadically, yes) on GitX for years, and the overall rate is pretty much steady - bursts of activity four or five times a year. Most of them accompanied by one or more Sparkle releases, if it's stable enough and/or fixes major bugs.

The major barricade to me having more collaborators to let the project 'just run' without my intervention is that I know there is a lot of code waiting in the wings that will actually move the project away from what I want out of it, and make my long-term plans more difficult.

I think the single-dev bottleneck mentioned above exists because none of the people that have worked extensively on GitX so far have had both the time and inclination to properly manage the project and its contributors with a wider developer base.

If anybody has a direction for the project, a plan to organise contributors, and the time to manage them, I welcome their efforts; and they should feel free to take up whatever role in gitx/gitx that they wish. I'll continue to post my code here for all to see and re-use.

[voxpelli]

+1 on @pipelineoptika and @rowanj – great if someone starts up an organization supporting GitX, great if it becomes even greater than the one @rowanj maintains – but until it has proven to become that, I'm happiest if @rowanj keeps maintaining his personal fork and keep making it work well for him, as that has so far worked well for me as well.

Forking is the right thing to do here.

[nanoant]

I am sorry, but forking doesn't make sense at all. The whole effort for @GitX org was to reduce user confusion and point them all to single actively developed version. Putting my finger into roadmap never was my intention. I always wanted @rowanj to lead and decide. IMHO current sittuation with several GitX versions scattered across Internet, these sites listing and comparing them is just no good for users. So once again I just want @rowanj to consider moving his project to gitx org and all obsolete forks point there. Aside of that, I don't want to change anything in current workflow. Again, this is all for users' sake.

[claybridges]

Let's consider "fork". It's a pretty overloaded word. In one sense, it's a technical term. But it's also a conceptual term, describing a splintering of effort, or community. Examples abound: Unix, Emacs, Lisp, WebKit/KHTML. I think some of the heat & light I'm seeing here might be related to this ambiguity.

This discussion, and others like it over the last couple of years, have not been about whether there should be a technical fork of GitX, but whether the community should get behind an organization responsible for GitX, and how that will occur.

For my money, @rowanj has clearly taken the baton for GitX over the last couple of years, for which he deserves a lot of credit and admiration. It is what puts us addressing this question on an issue in his repo today.

I'm very glad that he's clarified his position on the future direction of rowanj/GitX. If there is to be a viable gitx/GitX, it seems pretty clear -- now -- that will happen as the result of a both technical and community "fork".

I feel whatever brouhaha may be occuring here is mostly a result of his not clarifying that earlier. There is a long history here. If you are familiar with it, you know that such questions have been long brewing, and direct questions -- dare I say pleas -- to Rowan to clarify his position on the matter (roughly, "let's make a group") have long been on the table, publically and privately. Whatever consternation I may feel stems from his not addressing this up front, and essentially forcing somebody to wrest it out of him. It's been a waste of time. I feel this present public drama, of which this note is certainly a part, was completely avoidable.

I've seen some thoughts expressed along the lines of "of course this is Rowen's repository, go make your own". As I hope I've laid out carefully above, that's never really been in question, and is not a source of controversy. And yet, I find it hard to square the "glad that so many are benefiting from my work" stance with putting "By developers, for developers" in your project byline, which seems to be inviting real collaboration.

Regardless, no need to figure on it further.

[nanoant]

Finally typing on real keyboard, rather than iPhone on a beach in full sun ;)

@rowanj wrote:

(...) but I don't have the time to run an organisation and review code as often as people can submit it. That doesn't change with having a GitHub organisation; and I can have collaborators on rowanj/gitx just as easily.

Yes, indeed that doesn't change if the project stays on your account or it gets transferred to organization. I may read it wrong, but what you are basically saying it doesn't bring any benefit to you. Right? But the purpose of this move was not to please owners or collaborators, but to please end-users. I have stated that from the very beginning.

This discussion, and others like it over the last couple of years, have not been about whether there should be a technical fork of GitX, but whether the community should get behind an organization responsible for GitX, and how that will occur.

In practice there is always someone who decides about what and when gets done - a project leader. From my standpoint you are the leader, and I don't want to argue with that, change that and discuss that. Just to be clear "organization" is just GitHub term, and there's no implication that the GitX will be now held by some OSS organization or whatsoever if it runs on @gitx account. It is just technical way to get single gitx.github.io address and let end-users think this is the "right" project.

The major barricade to me having more collaborators to let the project 'just run' without my intervention is that I know there is a lot of code waiting in the wings that will actually move the project away from what I want out of it, and make my long-term plans more difficult.

Having more collaborators was indeed suggested during the discussion. But it wasn't target for @gitx GH organization. (see above)

@claybridges

Let's consider "fork". It's a pretty overloaded word. In one sense, it's a technical term. But it's also a conceptual term, describing a splintering of effort, or community. Examples abound: Unix, Emacs, Lisp, WebKit/KHTML. I think some of the heat & light I'm seeing here might be related to this ambiguity.

And what benefit it brings to the existing users?

I've seen some thoughts expressed along the lines of "of course this is Rowen's repository, go make your own". As I hope I've laid out carefully above, that's never really been in question, and is not a source of controversy.

Yes this is indeed how I've read that too.

And yet, I find it hard to square the "glad that so many are benefiting from my work" stance with putting "By developers, for developers" in your project byline, which seems to be inviting real collaboration.

Yes this sentence is in contradiction to what @rowanj writes above. This is disappointing, this had misled me, but I can live with that.

Now I think further discussion is pointless. @rowanj, @pieter and @laullon are owners of it. They are free to do anything they want. From now on I cease any further actions from my side.

[tiennou]

I just sent some email stating that I'm concerned with a year being gone by without any move on master, and that I'd be willing to make the organization thing come true because I don't feel like forking is any improvement to the current situation. As far as I know, there is already 2 "non-trivial" forks of @rowanj, my own development/fix/private testing version and @ssp — which I just discovered and collects a few bits and pieces.

Please note that if there was a non-forking resolution possible I'd be all for it, but after helping by writing code and fixing bugs and offering support with triaging issues and PRs, I don't see any other way.