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