Re: [Spice-devel] SPICE: changing the merge rules - a proposal

[Marc-André Lureau]

Hi

On Tue, May 19, 2020 at 11:10 AM Frediano Ziglio  wrote:

> >
> > Hi,
> >the community around the SPICE project always tried to follow one
> > fundamental, implicit rule for accepting code contributions to the
> > project: every merge request (beside trivial patches) should be reviewed
> > and acked at least by one before getting merged.
> > While everyone agrees with this fundamental rule, the actual status of
> > some SPICE projects makes the rule impractical to let the project move
> > forward.
> > Let's consider the spice/spice project as an example: the number of
> > contributions is very low, both on the commit side (only 4 different
> > contributors with more than 1 commit from the beginning of the year, and
> > a single contributor with 90% of commits) and on the review side (in the
> > last 40 merge requests before the C++ switch one, 21 had no comments).
> > The x11spice project is another example: we have only 4 contributors
> > from the beginning of the year (and a single contributor holding 70% of
> > the commits) and the reviews on the gitlab merge requests have been
> > provided by two people only, each one reviewing the merge requests of
> > the other.
> > For the sake of having the projects being able to move forward with a
> > reduced number of contributors/reviewers, the proposal is to *allow* a
> > maintainer to merge a Merge Request without an explicit ack if the three
> > following conditions are met:
> > 1) The Merge Request has been pending for at least 3 weeks without
> > getting new comments
> > 2) The Merge Request submitter has kept asking a review on a weekly basis
> > 3) There are no pending nacks on the Merge Request
> >
> > Note that having patches reviewed would still be the preferred way. If
> > at any time the number of contributors would raise again, we can switch
> > back to the mandatory review rule. Until then the priority is to allow
> > the project to move forward.
> >
> > What do you think? Please share your thoughts and/or contribute with
> > your own ideas.
> >
> > Thanks
> >
> > Francesco
> >
>
> Hi,
>I agree on the proposal. This problem has been going on for years now.
> The issue involve all repositories. The active part of community dealing
> with code review is very low.
>

All open-source projects are under-staffed. Spice has had a number of paid
developpers, and a number of paid developpers who can help when it is
needed. This is better than a lot of projects.

I think 3 weeks are perfectly fine. We should be in a trustful community,
>

I expressed my anxiousness about that short period. This is not going to be
healthy to put such constrain. If we were unhappy about the time it took to
review a MR, we would need first to prioritize our work better, and
reaching out for help. Not rush the changes, please.

if somebody is very busy in daily activity or on holidays whomever remains
> should be in charge. Is not that is a person in a team goes on holiday all
> the work of the team is impeded.
>

I don't think such "blocking" factor exist, because the Spice code base is
large, and the domain as well. But in such exceptional circonstances, we
can easily either find a consensus for an exception, or help each other to
unblock the situation.

thanks

-- 
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SPICE: changing the merge rules - a proposal

[Frediano Ziglio]

> 
> Hi,
>the community around the SPICE project always tried to follow one
> fundamental, implicit rule for accepting code contributions to the
> project: every merge request (beside trivial patches) should be reviewed
> and acked at least by one before getting merged.
> While everyone agrees with this fundamental rule, the actual status of
> some SPICE projects makes the rule impractical to let the project move
> forward.
> Let's consider the spice/spice project as an example: the number of
> contributions is very low, both on the commit side (only 4 different
> contributors with more than 1 commit from the beginning of the year, and
> a single contributor with 90% of commits) and on the review side (in the
> last 40 merge requests before the C++ switch one, 21 had no comments).
> The x11spice project is another example: we have only 4 contributors
> from the beginning of the year (and a single contributor holding 70% of
> the commits) and the reviews on the gitlab merge requests have been
> provided by two people only, each one reviewing the merge requests of
> the other.
> For the sake of having the projects being able to move forward with a
> reduced number of contributors/reviewers, the proposal is to *allow* a
> maintainer to merge a Merge Request without an explicit ack if the three
> following conditions are met:
> 1) The Merge Request has been pending for at least 3 weeks without
> getting new comments
> 2) The Merge Request submitter has kept asking a review on a weekly basis
> 3) There are no pending nacks on the Merge Request
> 
> Note that having patches reviewed would still be the preferred way. If
> at any time the number of contributors would raise again, we can switch
> back to the mandatory review rule. Until then the priority is to allow
> the project to move forward.
> 
> What do you think? Please share your thoughts and/or contribute with
> your own ideas.
> 
> Thanks
> 
> Francesco
> 

