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@xxxxxxxxxx> > > 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) > 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 > > > 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. > > Similarly, continuous integration on development branches, Nothing block people from having ci/scripts to test their branches. Nowadays people can fork our repos at gitlab and get a simple CI for free. We can give this advice in README. 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 :) > 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] > > > > > 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. > 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. What is a difference between a personal branch and a branch at the offical repo? I don't see a point of maintaining more branches (especially personal) at freedesktop. > > > > 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 > 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 :) > 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 * contact the author of the patches * keep a reference to the repo with the patches (git remote add..) * review the patches and make them go to the master branch of the official repo (probably the best option) 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. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel