Hi,

On Mon, 18 Jul 2016 17:20:50 -0400 Rich Freeman wrote:
> On Sat, Jul 16, 2016 at 5:33 AM, Andrew Savchenko <[email protected]> wrote:
> >
> > On Fri, 15 Jul 2016 18:03:30 +0000 Robin H. Johnson wrote:
> >>
> >> The tolerances are presently set to:
> >> - 5 seconds of clock drift.
> >
> > Set it for a minute or two. This will protect from commits from
> > really out-of-sync systems (like 14 days mentioned above) and will
> > keep usablity hight for others.
> 
> I'll defer to infra on how much they can accept, but I tend to think
> that we can afford to be a bit more liberal.  However, I don't think
> we want to accept things like systems coming out of suspend that are
> off by hours.

Nobody asks for hours :) 5 minutes should be fine and sane.

> >
> >> - 'git push' must be completed in 60 seconds.
> >
> > Why?! What is wrong if push will take 120 seconds? I often commit
> > from quite an old box and git push takes 20-40 seconds, while this
> > is within your limits, the margin is not safe.
> >
> > What if someone needs to commit via 2G GPRS or similar slow network
> > link? Afaik we have developers on quite slow and unstable links.
> >
> > Just set this limit to 5 minutes to make it a sane protection of a
> > stale push.
> >
> 
> Somebody can correct me if I'm wrong, but I'm pretty sure that only
> one person can be pushing anything at time.

Indeed so.

> So, regardless of any
> rsync limitations, I'm not sure we really want developers to be
> spending 5 minutes doing a push.  That means that if anybody else does
> a commit during that 5 minutes they're going to have to rebase it.

Let us consider which way we'll make more harm than good.

If git push takes longer than a minute due to a slow box or a bad
uplink, there is no way to fix this. If current limit will be
enforced further, we'll actually ban developers with slow
environment from contributing to Gentoo.

As for rebasing, this is simple and can be automated by
pull.rebase=true (it should be disabled during merge commits and
can be done so on the command line of course, but random merge
commits are not welcomed due to our git workflow policy, so this is
a rare event).

If I understand a reasoning behind the git push time constraint
correctly, it is needed as a safeguard from stale pushes, so events
where push takes > 1 minute should be very rare, thus a little harm
can be done by raising git push limit to 5 minutes.

Best regards,
Andrew Savchenko

Attachment: pgpyDRzcw6LFA.pgp
Description: PGP signature

Reply via email to