Re: [gentoo-dev] gentoo git workflow

[Rich Freeman]

On Mon, Sep 15, 2014 at 9:13 AM, hasufell <hasufell@g.o> wrote:
> Yes, you have to rerun repoman after a rebase or merge. On the tip of
> the local master branch (as in: right before you try to push).
>
> Sure, this may lead to problems if repoman takes long... but that's on
> purpose. If your changes are that big, then they should be communicated
> and coordinated properly without people randomly pushing changes in
> between that may break yours.

What do you mean by proper coordination?  Are you suggesting that we
have scheduled downtime anytime we do a kde stablereq or something
like that, once per arch?

Simply announcing the change isn't going to make repoman run any
faster.  If you try to stablize something like kde and the packages
are in more than one category, then you will need something like
10-20min of tree downtime to do a commit if you have to do a repoman
scan in the middle on spinning disks.  If somebody so much as does a
whitespace fix on a completely unrelated package you won't get a
fast-forward commit.

I'm all for consistency, but repoman against the entire tree is not
fast, and if you ban non-fast-forward commits then effectively all git
commits collide.  Combining the two makes the collision window
unsuitable for commits even in the middle of the night.

So, unless we want to schedule all multi-category commits and build
some kind of mechanism to even enforce this, I think we'll have to
live with trusting devs to just run repoman before their final
merge/rebase, and then they can use their judgment about whether it
will cause problems.  I'm not saying that many big changes shouldn't
be coordinated, but that shouldn't apply to every kde stablereq/etc.
I think that this will still be a big improvement on what we have
today.

--
Rich