On Mon, Sep 15, 2014 at 9:13 AM, hasufell <hasuf...@gentoo.org> 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