Hi,
   I agree on the proposal. This problem has been going on for years now.
The issue involve all repositories. The active part of community dealing
with code review is very low.
I think 3 weeks are perfectly fine. We should be in a trustful community,
if somebody is very busy in daily activity or on holidays whomever remains
should be in charge. Is not that is a person in a team goes on holiday all
the work of the team is impeded.

Frediano

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SPICE: changing the merge rules - a proposal

[Jeremy White]

Hi,



The x11spice project is another example: we have only 4 contributors
from the beginning of the year (and a single contributor holding 70% of
the commits) and the reviews on the gitlab merge requests have been
provided by two people only, each one reviewing the merge requests of
the other.


As projects become more specific/marginal, it's clear that the number of 
maintainers is lower. Yet, we have those projects under the same 
umbrella, and I don't think they should be treated differently. 2 active 
developers/maintainers can be very healthy, I would say. So do we have a 
maintenance issue with x11spice? Do we want to move the project out of 
the "Spice-space" projects for ex? What is the problem exactly?


The problem is that any merge request I put in sits there until Frediano 
comes around to look at it.  I do have commit rights, but I have not 
felt comfortable exercising those unilaterally.  I am a fan of the core 
Spice policy - commits only after review.  And I have had patches and 
MRs sit for very long periods of time with no review.  Frediano is right 
that the websocket change is a good example - it is a material 
improvement for anyone using the spice-html5 client, and it lingered for 
years without going in.


There were certainly patch sets that were small enough that I think it 
would have been reasonable for me to just 'time out' and apply them 
without review.  Perhaps I'm not using the 'trivial' policy as I should, 
and I think Daniel is right that there just aren't enough of us.


But another truth is I could have shouted louder and more often and 
perhaps gotten the websocket patch in faster, but it wasn't impacting me 
or any of my customers, so I didn't.




For the sake of having the projects being able to move forward with a
reduced number of contributors/reviewers, the proposal is to *allow* a
maintainer to merge a Merge Request without an explicit ack if the
three
following conditions are met:
1) The Merge Request has been pending for at least 3 weeks without
getting new comments
2) The Merge Request submitter has kept asking a review on a weekly
basis
3) There are no pending nacks on the Merge Request


It's hard to define a delay to bypass a reviewing & consensus rule. In 
general, it should really be frowned upon. There is clearly more than 
one person interested and using Spice. If the issue is important, it 
should be fairly easy to get someone else to look at the issue in a 
timely manner. If not, there are probably more important/interesting 
things to do to get other interested.


I have to say that I was really startled to find that the C++ change had 
been merged.  I largely don't review spice server patches, as I consider 
myself a consumer of the spice server, and not expert enough to comment 
on most patches.  To my discredit, I haven't really adapted to the 
gitlab era; I have not subscribed to MRs in areas outside my projects 
(x11spice, spice-html5).


I also agree with Marc-André that this conversation should have taken 
place over the mailing list.  A merge request is not the appropriate 
place to discuss that substantive a change.


And I *would* have noticed a discussion of that significant a change on 
the mailing list, and I might have even stirred myself to invest in it 
enough to give a considered opinion.


Cheers,

Jeremy
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SPICE: changing the merge rules - a proposal

[Francesco Giudici]

Hi,

On 18/05/20 12:56, Daniel P. Berrangé wrote:

On Fri, May 15, 2020 at 07:05:50PM +0200, Francesco Giudici wrote:

Hi,
   the community around the SPICE project always tried to follow one
