Re: [SyncEvolution] schedule SyncEvolution 0.9.1 + 1.0
On Mon, 2009-08-31 at 20:21 +0100, Lukas Zeller wrote:
On Aug 31, 2009, at 15:17 , Patrick Ohly wrote:
> The biggest unknown factor for 1.0 are the necessary changes in
> libsynthesis. Lukas has reassured me that he has made good progress
> towards those, but they have a business to run and therefore might
> have
> more important work to deal with first. September 4th in the
> schedule
> below is way too early
Yes.
> - more realistic proposals welcome ;-}
I have an external project until mid-September that will probably take
a lot of time (not entirely clear yet). So it's unrealistic that I can
make a lot of progress until then. On the other hand, if we can take
apart "SyncML server API discussed and usable" into "discussed" and
"usable", we can do the discussion part earlier so at least everyone
will have a clear picture what is coming and can prepare up to the
point of actually putting it together.
That would be useful. I'm sure there are several parts on our side that
we'll have to prepare for. Most of these I'm aware of, but spelling them
out explicitly and clarifying open questions will be useful. This might
be a more suitable discussion for the Synthesis list, so I assume that
you start the discussion with a post there.
What also might work is that I make a public branch of compilable,
but
not yet usable work in progress early, so environment setup (e.g.
organizing the build process for the new libsynthesis_srv) can start
already.
That would also be useful. It might also support the discussion.
This way, I think that a alpha libsynthesis_srv until end of
September
could still work.
How does that sound?
Excellent! I hope you don't feel pushed into working on it now when you
have other things to work on. The main purpose of my email was a) a
reality check and b) get the technical discussion started.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.