[Spice-devel] Survey of repository preferences
Christophe de Dinechin
dinechin at redhat.com
Mon Jul 31 07:57:41 UTC 2017
> On 28 Jul 2017, at 12:10, Pavel Grunt <pgrunt at redhat.com> wrote:
>
> Hi,
>
> On Fri, 2017-07-28 at 09:15 +0200, Christophe de Dinechin wrote:
>>> 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
>
> it can be done through mirrors (it is the case for the gitlab mirror)
Not for development branches. Today, it’s:
gitlab personal branch (some CI here)
a. send patch
b. someone else applies the patch and pushes to freedesktop (no CI here)
freedesktop replicated to gitlab after steps a and b have repeated a few times
CI applies to master on gitlab
So that means we run the CI tests only after multiple commits. I would like to migrate towards:
gitlab private branch (with CI)
merge request to gitlab/master (sends patch, etc)
merge to master (CI happens here too)
This ensures that CI tests run for every commit and before merge to master,
not once a day and after merge.
>
>> 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
>
> Yeah, you have to ping someone to open the account
That would be OK if they were responsive. But multiple months vs. minutes for gitlab?
>
>>
>>> 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.
>
> You never push to a mirror.
That’s exactly what I was saying ;-)
>
>>
>> Similarly, continuous integration on development branches,
>
> Nothing block people from having ci/scripts to test their branches.
There is no incentive to do it either. Why replicate the effort?
> Nowadays people can fork our repos at gitlab and get a simple CI for free.
> We can give this advice in README.
That is a very good thing. Why did you share it? You should apply the same logic
that led you to sharing that work to the scripts/tests you talked about above.
>
> Also a committer can push the patches to her/his gitlab fork to make sure
> everything is OK (before pushing to the main repo).
>
>> 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.
> For you, not for me :)
Nothing forces you to use or maintain it if it’s not helpful to you.
>
>> 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.
>
> It is really a personal thing, I'd not spend time implementing it on a global
> level (a super repository). [1]
FWIW, I already have, so you won’t have to. I’m still struggling about how
to organize things in there.
>
>>
>>>
>>> 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.free
>> desktop.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.
>
> The patches were sent to the ML for a review. It is a Frediano's branch, nothing
> official. The author has right to break the things if he wants.
Precisely. This is one reason I am uncomfortable working like this. Either others
need it, and then it becomes a shared branch, or it’s a personal-only branch,
and only one person works on it. But shared work based on a private branch
is a very strange (and dangerous) way to do things.
>
>> 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.
>
> Once the patches get reviewed, they may be merged to the master branch.
I’m talking here about long branched development, like the streaming work.
They are not merged to master.
> What is a difference between a personal branch and a branch at the offical repo?
Visibility. Having an implicit way to share not just the diffs (the way patches do)
but the actual branch. There is a reason kernel.org hosts git repos and not
just a mailing list with patches: git branches are much easier to deal with.
That’s why Linus “lieutenants” send him pull requests for whole branches,
and not individual patches.
If we use only a central repo with one branch, and patches exchanged by mail,
what benefit does git bring over cvs or svn?
>
> I don't see a point of maintaining more branches (especially personal) at
> freedesktop.
When you share a patch, that code is no longer personal, it is intended for
integration in master. If it’s not personal, it’s by definition no longer a personal branch.
This is even more true once more than one person is working on the code,
as is the case for streaming-related branches.
Can you see the point better if I remind you that this would help:
1. running CI before merging things,
2. having an easy-to-browse list of things to review
3. reduce the number of git remotes you need to fetch
4. make it easy to git pull the code for testing
5. ensure you knows where to look for the code without having to ask authors
6. ensure you don’t depend on private branches
7. enable long-running projects to have branches with multiple contributors?
BTW, you don’t “maintain” a review branch. You either push it, or you nuke it.
Any maintenance you would do on your private branch like today.
>
>>
>>
>>> 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.or <https://lists.freedesktop.or/>
>> g/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,
>
> Why? I hope I can still have my own branches :)
Of course! The question is how to share branches, it will certainly not prevent you from
having private branches you don’t want to share.
>
>> without letting us know if / when that branch changes. Something which
>> submodule deal with perfectly.
>
> You can
> * have a copy of the commits at your git repo
What’s the benefit of having to create a new commit, instead of reusing the one that
exists? It only introduces a possibility of error, like I could apply the patch to a different
revision, etc.
> * contact the author of the patches
Which I did. So far, about 50% of the replies I got were variants of “I don’t remember, try this one”
Of course, it did not help that we had branches for the same topic that had different names
in different repos, including in different repos from the same author…
> * keep a reference to the repo with the patches (git remote add..)
Which I did too. But the problem is that the author’s repos are usually considered
private branches, and rightfully so. They get rebased all the time, etc. There is
absolutely no expectation that the branch will stay stable.
> * review the patches and make them go to the master branch of the official repo
> (probably the best option)
That works only for patches that have reasonable chances of going to master shortly.
The whole discussion started with lost patches (Frediano), multi-repo branches
(me, for the flight recorder) and multi-user branches (streaming). In that case, the
simplistic approach you suggest does not work so well.
>
> Pavel
>
>>
>>
>>> - 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.
>>
>>
>
> [1] When I work with multiple branches, I simply install the stuff (eg.
> PKG_CONFIG_PATH=/home/pgrunt/dev-stream/share/pkgconfig:/home/pgrunt/dev-
> stream/lib/pkgconfig ./configure --prefix=/home/pgrunt/dev-stream ).
> Another thing you can do is to create rpms and install them (switch between
> them). I am used to it. I'd be confused with the super top level git repo.
A super-repo would not change any of this. You are talking about how
to build things. I am talking about how to get the source.
Thanks
Christophe
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org <mailto:Spice-devel at lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/spice-devel <https://lists.freedesktop.org/mailman/listinfo/spice-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170731/2a229318/attachment-0001.html>
More information about the Spice-devel
mailing list