fundamental, implicit rule for accepting code contributions to the project:
every merge request (beside trivial patches) should be reviewed and acked at
least by one before getting merged.
While everyone agrees with this fundamental rule, the actual status of some
SPICE projects makes the rule impractical to let the project move forward.
Let's consider the spice/spice project as an example: the number of
contributions is very low, both on the commit side (only 4 different
contributors with more than 1 commit from the beginning of the year, and a
single contributor with 90% of commits) and on the review side (in the last
40 merge requests before the C++ switch one, 21 had no comments).
The x11spice project is another example: we have only 4 contributors from
the beginning of the year (and a single contributor holding 70% of the
commits) and the reviews on the gitlab merge requests have been provided by
two people only, each one reviewing the merge requests of the other.


I think these paragraphs here are the highlighting the key issue. There
just is not sufficient contribution to SPICE in general. I think the most
important thing is to consider why the SPICE project has such a low rate
of contribution, and more importantly what steps can be done to make SPICE
more interesting to attract contributors.

I like your analysis, thanks for sharing it. I agree the best solution 
would be to attract contributors (we need to find some ideas on how to 
do this and act on them btw!) but my point is also: let's try to keep 
the contributors we already have in the meanwhile. I would like to avoid 
issues about contributions not merged (or merged without agreement) 
causing us to start arguing among us. This could led to a not-so-happy 
environment that may harm the project and the community.



For a project that has such a large codebase and featureset, it is not
healthy to have such a small community. The "bus factor" is waay too
low here, such that SPICE would be in serious trouble as a project if
one or two main contributors moved onto to different work.

So for any changes in process, it is wise to consider what effects those
change have on people SPICE would like to attract as new contributors.


Agreed. I would also add we don't want any change that may also make 
current contributors lose love or even leave the project. Hope this is 
not the effect of this draft "proposal" on anyone, as my intent is 
exactly the opposite!




For example, if new feature work by an existing contributor is discussed
out of band between two contributors, instead of via merge request comments
this sets up new contributors up as second class citizenships - the out of
band discussions are essentially invisible to them, so they can't see or
understand the rationale for decisions. This makes it harder for them to
learn how to effectively contribute to the project.

This is the big thing that concerned me about the merge request that adopted
C++. Reading between the lines I get the impression this was indeed discussed
between the several contributors but out of band, instead of on the merge
request which had no comments. Thus that discussion is invisible to any 3rd
party contributor interested in SPICE. I think this risks discouraging people
from contributed to SPICE, so it is something to be wary of doing too often,
especially for really big technical changes.


Thanks for sharing this! AFAIK, this did not happened: no out of band 
discussion at all about the C++ branch merging. Glad you brought this up.
There were two legitimate competing desires in that situation: one was 
to have a big rework merged by the main contributor to the project. The 
other was to have proper review and agreement before performing such a 
merge.
My personal point is that such a rework, moving to C++, with so low 
review effort on the spice/spice project, would have caused the branch 
to stay there without getting a fair review for a very long time... btw, 
a warning that it was going to be merged if no reviews would have had 
not harmed.
This is why I think would be good to have rules that help on what to do 
in such cases: committer asks for reviews for few weeks before merging. 
The other contributors will know that if they don't reply, the merge 
will happen. They will have at least to put a comment there asking for 
more time if they are interested in reviewing. Wouldn't be a fair 
"game"? ;-)





For the sake of having the projects being able to move forward with a
reduced number of contributors/reviewers, the proposal is to *allow* a
maintainer to merge a Merge Request without an explicit ack if the three
following conditions are met:
1) The Merge Request has been pending for at least 3 weeks without getting
new comments
2) The Merge Request submitter has kept 

Re: [Spice-devel] SPICE: changing the merge rules - a proposal

[Daniel P . Berrangé]

On Fri, May 15, 2020 at 07:05:50PM +0200, Francesco Giudici wrote:
> Hi,
>   the community around the SPICE project always tried to follow one
> fundamental, implicit rule for accepting code contributions to the project:
> every merge request (beside trivial patches) should be reviewed and acked at
> least by one before getting merged.
> While everyone agrees with this fundamental rule, the actual status of some
> SPICE projects makes the rule impractical to let the project move forward.
> Let's consider the spice/spice project as an example: the number of
> contributions is very low, both on the commit side (only 4 different
> contributors with more than 1 commit from the beginning of the year, and a
> single contributor with 90% of commits) and on the review side (in the last
> 40 merge requests before the C++ switch one, 21 had no comments).
> The x11spice project is another example: we have only 4 contributors from
> the beginning of the year (and a single contributor holding 70% of the
> commits) and the reviews on the gitlab merge requests have been provided by
> two people only, each one reviewing the merge requests of the other.

