[Spice-devel] Survey of repository preferences

Fri Jul 28 07:15:46 UTC 2017

> On 27 Jul 2017, at 17:07, Marc-André Lureau <marcandre.lureau at redhat.com> wrote:
> 
> Hi
> 
> ----- Original Message -----
>>> I think we should rather find a consensus on the mailing list rather than
>>> avoiding the discussion.
>> 
>> “Avoiding the discussion" sounds like a cheap and unjustified shot. Please
>> discuss.
> 
> You are the one making proposal, you should come up with rationale. but ok

As I wrote, the rationale was discussed on this list between yesterday and today. I’ll repeat it here. Now, you were the one saying there were “problems”. I cannot guess the problems you have with my proposals if you don’t discuss them.

> 
>> 
>>> 
> 
> - Use gitlab/github as primary, make freedesktop a mirror *?
> 
> What benefit does that bring?

It is to get these additional features, that AFAIK freedesktop lacks:

1. Continuous integration
2. Merge requests or pull requests
3. Being actually open (reported by Christophe Fergeau). For example, it took me 6 months to get a working freedesktop account

> The canonical source is hosted on freedesktop for ages.

That does not need to change.

> The role of this is a stable & controlled git repo to pull/push code to.

Why do I get a sense that “controlled” is the keyword here? ;-)

> Moving it to a different location doesn't change that. Using github/gitlab as mirrors allows to have all the benefits of those hosting services.

To the best of my knowledge, that statement is incorrect

Specifically, we cannot enable merge requests on a mirror easily, because that means if we accept the merge request on gitlab, then gitlab is ahead of freedesktop, and when we push from freedesktop, that push is either rejected, or if we use push -f, we lose the merge.

Similarly, continuous integration on development branches, i.e. before we actually merge them, is not possible with freedesktop, even less so if your sense of “control” means you feel it’s OK to delete a review branch I push there without asking me first. All that is a bit moot anyway, because Google “freedesktop continuous integration” gives me nothing on the first page. 

> So why?

Because I think that continuous integration and a list of pending merge requests are more important than preserving the “we have been doing that for ages” comfort zone.

> 
> - Rename spice as spice-server

- To unambiguously leave ‘spice’ as the name for a top-level repository.
- So that mail-processing script does not have to do extra ad-hockery to map [PATCH spice-server] to a repo not named spice-server

Apparently, I’m not the first one to have the (obvious) idea, cf https://cgit.freedesktop.org/spice/spice-server (yet another confusing thing for newbies ;-)

> - Rename other repositories so that all children repos begin with 'spice-' *
> 
> I wasn't aware of that discussion, but changing a project name brings a number of issues for distributions and people watching releases etc. Renaming stuff is always problematic, what is the benefit?

Mostly to disambiguate between modules we really own (most of them) and modules that seem to be external dependencies for the spice project. For example, are libcacard or usbredir used by other projects?

Is spice/qemu an external dependency, is it there fore convenience? Or is that just obsolete? What about spice/spicec, spice/vdesktop, … I have a feeling there are a few stale repositories there.

The logical structure found in https://cgit.freedesktop.org/spice is nice. It’s not clearly visible e.g. on spice-space.org. And AFAIK, it’s not visible to git.

> 
> - Create top-level repository with all others repositories as submodules (if we use 'spice-server', that one would be called 'spice') *
> 
> Isn't this already the case? https://cgit.freedesktop.org/spice/

If that’s the case, it’s cool. But it looks like a group of repositories in freedesktop, more than a repository with submodules. What is the git clone command to clone that top-level repo?

Having a top-level repository makes work on branches that impact multiple components easier. Case in point today: streaming impacts server, protocol, agent, client, etc. So being able to easily switch to the “stream” branch and update protocol, agent, client and server in one command (ok, two, git checkout following by git submodule update) is useful.

> 
> How you really mean "git submodules".. Eh, what's the point? Sounds very wrong and useless to me, it will be constantly outdated.. Write a script instead?

What I really mean is something like this: https://gitlab.com/c3d/spice. I did that quickly, but ultimately, I’d like to have READMEs and global build scripts, to put spice-space repositories under “docs”, that kind of things.

> 
> - Make spice-protocol a submodule of modules that use it 
> 
> We have been there before with spice-gtk/spice-common, and it was reverted.

But spice-common is still a submodule, so I don’t understand why you bring it up. Unless you are talking about removal of spice-protocol in spice 0.12.6 ? If that’s the case, I don’t see much of a discussion around https://lists.freedesktop.org/archives/spice-devel/2015-August/021312.html, just the justification “it’s stable, so we don’t need to bundle it”. I looked in the mails for the three months prior to that looking for clues as to why submodules were such a problem, didn’t find any.

> The main issue was that every project ended-up bundling spice-protocol.

Well, that’s sort of the point of submodules. I don’t see how this is a problem.

> (and others keep complaining about various submodules issues)

Let me guess: dangling SHA1 because people kept forgetting to push changes to the submodule? Hmmm, but if the module is stable, that should practically never happen.

> Since spice-protocol is very stable, it's actually best to keep it standalone.

From a git perspective, this sentence makes no sense whatsoever. Most submodule-related issues tend to occur with active submodules, not with stable ones.

In any case, right now there are changes related to streaming. The diffs look like this: https://github.com/SPICE/spice-protocol/compare/master...c3d:stream.

I find it annoying that the “canonical” source for these changes is, to the best of my understanding, git://people.freedesktop.org/~fziglio/spice-protocol, a personal branch. That’s OK as long as Frediano is the only one working on it. But that’s no longer the case. So now, we all build servers that have this implicit requirement that you need some personal branch hidden somewhere on the Internet (go look it up), with no dedicated version number, and API stability sounds just like a misguided on-principle excuse to avoid addressing a very concrete problem.

> In all cases, it's a pain to change that, so please no…

Well, the change that removed it looks like this: https://lists.freedesktop.org/archives/spice-devel/2015-August/021312.html. Is that really a pain? Or is there more to it?

I’m not advocating against making separate builds for spice-protocol. I’m advocating against developing changes to spice-server and spice-client that require an ad-hoc personal branch, without letting us know if / when that branch changes. Something which submodule deal with perfectly.

> - Use merge requests or pull requests for my own code *
> - Have others use merge requests or pull requests *
> - Require patches to also be sent to mailing list for all merge/pull requests *
> 
> As long as patch are reviewed on ML, I am fine with all that.

Good. Thanks.

> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel