Stewart Smith wrote: > On Wed, 2008-07-23 at 00:10 +0000, Jim Winstead wrote: >> Jim Winstead has proposed merging Fix some compile issues for Mac OS X, and >> remove glib for now into Drizzle Active Development Branch. > > > A few comments. > > (I much prefer individual mails of patches to list.... very tempted to > write a bzr plugin that does this. I hate not having patches in mail to > respond to when offline).
Already exists... there are two different ones. There's bzr-email, which is apt-get able, which will send commit mails. This, of course, gets chatty. There is also the built in bzr send command, which will send the patch you are proposing for merge and a revision bundle. Additionally (and I've been using this some) you can subscribe to branches in launchpad, so that when someone pushes to a branch, launchpad will mail you a patch of each revision. The problem here is that you have to subscribe to their branch. BUT ... perhaps we can suggest to launchpad that we would like a branch subscription option that would send emails of each commit - when a branch submits for merging. So in this case, if I was subscribed to trunk, and jim submitted macosx-fixes to trunk, launchpad would email me all of the commits jim is proposing for merge... > http://bazaar.launchpad.net/~jimw/drizzle/macosx-fixes/revision/186 > > should only be marked unused for OSX. otherwise, they are used. > > for only OSX, you can have in the #ifdef section, > (void)parameter; > > and that squishes the warning for OSX only. Agree. > http://bazaar.launchpad.net/~jimw/drizzle/macosx-fixes/revision/183 > > not so sure about this one.... bzr clean-tree is fairly useful, and > doing --ignored is... err... good too, but you have to be careful if you > use quilt or similar with this. > > so not really a fan of this one. Ah... good point... BUT, I like this because I like to do bzr status to check on what I've done, and after a build I have to pipe it through less because of the laundry list of unknown files. I would really like to remove our current need for running bzr clean-tree and get make clean and make distclean and make maintainer-clean all doing the right thing. > http://bazaar.launchpad.net/~jimw/drizzle/macosx-fixes/revision/184 > > only mark unused on platforms where it isn't used. > > am okay with the removal of embedded stuff, think coding style patches > sholud be in sep commits, don't see any current reason for removing glib > after we just added it. certainly don't want to go back to my_strdup. This glib argument back and forth really needs some clarity... but yesterday we had three new people all trying to get started on OSX who were all having issues, so I figured merging this for now is fine, and then once we've got either - a clear glib direction - decent instructions on getting going with glib on OSX I can pretty easily put the glib code back in > frankly, OSX can grow up and get readline and we can have it as a build > requirement. I also agree that OSX needs to grow up as a dev platform, and I'm a bit annoyed at having to put craziness in to deal with its deficiencies... but I'm ok with it _for_now_... as long as we can put together a decent longer term plan for dealing with lack-of-sensible-libs-or-packaging on OSX. > http://bazaar.launchpad.net/~jimw/drizzle/macosx-fixes/revision/188 > > am okay with this one. > > hope this helps, > stewart -- https://code.launchpad.net/~jimw/drizzle/macosx-fixes/+merge/543 You are subscribed to branch Drizzle Active Development Branch. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