I think these paragraphs here are the highlighting the key issue. There
just is not sufficient contribution to SPICE in general. I think the most
important thing is to consider why the SPICE project has such a low rate
of contribution, and more importantly what steps can be done to make SPICE
more interesting to attract contributors.

For a project that has such a large codebase and featureset, it is not
healthy to have such a small community. The "bus factor" is waay too
low here, such that SPICE would be in serious trouble as a project if
one or two main contributors moved onto to different work.

So for any changes in process, it is wise to consider what effects those
change have on people SPICE would like to attract as new contributors.

For example, if new feature work by an existing contributor is discussed
out of band between two contributors, instead of via merge request comments
this sets up new contributors up as second class citizenships - the out of
band discussions are essentially invisible to them, so they can't see or
understand the rationale for decisions. This makes it harder for them to
learn how to effectively contribute to the project.

This is the big thing that concerned me about the merge request that adopted
C++. Reading between the lines I get the impression this was indeed discussed
between the several contributors but out of band, instead of on the merge
request which had no comments. Thus that discussion is invisible to any 3rd
party contributor interested in SPICE. I think this risks discouraging people
from contributed to SPICE, so it is something to be wary of doing too often,
especially for really big technical changes.  

> For the sake of having the projects being able to move forward with a
> reduced number of contributors/reviewers, the proposal is to *allow* a
> maintainer to merge a Merge Request without an explicit ack if the three
> following conditions are met:
> 1) The Merge Request has been pending for at least 3 weeks without getting
> new comments
> 2) The Merge Request submitter has kept asking a review on a weekly basis

Note since spice is using gitlab, it is possible to explicitly tag people
by name in the comments to ask for reviews, and/or assign people as a
reviewer. I'd suggest to make use of such tagging, so that people can be
aware they they are being explicitly asked for feedback if something has
been sitting for a long time.

> 3) There are no pending nacks on the Merge Request
> 
> Note that having patches reviewed would still be the preferred way. If at
> any time the number of contributors would raise again, we can switch back to
> the mandatory review rule. Until then the priority is to allow the project
> to move forward.

Contributors are unlikely to magically rise again on their own, without
proactive work to make SPICE a more attractive project to contribute to.
This is a very difficult problem for projects in general, not just SPICE,
to which I don't have any magic answers. At least try to think about what
you like to see from projects when you are approaching them as a new
contributor, and then make sure SPICE follows these practices where ever
possible / practical. Code being pushed with no review is a turn-off to
me as a external contributor, unless the project is clearly setup as a
single-author personal project, rather than a team project.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SPICE: changing the merge rules - a proposal

[Francesco Giudici]

Hi,

On 15/05/20 23:58, Marc-André Lureau wrote:

Hi

On Fri, May 15, 2020 at 7:06 PM Francesco Giudici > wrote:


Hi,
    the community around the SPICE project always tried to follow one
fundamental, implicit rule for accepting code contributions to the
project: every merge request (beside trivial patches) should be
reviewed
and acked at least by one before getting merged.
While everyone agrees with this fundamental rule, the actual status of
some SPICE projects makes the rule impractical to let the project move
forward.


I wasn't aware of a maintenance problem. Perhaps we should first list 
the projects that have maintenance issues & discuss our options, before 
changing the common rule.


The idea of this e-mail is exactly this: let's discuss. But starting 
with a proposal and not only the issue seems to me the best way to try 
to move things forward (also if in the end the proposal my be completely 
changed it would have reached the goal).




Let's consider the spice/spice project as an example: the number of
contributions is very low, both on the commit side (only 4 different
contributors with more than 1 commit from the beginning of the year,
and
a single contributor with 90% of commits) and on the review side (in
the
last 40 merge requests before the C++ switch one, 21 had no comments).


