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 > > >
