Re: [gentoo-dev] gentoo git workflow

[hasufell]

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?
>

I don't know how kde stablereqs work.

> 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.
>

Whether the package is related or not has to be verified by someone. I
doubt that a lot of people will review the changeset after a rebase or
merge and I don't have a lot of faith in people doing things right
including myself.

>
> So, unless we want to schedule all multi-category commits and build
> some kind of mechanism to even enforce this
>

Why all? If the multi-category commits are so big that you actually have
to run repoman on top-level (you could as well run it on all related
ebuild directories or on category-level), then yes... those monster
pushes should definitely be scheduled.

I think top-level repoman checks will be the exception, even for
multi-category commits.