1 |
On 08/19/2015 11:11 AM, hasufell wrote: |
2 |
> On 08/19/2015 08:00 PM, Zac Medico wrote: |
3 |
>> On 08/19/2015 10:49 AM, hasufell wrote: |
4 |
>>> And how often was that useful in practice? |
5 |
>> |
6 |
>> Well, there haven't been any EAPI bumps lately. However, in the time |
7 |
>> that follows an EAPI bump, it can be very useful if there are new |
8 |
>> dependency features that require new repoman checks. |
9 |
>> |
10 |
> |
11 |
> Still am not sure how this is useful in practice. |
12 |
> |
13 |
> Some commit is broken, someone else finds out. He runs repoman locally: |
14 |
> * repoman reports the brokenness -> ask the committer which repoman |
15 |
> version he used (and if he can reproduce it with latest stable |
16 |
> repoman) |
17 |
> * repoman does not report brokenness -> report a bug against his local |
18 |
> version after checking that he is up2date |
19 |
|
20 |
I guess that will probably work well enough. |
21 |
|
22 |
> Now with git... it is even easier to test these things, because you can |
23 |
> just jump back in time and run repoman on the offending commit. |
24 |
|
25 |
Well, that's true if they use merge commits. If they rebase, that's |
26 |
trickier. I'm not really worried about it, though. |
27 |
|
28 |
> No |
29 |
> reason to include that information in all commits, afais. And it doesn't |
30 |
> tell you much anyway, because other versions could be affected too by |
31 |
> the bug, so you end up debugging properly anyway. |
32 |
> |
33 |
|
34 |
Yeah, I'm will willing to let it go away. |
35 |
-- |
36 |
Thanks, |
37 |
Zac |