You are omitting the passive reviewers. I consider myself as one of 
them. If you need people to be more proactive, you could at least reach 
me & probably others past contributors.


Great to know that you are looking at the contributions, also if not 
sure what a "passive" reviewer does. In this case anyway I think if you 
add a comment to the branch you looked at it will be much better. I'm 
pretty sure the submitter will be happy that someone looked at it. So, 
reaching out right now: if there are people looking at the branches and 
not commenting, please start doing. Also partial comments (not full 
reviews) may help I would say.




The x11spice project is another example: we have only 4 contributors
from the beginning of the year (and a single contributor holding 70% of
the commits) and the reviews on the gitlab merge requests have been
provided by two people only, each one reviewing the merge requests of
the other.


As projects become more specific/marginal, it's clear that the number of 
maintainers is lower. Yet, we have those projects under the same 
umbrella, and I don't think they should be treated differently.


Sorry, maybe I was not clear: projects under the same umbrella should be 
treated equally. So, the rules will be the same for every project, and 
can be used to address situations where contributions (reviews) are 
missing. This is something that the number above suggests.


 2 active
developers/maintainers can be very healthy, I would say. So do we have a 
maintenance issue with x11spice? Do we want to move the project out of 
the "Spice-space" projects for ex? What is the problem exactly?


I think you are not getting the point, maybe I was not clear: as long as 
we have at least 2 contributors we get a review there. Perfect, nothing 
changes.
What if one of the two developers/maintainers gets sick? For months? Or 
stops for his own reasons to contribute to the project? Should the 
project stop?
Problem is: if there is low contribution we don't want that active 
contributors face even more obstacles to keep contributing. We want to 
keep the project healthy and alive as much as possible.





For the sake of having the projects being able to move forward with a
reduced number of contributors/reviewers, the proposal is to *allow* a
maintainer to merge a Merge Request without an explicit ack if the
three
following conditions are met:
1) The Merge Request has been pending for at least 3 weeks without
getting new comments
2) The Merge Request submitter has kept asking a review on a weekly
basis
3) There are no pending nacks on the Merge Request


It's hard to define a delay to bypass a reviewing & consensus rule. In 
general, it should really be frowned upon.


I understand your feeling and I feel the same at least in part: but the 
rules we are talking about apply only when a project doesn't get reviews 
and gets paralyzed. Also notice that it *allows* a *maintainer* to merge 
the branch, it is not automatic. We give more freedom and trust to 
maintainers over strict rules when contributions are low.


There is clearly more than 
one person interested and using Spice. If the issue is important, it 
should be fairly easy to get someone else to look at the issue in a 
timely manner.


I like your optimism here, but honestly I don't think this is true. But 
anyway, checking if someone will give the review is already part of the 
proposal: the "asking a review on a weekly basis" meant this. Making 
this more explicit would help?



If not, 

Re: [Spice-devel] SPICE: changing the merge rules - a proposal

[Marc-André Lureau]

Hi

On Fri, May 15, 2020 at 7:06 PM Francesco Giudici 
wrote:

> Hi,
>the community around the SPICE project always tried to follow one
> fundamental, implicit rule for accepting code contributions to the
> project: every merge request (beside trivial patches) should be reviewed
> and acked at least by one before getting merged.
> While everyone agrees with this fundamental rule, the actual status of
> some SPICE projects makes the rule impractical to let the project move
> forward.
>

I wasn't aware of a maintenance problem. Perhaps we should first list the
projects that have maintenance issues & discuss our options, before
changing the common rule.

Let's consider the spice/spice project as an example: the number of
> contributions is very low, both on the commit side (only 4 different
> contributors with more than 1 commit from the beginning of the year, and
> a single contributor with 90% of commits) and on the review side (in the
> last 40 merge requests before the C++ switch one, 21 had no comments).
>

You are omitting the passive reviewers. I consider myself as one of them.
If you need people to be more proactive, you could at least reach me &
probably others past contributors.

The x11spice project is another example: we have only 4 contributors
> from the beginning of the year (and a single contributor holding 70% of
> the commits) and the reviews on the gitlab merge requests have been
> provided by two people only, each one reviewing the merge requests of
> the other.
>

