Given Pieter's comments below, it sounds like the best course of action is to prepare our first update and distribute it via the current site. This basically boils down to sending Pieter the updated Sparkle feed and having him update it there. The actual download can still be on the GitHub site.
On Sun, Mar 14, 2010 at 8:29 AM, Pieter de Bie <[email protected]> wrote: I don't mind hosting the site and other small updates. I'm a bit > hesitant moving the sparkle feed (and website) completely, with the > chance that nothing happens with GitX and that it would be out of my > control to do anything about it. I'd rather wait a bit and see how > things go before moving everything out of my control. > I can definitely understand this concern. A few guys talking on a mailing list is hardly the same as producing stable updates that are ready for public consumption. I have no problem with delaying any web site transition until Pieter is happy with the progress of things. > I took a quick look at the for example Uli's master, and I think those > commits are far from ready to go into master. I'd suggest trying to > make the commits more clear than they were previously, so try to avoid > all the "trying to fix this.." "oh, that didn't work, let's try this" > type of commits that sometimes appear. > I had similar concerns. It's clear that many users are forking and using that space for work that should really be happening privately on topic branches. Hopefully at some point we might convince those in the Network graph to bring their testing code offline so that the graph won't be so confusing to look at! I think I might have said this before, but I'd also suggest to adopt a > single way to contribute to GitX -- I don't like push messages and > merges as they aren't really public, it's hard to comment on those > kind of changes and impossible to discuss. It's hard in github to > follow forks, even with the network view, as some people just create > random fixes that shouldn't be applied, some don't update their > branches to the latest master. I'd suggest doing it the way git does, > and accept only patches send to the list. That way everybody can > follow what's going on, and it'll be a relative low amount of mail > anyway. I, at least, would still like to follow development and > comment on stuff, and perhaps keep contributing. > I'm mostly in agreement with this. I don't see Merge Requests being an issue if they are discussed on the list first though. I think the key point to keeping the community involved is to have any feature changes come through the list for discussion first. That way we have the benefit of other viewpoints before moving forward with things. And thanks for commenting Pieter. I'm glad to know you will continue to be involved! Kevin
