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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel