[Spice-devel] Survey of repository preferences

[Frediano Ziglio]

> 
> 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
> 
> > 
> > > 
> 
> - Use gitlab/github as primary, make freedesktop a mirror *?
> 
> What benefit does that bring? The canonical source is hosted on freedesktop
> for ages. The role of this is a stable & controlled git repo to pull/push
> code to. 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. So why?
> 

I think the idea was to use kind of click to merge directly from PR

> - Rename spice as spice-server
> - 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?
> 
> - 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/
> 
> 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?
> 
> - Make spice-protocol a submodule of modules that use it
> 
> We have been there before with spice-gtk/spice-common, and it was reverted.
> The main issue was that every project ended-up bundling spice-protocol. (and
> others keep complaining about various submodules issues) Since
> spice-protocol is very stable, it's actually best to keep it standalone. In
> all cases, it's a pain to change that, so please no...
> 

All these seems not much related to tracking, I agree with Marc-andre on this.

> - 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.

If the first 2 are true and 3rd not reviewed should be done on the PR
with just (if possible, usually yes) notification in the ML.

The flow is not defined however. PRs could be just used for tracking
or avoiding entirely the ML. This maybe should be chosen before a poll.

Frediano