Re: [gentoo-dev] gentoo git workflow

[hasufell]

Ian Stakenvicius:
>
> I'm not that worried about the big (multi-package) commits, as it does
> make sense we're going to have difficulty and lots of potential
> conflicts there, but aren't we going to run into this issue just with
> multiple people committing separate single-package commits at the same
> time??
>

Yes. If that becomes a major problem, then we have to say goodbye to the
central repository workflow, because we either
* allow inconsistency and broken states as we do now with CVS (and rely
  on QA to run a repoman tinderbox and reverse-fixing broken crap)
* require devs to rebase+merge and rerun repoman 10+ times in order to
  get a single commit pushed

It is already pretty gross and broken to have ~200 people have direct
push access to a single repository.

However, having ~150 commits per day I don't think this commit rate is
high enough to deadlock push access.

git pull --rebase=preserve && repoman full && git push origin master

or something similar. This can even be implemented a bit more sanely
within repoman or another script, but I don't think we need that yet.

It's also possible that projects start accumulating changes in branches
or even their own repositories to minimize the amount of pushes to
master. The merge-rate will be something that has to be dynamically
figured out and will improve tree quality.

We shouldn't try to map our CVS workflow 1:1 to git, so there have to be
changes in workflow. The optimum would be to have a real review workflow
enforced with only a handful of people having direct push access, but I
doubt this will work in our current community and mindset.
However, such a review workflow can dynamically evolve, because it's git
after all! If that happens, we can just make it a policy at some point
or even implement it on infra-level.