[fpc-other] Git & SVN

[Marco van de Voort]

In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > how to avoid that a push of member X doesn't leave a branch in an
> > undesirable state that leaves member Y three choices:
> 
> How to avoid that member X with commit write access doesn't leave a branch
> in SVN in an undesirable state? :) You have to trust people, and choose
> who you give write access to a given branch/repository, really. This
> didn't really change and not an argument against git.

Trust is that people are not deliberately doing things. For accidental
things there are tools (except GIT, apparently)
 
> And well, in Git you don't push, but people who want to contribute, have a
> pull request. Then you can review that, and either apply to your tree or
> reject it. It's important to understand that in git all repositories are
> equal, and that I have a "make-amiga-great-again" branch, doesn't mean
> that you should have it, I could still send a pull request against your
> master branch, or whatever branch. All pull requests are just a set of
> changes, really.

Yeah, blabla, distributed, anarchy, world domination. I though I did mention
I wanted practical info?

> > 1. push anyway and make the mess worse
> > 2. hold the commit/push
> > 3. clean the mess himself.
> 
> Well, ideally 

I was not asking for ideally. I was asking very specifically how a GIT in a
FPC team group would work.

And no, sending 40+ pull requests to all members of core does not count. So
there is one golden repo and that is what I'm talking about.

> easily. It's the responsibility of the maintainer of a given branch to
> accept that pull request or not, or request further changes before its
> accepted.

So tool failure is fixed by throwing manpower at it?

We don't have an approval person now, so a requirement to that would IMHO be
a dealbreaker for GIT.

> And talking about myself - as much as I enjoy just committing my crap to
> trunk, I sometimes would really prefer review. Not because I'm not a
> senior engineer, but especially because of that... Now if I don't want to
> do a branch in SVN which are huge and expensive (Git branches are cheap
> and small), I either have to commit it first anyway to trunk, then ask for
> a review, or send a patch for review first in e-mail, which is quite
> cumbersome. Plus there's absolutely no warranty, that I later commit the
> same patch which was reviewed.

I would like to have lots of extra manpower too, but I rather not spend it
on what in practice would be rubberstamping commits (and delays in 
distribution till something is approved if the reviewers are AFK). 

This is exactly what I wanted to avoid with the primary case posed in this
subthread: how to avoid blocking the central repo for commits (from a
practical viewpoint)
 
> At work, I don't even push against master, but I do a pull request against
> my own repository, and ask one of my senior colleagues to review... I
> don't know about you, but to me this sounds a lot more like teamwork, than
> going around beating up people "for wrongdoing" with a cluestick.

Then you don't understand what I mean. In the job you go see the person,
work something out, and problem sorted in a few minutes. The odd impossible
person is usually swiftly dealt with.

In distributed, volunteer driven, projects, people are away/nonresponsive for
extended periods of time, working hours (and days) don't match. Also working
this out via mail is much less productive.

> Of course in the end it's just like crypto - you need to have a chain of
> trust from the top, a group of trustees who will do the actual merging of
> the pull requests, reviews and then push it upstream/mainline/trunk. If
> one of these maintainers do a bad job, then you need to sort out that
> problem, but that doesn't mean the whole system is broken. It's similar to
> giving commit access to a developer who doesn't deserve it in SVN, really.

I know what an honor-system is. It doesn't protect against mistakes the day
before holiday. Remember the old locking VCSes ?

> Now, how the actual process would look with the FPC team, that's hard to
> define at this point. But the tools are there for it.
> 
> Was this a proper answer, or I was beating around the bush in your views?
> :)

Sorry to say, but I didn't find anything new or usable in this post. It is
the standard "think different" nonsense from a very idealist viewpoint,
little practical details.

So I now give up this thread (and GIT).