[Spice-devel] Improving spice-server code base

[Uri Lublin]

On 08/11/2015 11:04 AM, Christophe Fergeau wrote:
> Hi everyone,

Hi Christophe,

I'd like to suggest an alternative branching scheme. See below.

>
> spice-server code is currently very hard to follow, with a few huge
> source files, very little encapsulation, ...
>
> There is a branch where quite a lot of cleanup has been done
> http://cgit.freedesktop.org/~jjongsma/spice-server/commit/?h=replay-rebase
> even though there is still a lot to do ;)
>
> This was initially started a few years ago to experiment with recording
> the network stream for a SPICE session, and then being able to replay it
> automatically for testing purpose, but during this experiment, quite a
> few improvements to the code base were done as well (main highlight
> being red_worker.c split). Then additional work was done on top of that,
> GObjectification of the channel objects, more code
> separation/encapsulation/... The API/ABI have been kept though, so no
> changes are required in users of the spice-server library.
>
> The resulting code base is far from being great, but is already a big
> improvement over what we currently have in git master. However, until
> now we never really thought about how to merge all that work back
> upstream, and the more commits go in, the harder it gets.
>
> Starting merging this is long overdue, but integrating that work
> upstream while being reasonably confident that this will not introduce
> regressions is harder :) The lack of tests/unit tests is not helping
> with that, and the fact that the code refactoring is mixed with the
> addition of the 'replay' feature is also making this merge more
> complicated.
>
>
> After some discussions, one suggested way of handling this is the
> following:
> - create a new 'next' branch in git based off git master
> - go over this 'replay-rebase' branch and extract manageable patch
>    series from it, and merge these to the 'next' branch after a review
>    (not necessarily an extensive review)
>
> We'll also try to add tests while this work is being done to help catch
> regressions. Whether the 'replay' feature is merged at the same time
> will depend on how hard it is to extract it, and if it's useful for
> testing.
>
>
> This 'next' branch would be the development version of SPICE, and we
> could make unstable releases from this branch.
>
> The current master branch would keep being maintained and seeing
> releases but *ideally* would be getting only bug fixes.
> I know there are currently some patches pending against spice-server,
> these would be taken care of before the 'next' branch is created.

Here is an alternative suggestion for branching:
Branch 0.12 will keep the current code and will be updated
mostly with bugfixes.
Branch master will hold the new code (version 0.13 while its
experimental and version 0.14 when it becomes stable again)

This is also consistent with "older" branches (0.4 0.6 0.8 0.10)

With this approach master will become unstable/experimental
for the (hopefully) short term.

Thanks,
     Uri.


>
>
> At this point this is just a preliminary plan, we're open to any
> suggestions/comments/... you have about all of this, and we can still
> decide to take a very different approach with respect to how we
> integrate this branch,
>
> Thanks for any input,
>
> Christophe
>
>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>