public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Andrew Savchenko <bircoph@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Signed push & clock drift rejection
Date: Tue, 19 Jul 2016 20:20:49 +0300	[thread overview]
Message-ID: <20160719202049.038e47e82a12f9d8a3001016@gentoo.org> (raw)
In-Reply-To: <CAGfcS_nRq-YjXZRD2h+unEHufn7vdYHJsj+6-fGO7d4XPwu56g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

Hi,

On Mon, 18 Jul 2016 17:20:50 -0400 Rich Freeman wrote:
> On Sat, Jul 16, 2016 at 5:33 AM, Andrew Savchenko <bircoph@gentoo.org> 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 #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-07-19 17:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 18:03 [gentoo-dev] Signed push & clock drift rejection Robin H. Johnson
2016-07-16  9:33 ` Andrew Savchenko
2016-07-18  1:12   ` Rafael Goncalves Martins
2016-07-18 20:03     ` Marc Schiffbauer
2016-07-18 20:27       ` Andrew Savchenko
2016-07-19  2:21         ` waltdnes
2016-07-19  2:37           ` Kent Fredric
2016-07-19  8:07             ` Chí-Thanh Christopher Nguyễn
2016-07-19 11:29               ` waltdnes
2016-07-19 15:42                 ` Chí-Thanh Christopher Nguyễn
2016-07-19 18:23           ` Andrew Savchenko
2016-07-19 19:28             ` R0b0t1
2016-07-19 20:22             ` Patrick McLean
2016-07-19 20:28               ` Patrick McLean
2016-07-19 20:34             ` Alec Warner
2016-07-18 21:25       ` james
2016-07-18 23:06         ` Mart Raudsepp
2016-07-18 23:34           ` Bill Kenworthy
2016-07-19  8:09         ` Andrew Savchenko
2016-07-19 15:46       ` Michał Górny
2016-07-18 20:35     ` Ulrich Mueller
2016-07-18 21:20   ` Rich Freeman
2016-07-19 17:20     ` Andrew Savchenko [this message]
2016-07-19 11:31 ` Consus
2016-07-19 20:22   ` Alec Warner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160719202049.038e47e82a12f9d8a3001016@gentoo.org \
    --to=bircoph@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox