On Mon, Sep 15, 2014 at 10:26 AM, Ian Stakenvicius <[email protected]> wrote: > I'm not that worried about the big (multi-package) commits, as it does > make sense we're going to have difficulty and lots of potential > conflicts there, but aren't we going to run into this issue just with > multiple people committing separate single-package commits at the same > time??
So, if you require fast-forward commits (which I think is sensible), then all commits collide. The other factor here is the time to run repoman. Running a repoman scan on a single package only takes tens of seconds, which means we're ok as long as we don't do commits every few seconds. But yes, you're right that commits of unrelated packages can potentially collide. The issue with something like kde is that the stablereqs can involve 100+ packages in several categories. Either you run repoman scan against all of them individually, or you run it at the tree level, and either way it is going to take a while to run (and if it is disk-bound, running in parallel probably won't help much). The reality is that a kde stabilization is not a huge risk. The packages are fairly contained, and they aren't system packages so if something does go wrong recovery is generally easy. I've yet to hear of something like this going badly. I think the worst I've seen is the odd package getting missed on the first pass. In any case, I don't have any hard numbers to prove that requiring repoman scans on every commit is a bad idea. However, I think that it has a large potential to make larger-scale changes difficult. It would make a lot more sense if we had a release-oriented strategy, even if releases were hourly/daily/etc. -- Rich
