Rich Freeman: > 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? >
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.
