Re: [Tracker] Fwd: tracker 1.11.2

[Carlos Garnacho <carlosg gnome org>]

Hi Philip!,

On Fri, Dec 9, 2016 at 11:46 PM, Philip Van Hoof <philip codeminded be> wrote:
> On Fri, 2016-12-09 at 00:44 +0100, Carlos Garnacho wrote:
>
> Hello Carlos,
>
> NO criticism on the content of the releases and the technical
> improvements, nor on the communication on the security bug and panic of
> certain people.

:)

> Just some remarks on versioning here.
>
> >   * tracker-extract: Sandbox extractor threads. Filesystem and network
> >     access are limited to being read and local only.
>
> As a semver fan myself, I wonder why you didn't start 1.12.0 instead of
> calling this update 1.11.2?

Although following its own version numbers, Tracker has been following
lately the gnome schedule. I came to think lately (most nominally,
when rolling this last bunch of tarballs), that the gnome schedule is
indeed too fast paced for Tracker, while we've most often respected
backwards compatibility quite thoroughly. eg. there's distros shipping
1.8 because that's what came out with gnome 3.20, while 1.10 is a
qualitatively better drop-in replacement.

I however think going from "odd minor number is unstable" to semver
versioning with minor!=0 is going to be confusing... I will suggest
the following plan:

- Finish this 1.11.x/1.12 cycle
- Sticking to 1.12.x for as long it's needed while
- Gearing to a Tracker 2.x that switches to using semver approach to
communicate API/ABI changes.

If communicated properly, that'd at least allow us to have a single
last/current stable release to care about most often, and the window
to accumulate backwards compatible changes can be made variable based
on urgency (situations like this don't come up often but you never
know...), I wouldn't mind that this unstable window is still made to
roughly match the 6 months gnome schedule though, and maybe release
2.[x+1] with whatever might accumulate in that period.

How does that sound to you?

I'll also take the opportunity to introduce to the ML the "roadmap"
that's been shaping up in my head for 2.x:

- Getting as close to supporting the full sparql 1.1 spec as possible
in libtracker-data:
  * property paths: last weekend got halfway with this \o/
  * graph management: for DROP GRAPH I think triggers will perform
just fine, CREATE is also easy, for LOAD/MOVE/ADD it looks like we can
unroll into specific updates.
  * the VALUES clause
  * the MINUS filter
  * CONSTRUCT/ASK/DESCRIBE
  * Removing or limiting the extensions we've gained on the way and
are addressed in 1.1 (eg. accepting "AS var" as good, property paths
greatly reduce the need for our property functions,... other
extensions like FTS must stay of course)

- Double checking ontology migration code, ensure it can handle weird
ontology changes more or less elegantly.

- Library-fying tracker-store, and separating ontology for good, so
eg. an irc client wanting to store conversation logs privately can eg.
do:

connection_manager = tracker_open (".../.cache/my-app/private-store",
"/usr/share/ontologies/nepomuk/nmo.ontology", cancellable, &error);

And it gets a local database with just the relevant classes from the
specified ontology. This might need a hardcoded basis though,
xsd/rdf/nrl/dc/tracker at least. As long as that is properly
documented I'm fine with it.

- And of course, keep dbus-based implementations around, I guess we
can't move too far from nepomuk there, as it's already the implicit
contract between miners and all the surrounding ecosystem.

However would be great to have the tracker-store executable be more
generic, so you can make it claim a different dbus name, write to a
different location, construct the database using a different
ontology...

Does this sound sensible? matches reasonably with your own "Tracker as
generic SPARQL endpoint" ideas?

> Sandboxing sounds to me like a new feature. Not just a bugfix.
>
> As Tracker gets used in ever increasing use-cases, ie. not only
> desktops, I think our users want a clear version numbering policy. The
> semver rules offer just that, and are compatible with API and ABI
> changes and packaging formats like Debian and RedHat's.
>
> >   * tracker-miner-fs: Fixed high CPU use when receiving many writeback
> >     notifications at once.
> >   * tracker-extract, libtracker-sparql, libtracker-miner: plug leaks
> >   * tests: cleanups and improvements
>
> Those two are worthy of a 1.11.2, yes. So I would have released a 1.12.0
> containing the sandboxing, and a 1.11.2 with these two.
>
> > Translations: hu
>
> 1.11.2
>
>
> Now, I understand that 1.10.1 was in need of a upgrade too, and
> incrementing its version number to 1.11.0 would have conflicted with
> existing releases under 1.11.x.
>
> What to do in that case, in my opinion, is to release a 1.12.0 coming
> from 1.10.1 (instead of 1.10.2). And a 1.13.0 coming from 1.11.1
> (instead of a 1.11.2). The release numbering just jumps over the
> existing ones.
>
> I also think that, given that you are maintaining +3 simultaneous
> releases, a gitflow setup could be useful (develop, master, hotfix/*,
> release/* and feature/*).

That is not by choice, believe me :), I would be more than happy if I
had to maintain one single stable branch, then some distros stick to
outdated stuff :(.

Cheers,
  Carlos

PS. I haven't forgotten the "big rip" thread, nor the "Resource table
fills up with UUIDs" from further in the past, need to get back to
those...