As projects become more specific/marginal, it's clear that the number of
maintainers is lower. Yet, we have those projects under the same umbrella,
and I don't think they should be treated differently. 2 active
developers/maintainers can be very healthy, I would say. So do we have a
maintenance issue with x11spice? Do we want to move the project out of the
"Spice-space" projects for ex? What is the problem exactly?

For the sake of having the projects being able to move forward with a
> reduced number of contributors/reviewers, the proposal is to *allow* a
> maintainer to merge a Merge Request without an explicit ack if the three
> following conditions are met:
> 1) The Merge Request has been pending for at least 3 weeks without
> getting new comments
> 2) The Merge Request submitter has kept asking a review on a weekly basis
> 3) There are no pending nacks on the Merge Request
>
>
It's hard to define a delay to bypass a reviewing & consensus rule. In
general, it should really be frowned upon. There is clearly more than one
person interested and using Spice. If the issue is important, it should be
fairly easy to get someone else to look at the issue in a timely manner. If
not, there are probably more important/interesting things to do to get
other interested.

If Spice is good enough for our users and interested parties, then it may
be risky to change it in wild directions without their approval.

But 3 weeks is way too short. You could have more important work, family
issue, get sick and go on holiday, all happening each after the other. If
we need you to review some code, because you have the best experience, we
should wait. If really we want a delay, I would argue waiting 3 months
minimum (there might be exceptional circumstances, but they are exception,
not the rule). And during that time, the contributor should have attempted
multiple time to involve people, by different means (at least ML, irc and
gitlab issue+MR - eventually try a conf call to explain the motivation,
present the work differently etc, complain about the Spice project laziness
on public blog if need be etc).


Note that having patches reviewed would still be the preferred way. If
> at any time the number of contributors would raise again, we can switch
> back to the mandatory review rule. Until then the priority is to allow
> the project to move forward.
>
> What do you think? Please share your thoughts and/or contribute with
> your own ideas.
>

Thanks, but I think the trivial rule is already very subtle and generally
disapproved (fwiw, I am still in favor of a subjective trivial rule), so I
don't think this proposal would work.

We have to grow a community, by convincing people and doing interesting
work. Not by doing personal thing, and then leave the pieces behind,
because we did it alone and didn't gather others.

Perhaps Spice is doing the job. Perhaps Spice needs to define new
objectives. These are interesting topics that I believe people would want
to discuss and participate. If not, we are doing it wrong.

thanks

-- 
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] SPICE: changing the merge rules - a proposal

[Francesco Giudici]

Hi,
  the community around the SPICE project always tried to follow one 
fundamental, implicit rule for accepting code contributions to the 
project: every merge request (beside trivial patches) should be reviewed 
and acked at least by one before getting merged.
While everyone agrees with this fundamental rule, the actual status of 
some SPICE projects makes the rule impractical to let the project move 
forward.
Let's consider the spice/spice project as an example: the number of 
contributions is very low, both on the commit side (only 4 different 
contributors with more than 1 commit from the beginning of the year, and 
a single contributor with 90% of commits) and on the review side (in the 
last 40 merge requests before the C++ switch one, 21 had no comments).
The x11spice project is another example: we have only 4 contributors 
from the beginning of the year (and a single contributor holding 70% of 
the commits) and the reviews on the gitlab merge requests have been 
provided by two people only, each one reviewing the merge requests of 
the other.
For the sake of having the projects being able to move forward with a 
reduced number of contributors/reviewers, the proposal is to *allow* a 
maintainer to merge a Merge Request without an explicit ack if the three 
following conditions are met:
1) The Merge Request has been pending for at least 3 weeks without 
getting new comments

2) The Merge Request submitter has kept asking a review on a weekly basis
3) There are no pending nacks on the Merge Request

Note that having patches reviewed would still be the preferred way. If 
at any time the number of contributors would raise again, we can switch 
back to the mandatory review rule. Until then the priority is to allow 
the project to move forward.


What do you think? Please share your thoughts and/or contribute with 
your own ideas.


Thanks

Francesco

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel