[Spice-devel] Survey of repository preferences

[Frediano Ziglio]

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

usually in git you create your branch in your repository. This branch
will be checked against CI so before the patch would be integrated in
master.

> merge request to gitlab/master (sends patch, etc)

This can be done too without the main repository in gitlab.

> merge to master (CI happens here too)

Yes, this would require some additional effort to do in freedesktop
instead of gitlab.

> This ensures that CI tests run for every commit and before merge to master,
> not once a day and after merge.

As I said this would be the case even if the official master is on freedesktop,
the CI tests would be run on the personal repositories.

Note: I'm not expressing my opinion or how it should work, just how can work
without moving the repository.
Personally I don't feel moving the official repository too complicated.

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

This is much a good reason to switch to gitlab then MRs/PRs.

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

In case of someone pushing directly to gitlab we could avoid the
-f during the push and manually sync the 2 repositories.
Mistakes happens.


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

...

IMHO all renames/submodule discussions should go to a different thread
and we should discuss it later.

For some reason the format of the reply is getting weird. To sum up:
- we can use MR/PR and CI on gitlab without moving the official
  repository to gitlab, just we cannot merge directly from the MR/PR.

Maybe another question to ask is how and if we want to use the PR.
- should PR be mandatory? If the reason (my initial one) were
  tracking the answer should be yes, that is all patches on the ML
  should came from a PR;
- can we setup PR so it send a mail to the ML for every
  open/comment/change?
- should we review only using the PR, that is no reply on mails?
  From what I can see in other comment I feel the sensation is no,
  maybe we can vote on this point.

Frediano