Re: Upcoming evolution-data-server API changes (libical-glib + more)

On Fri, 2019-04-12 at 08:47 +0200, Milan Crha via desktop-devel-list
I found these hosted on GNOME:

I've a little update on the dependencies and the porting preparation
progress. Those prepared are:


  bijiben alias gnome-notes



Partially prepared is gnome-todo, because I've some trouble to build
the master branch of it, thus I prepared the changes for the gnome-3-28 
branch. More is written here:

Some didn't need any change, they were:
  ekiga (uses the old deprecated EBook, not EBookClient API)

As Bastien reminded in the other subtread, gnome-phone-manager is
archived, thus I'm skipping it for now. I may attach a patch for it and
other not-hosted-on-GNOME project at the eds report, thus they are
easily findable:

These hosted on GNOME, which  are still to be done:
   california - that's just Vala, but I do not speak Vala, thus any
      help would be appreciated. It seems the project is
      currently unmaintained.

   evolution-activesync - this will be fun, but it's not a critical
      component for the GNOME, thus I'll keep it for now, similarly
      as all the other dependencies (not hosted on GNOME).

The libical 3.0.5 release is planned by the end of this April, +/-,
after which it might be possible to move things forward, from my point
of view. Depending on the actual date of the libical release, I'd
commit the eds changes a week after it. It's not much time, I agree,
but it could be around May 7th, which is ~2 weeks after the 3.33.1
release and a bit less than 3 weeks before the 3.33.2 release, which
sounds good, I hope.

Thus, unless there is any objection, I'd stick with this plan.

I'll continue preparing other projects, to have them ready on time and
make the transition as smooth as possible.

One thing, with the prepared merge requests [which will need changes in
the version reference (they reference libecal-2.0 as 3.33.1, while
it'll be a different version)], should I contact respective maintainers
anyhow specifically, other than through the gitlab and this mailing
list, thus they know about the change? And once the eds changes are
committed, should I still wait for them for an approval, or should I
just commit, at least for those projects which are related to GNOME
Continuous and other services, which will break once the evolution-
data-server changes are committed? I do not want to touch their code
without them knowing about it, I do not like it myself, thus I'm
looking for some advice how to make it smooth and coordinated. There's
plenty of time, probably 3 weeks, and the merge requests are quite
fresh, I didn't expect any quick reaction on them (even I did receive
one, which was impressing), but I like to be prepared and behave like a
good citizen.

        Thanks and bye,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]