On Mar 8, 12:18 pm, Nathan Kinsinger <[email protected]> wrote:
> I'm not a maintainer but I think Uli's fork is the most up to date (or has > the most features anyway):http://github.com/uliwitness/gitx/ > Is Uli on this list? I think if we were to nominate a new fork as the interim maintainer (as Pieter seems to approve of in another thread) we should pick something that hasn't been treated like a dev branch. A quick peek at Uli's timeline has me thinking it's somewhat experimental in nature. > I have some changes that I'm working on, hopefully just one more weekend and > I should be ready. I was going to do auto refreshing using FSEvents, but I > haven't had the time so I'm just going to clean up what I have and push that. > Actually, no offense but, this is the mindset I was hoping to get away from. :) Admittedly, I'm not an expert in Git workflows but from my understanding, experimental stuff should stay in the local clone until it's ready for merging to the mainline or to be shared as an experimental branch when collaborating. In both cases it should probably be pushed as something other than master so it's clear this is a feature/topic branch. Otherwise the network graph gets muddled very quickly and essentially becomes useless to the maintainer. I wouldn't be surprised if this is why Pieter was requesting patches via email instead of using GitHub's pull request feature. What I propose is this, the community needs to nominate an interim maintainer and decide on a stable fork from which to work. Any work submitted to the maintainer should be as focused as possible so the maintainer can do his job without getting overwhelmed. Simple bug fixes should be accepted without much work. New features or those bugs requiring larger refactoring efforts should probably get discussed on the list a bit so that an agreement can be reached on whether or not it's suited for inclusion in the mainline. Anything submitted to the maintainer should be merged/rebased privately to ensure it applies cleanly to the current stable master. Any feedback on these ideas would be greatly appreciated. This isn't something I was planning to tackle myself but if a few people were interested I would definitely be willing to be part of a team effort. PS: Please don't consider the above comments as criticism against anyone who's taken the initiative to hack on GitX in their own time. That effort is appreciated. It's just that without some community organizational effort, that work probably isn't reaching the community as a whole. Kevin
