Re: [gnome-db] Gee Release Plans for 0.8?

Your comments open lot of light for me.

May be I could help in some bugs and the trivial ones, in order to
have 0.8 ASAP. With this in mind I consider that depend on 0.8 is good
enough for 5.2 release, unless GDA maintainer consider to keep Vala
extension on its branch until 0.8 is close or is released.

2011/12/8 Maciej Marcin Piechotka <uzytkownik2 gmail com>:
> On Thu, 2011-12-08 at 16:12 -0600, Daniel Espinosa wrote:
>> I've recently implemented some libgee-0.7 interfaces for libgda[1],
>> and I want to merge to master, but may be 0.8 will not be ready for
>> libgda-5.2 release?
>> What are your planed milestones and release plan?
> Right now unfortunately it's partially 'when it's done'. The main
> problem is the amount of time I had available during this term. I hope
> that during next term it will be better.
> The main parts which have not been done (and been planned):
>  - Adapter for Set in terms of Map interface. Should be very simple (I
> was considering posting Gnome Love bug for that).
>  - Adding signals. Should be very simple.
>  - Implementing ConcurrentSortedSet. The changes in interfaces could be
> quite simple and done quickly while the implementation may be moved
> outside scope of 0.8 release (in any case main part of concurrent data
> structures was already implemented).
>  - Removing the _impl functions. For this I need to have bug #640330[1]
> solved. From what I understand Jürg have some plans for semantic
> analyser in Vala etc. Releasing the 0.8 before this bug is solved will
> result in very ugly API which I would prefer to avoid.
>  - Finally finishing SortedMap implementation. The solution requires to
> solve bug #596549[2].
>  - Polishing subset implementation (can be offseted till later). I was
> about to post some question about that.
> Assuming lack of #640330 the changes could be done before New Year
> making the release before libgda-5.2 (I assume it corresponds to Gnome
> 3.4).
> Those points were also considered:
>  - Reverse iterators/collections. While they should be reasonable simple
> to write someone needs to write them ;) I had patches but they cannot be
> used after introduction of concurrent data structures.
>  - Asynchronous iterators. It requires probably either making all
> iterators async (as the API/ABI is broken it should not be a big deal)
> or the Vala extension[3]. The original intention was to iterate over
> file in nice way (possibly introducing helper for it later on) but I
> guess they would fit the iteration over database records nice as well.
> Probably for full use would require to have support for #604827[4]
> Both should be also relatively easy to implement.
> I consider bug #640330 especially 'annoying' as it both prevent from
> API/ABI cleanness I would like to have in 0.8 and it prevents to have
> short conditional compilation between 0.6 and 0.8.
> I would say the API/ABI stable version is max(bug #596549 solved + Δt,
> bug #640330 solved + Δt, end of January).
> Unfortunately both Jürg (from what I heard on #vala) and I were busy so
> I am a bit out of touch and I cannot say any exact date or Vala version
> (some of Vala enhancements are not necessary trivial). People from folks
> considered conditional compilation as described in bug #661102[5]
> (depending on #640330).
> I am sorry that I cannot give exact time.
> Best regards
> [1]
> [2]
> [3] Previously I believed that it requires extension but I see a way to
> workaround it.
> [4]
> [5]

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)

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