On Wed, 18 Jan 2017 10:48:18 +0100
Dirkjan Ochtman wrote:
> This doesn't ring intuitively true for me. Maybe you're talking about
> running a "repoman full" for every committed package; I'm not. The
> checks Doug describes are all package-local. What makes this process
> so
On Wed, Jan 18, 2017 at 10:04 AM, Kent Fredric wrote:
> That's not viable, mostly because the performance cost of doing so is
> significantly
> time consuming, that it would block `git push` for minutes at a time, and all
> users
> performing pushes would have to wait in a
On 18/01/17 09:04, Kent Fredric wrote:
> On Wed, 18 Jan 2017 08:19:19 +0100
> Dirkjan Ochtman wrote:
>
>>
>> That makes sense. My other comment initially reading your email would
>> be, send those emails to gentoo-core or -project or whatever. If
>> others don't get to feel the
On Wed, 18 Jan 2017 08:19:19 +0100
Dirkjan Ochtman wrote:
> This sounds like a much better strategy to me. We're expecting people
> to check things that should be easy to check for machines. Yes, some
> people (like myself) will always use repoman to commit, but it would
> be
On Wed, Jan 18, 2017 at 5:58 AM, Doug Freed wrote:
> At some point, the repoman manifest-check, or some variation of it,
> will probably get added to a post-receive hook, which will then abort
> your push if you try to push something that would break the conversion
> process.
Oh, I missed some things. First off, a general timeline of rsync-gen
events (all times occur every hour at roughly specified minute after
the hour):
:00 / :30 - current state of git tree is checked out on git server and
then rsynced to private master rsync server - this is your cutoff time
for