Dnia 2014-09-14, o godz. 15:40:06
Davide Pesavento <p...@gentoo.org> napisał(a):

> On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny <mgo...@gentoo.org> wrote:
> > We have main developer repo where developers work & commit and are
> > relatively happy. For every push into developer repo, automated magic
> > thingie merges stuff into user sync repo and updates the metadata cache
> > there.
> 
> How long does the md5-cache regeneration process take? Are you sure it
> will be able to keep up with the rate of pushes to the repo during
> "peak hours"? If not, maybe we could use a time-based thing similar to
> the current cvs->rsync synchronization.

This strongly depends on how much data is there to update. A few
ebuilds are quite fast, eclass change isn't ;). I was thinking of
something along the lines of, in pseudo-code speaking:

  systemctl restart cache-regen

That is, we start the regen on every update. If it finishes in time, it
commits the new metadata. If another update occurs during regen, we
just restart it to let it catch the new data.

Of course, if we can't spare the resources to do intermediate updates,
we may as well switch to cron-based update method.

> [...]
> > In any case, we would likely strip the history anyway to get a small
> > repo to work with.
> >
> > I have prepared a basic git update hook that keeps master clean
> > and attached it to the bug [1]. It enforces basic policies, prevents
> > forced updates and checks GPG signatures on left-most history line. It
> > can also be extended to do more extensive tree checks.
> 
> Are we going to disallow merge commits and ask devs to rebase local
> changes in order to keep the history "clean"?

I don't think we should cripple git. Just to be clear, 'accidental'
merges won't happen because the automatic merges are unsigned
and the 'update' hook will refuse them.

The developers will have to either rebase and resign the commits, or
use a signed merge commit whichever makes more sense in particular
context.

Signed merge commits will also allow merging user-submitted changes
while preserving original history.

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: PGP signature

Reply via email to