Awesome! I won't spend more time on the website then. I like the idea of posting patches, but I'm concerned about stuff getting lost on the mailing list. Would the ticketing system be a better place for this?
-dave On Mar 13, 2010, at 3:29 PM, Pieter de Bie wrote: > Hey, > > 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 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. > > Another thing is changes in the .xib files. They're really hard to > merge, so any commit that changes them really should have a clear > explanation on what was changed in the xib -- so detailed that someone > that does a merge is able to redo the changes manually. > > 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. > > - Pieter > > On Sat, Mar 13, 2010 at 12:55 PM, Dave Grijalva <[email protected]> wrote: >> Sounds perfect. There's currently a 'master' branch and a 'stable' branch. >> I'm a fan of this workflow vs using 'master' as 'stable'. This is >> basically the same as you've proposed only with a minor naming difference. >> Plus, it's the way pieter was already doing it. As always, it's best if >> contributors work in topic branches. >> There are already a few commits on top of the last release in the stable >> branch, so that's go good jumping off point for 0.7.2. We can pull fixes >> into there and get something out soon. If anybody has bugfix commits out >> there, please bring them to my attention as soon as possible so we can get >> them in. >> Meanwhile, I'm going to merge the stable branch down into master and try to >> consolidate it with the pretty large set of changes that were applied there >> after 0.7.0. Then we can start putting the two releases together at the >> same time. >> I haven't talked with pieter yet about moving the website, but I will send >> him an email tonight. If he wants to continue to host the site, that would >> make my life easier, but I have the impression he wants to remove himself as >> a bottleneck from the project. >> -dave >> On Mar 11, 2010, at 9:05 PM, Kevin LaCoste wrote: >> >> On Fri, Mar 12, 2010 at 10:21 AM, Dave Grijalva <[email protected]> wrote: >> >>> I've reset my master to what's in Pieter's. Since this is most inline >>> with the state of lighthouse, it's probably the best place to start. We >>> should probably re-evaluate what's scheduled for 0.8 since there's a lot of >>> code that's ready or near ready that doesn't necessarily line up with what's >>> scheduled. I have access to the lighthouse project now, so I can start to >>> work on this. >> >> The current release is 0.7.1. Maybe we should map out a quick list of >> milestones to get us started? >> >> I propose we get a very minor update out that cherry picks any outstanding >> bug fixes from the network and call it 0.7.2. No new features or major >> refactorings. Then we start with Nathan's additions and work to get them >> reviewed/integrated for a 0.8 release. It would also be a good idea to limit >> the changes for 0.8 to things we can get done in a short period of time, say >> two weeks or so after the 0.7.2 update. >> >> 0.7.2 >> - new Sparkle feed >> - website redirection of the old Sparkle feed (so current users find us) >> - cherry picked bugs from the network >> - possibly run things through the static analyzer and fix any memory leaks >> >> 0.8 >> - add Sparkle delegate method to enable "cutting edge" releases >> - add completed/reviewed patches from Nathan's branch >> - anything else that comes up through further discussion that doesn't push >> back the release >> >> How does this sound to you guys? >> >>> Getting the website moved over is important so we can remove the >>> dependency on Pieter to do releases through sparkle. >> >> One thing that needs to be looked into here is getting the current Sparkle >> feed to redirect to the GitHub hosted version. This is important since it >> will allow existing users to find us without having to come back to the >> project to see what's new. Have you talked to Pieter about this? >> >> Pieter, would you be okay with this? >> >> I would also like to propose we run with two permanent branches in the main >> fork. The traditional "master" branch, which would contain all the code in >> the current stable release and a "beta" branch, where new patches would be >> applied. The thinking here is that all integration is done on the beta >> branch and once we're satisfied with the stability of it, we could merge >> that branch into the mainline. Beta releases could be generated from the >> beta branch after any given patch is merged. Final releases would come from >> the master branch whenever it's merged with the beta branch. >> >> Again, any thoughts on this process would be appreciated. >> >> Kevin >> >> >>
