On Wed, 2007-12-05 at 16:29 +0000, John Carr wrote: > Lo all > > On 12/5/07, Jonny Lamb <[EMAIL PROTECTED]> wrote: > Hi everyone. > > A fairly long email with some various thoughts on several > things. This > is meant to spark up discussion, so please do reply! > > 0.11 > ==== > > I think this needs to be released pretty soon. However, there > are some > things that need to be sorted first: > > * Documentation -- yes this is the obvious one. Nothing really > to say > about this. > > I tried to start discussion about this earlier - mainly the best way > to structure the new wiki stuff and specifically how to deal with > distrubtuion specific bits without the duplication getting crazy. >
At the moment, the docs are getting sooooo out of date a comprehensive text file would be an improvement :) Seriously, I think we shouldn't get overambitious, anything in whatever format would be good. > * Various fixes -- known bugs in the software that don't > require a > whole new rewrite should really be fixed before the > release. Please > can you all reply with problems that spring to mind when I > speak > about this, so I can keep track of the progress. > > Rather a general "what needs to be done" list. Please do reply > with > specifics! I suppose I'm suggesting we put in a freeze now > and > concentrate on bugs, for the release. > > Stuff I had wanted to see before 0.11: > > * Data loss bug on WM6 phones when partnership is deleted - jagow is > close on that > * Mess with wbxml. I have some basic pure python wbxml that we could > think about using, but i'm almost ashamed to admit it right now - not > really had time for it and code is a messy port of some PHP Not too up to date on PIM post WM2003 syncing, but it looks like John is on a mission with it, and more power to him. What exactly is the deal with wbxml again ? > * HAL integration - a HAL callout that: > * dhcp-ifies a device > * starts odccm with the ips that dhcp sorted out (if not running) > * starts sync-engine (if not running) > This stuff, while cool, I definitely see as low priority. The connection infrastructure actually works. Of course if anyone feels the need to play then that's up to them. > If this doesn't make it for 0.11, any objections to a 0.12 closely > following when these bits are ready? > > 0.10.0 to 0.11 (There's no point in an extra ".0" in "0.11" as > there's > not going to be a "0.11.1" -- "0.10.0" was perhaps a little > optimistic!) > isn't going to be the biggest update ever, but there are > several nice > new features or fixes. Things that come to my mind now: > > * Samsung SC* phones fixed with usb-rndis-lite. > * odccm now supports legacy devices. > * WM6 support. > * Various other fixes in SyncEngine. > Again, please fill the gaps here. > > I think a new release will be very good for the project. It > will provide > milestones that will be acceptable and doable for developers. > It will > show SynCE as still being active and the new docs will make > the project > more usable. The docs are currently what is stopping me > pursuing > actually getting packages into Debian (and then perhaps > Ubuntu), so that > would be started again. > I agree here, we need to release or users give up from lack of progress, or get lost trying to build from svn. We've had a ton of minor fixes as well, apart from the headlines above. > > Further goals > ============= > > After 0.11 there will be some other features and fixes that > will be > worth investing time in. Two I can think of now are: > > * Simplifying the installation process, significantly. > > Helping main distros get everything packaged and the hal callout i > mentioned should do this. > > I'd like to see odccm be per device if its possible. And use HAL to > close each odccm when its own device is removed.. Any device > properties should be stashed in HAL rather than apps having to talk to > odccm. It seems a large chunk of odccm is boilerplate :-( > As above, sounds like a nice idea, but should definitely be low priority. > > Other talking points > ==================== > > vdccm: It seems to me that the only advantage of vdccm is its > multiple > device support. Therefore, I am suggesting dropping vdccm as a > proper > SynCE module. I'm not saying it should be deleted from SVN, > but just > left out of releases. Thoughts? > > I presume vdcccm won't support WM6? It also doesn't work with > sync-engine. Unfortunately dropping it hurts KDE users, who often ask > about RAKI. I have no idea what exactly that is, but seems not to work > with odccm. Yet. I am strongly in favor of having just one *dccm. > Either RAKI support in odccm or another standalone proggy, or vdccm > needs to be extended for WM6 and needs to be made to work with > sync-engine? > > When we talk about multi device in vdccm, are we talking WM5 or earlier ? I get the idea we are talking older devices, and odccm will probably do this as well. I am not a raki expert, but from the little I have been through it shouldn't be too hard to move to odccm. Raki receives events via a control socket in ~/.synce from vdccm, essentially the same events come from odccm via dbus. Don't look at me for that, I can read C++ fine but writing it is something else. > UK meetup: There are a few of us in the UK (myself, John Carr, > J. A. > Gow, Mark Ellis, more?) -- John Carr and myself have spoken > about > meeting up but I've been tremendously busy this term starting > uni and > all that. Would anybody be interested in this? > > Meeting ++; > > Though not sure where :-) > Could be fun. Mark ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
