| 1 |
On Sun, Dec 6, 2015 at 12:26 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> |
| 3 |
>> On Dec 6, 2015, at 11:52 AM, Rich Freeman <rich0@g.o> wrote: |
| 4 |
>> |
| 5 |
>>> On Sun, Dec 6, 2015 at 11:09 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 6 |
>>> On 12/06/2015 11:00 AM, Michał Górny wrote: |
| 7 |
>>>>> |
| 8 |
>>>>> Of course. Add the commit author, too: I want to know if I break someone |
| 9 |
>>>>> else's package. |
| 10 |
>>>> |
| 11 |
>>>> So far, can't do that since we don't know which commit exactly broke. I |
| 12 |
>>>> don't want to do any heuristics that could blame the wrong person. |
| 13 |
>>> |
| 14 |
>>> Is the testing performed per-push rather than per-commit? Either way, I |
| 15 |
>>> would like to get a notification that something broke, even if it wasn't |
| 16 |
>>> my commit at fault. Just change the word "blame" to "alert" so no one |
| 17 |
>>> feels slandered. |
| 18 |
>> |
| 19 |
>> ++ |
| 20 |
>> |
| 21 |
>> This isn't about shaming people. It is about alerting that the tree |
| 22 |
>> is broken. I think we can agree that when packages don't build it is |
| 23 |
>> a problem, and it won't fix itself. |
| 24 |
>> |
| 25 |
>> How many commits typically go by in-between checks? Would it be |
| 26 |
>> practical to just alert any commit author in that time range? Sure, |
| 27 |
>> it would generate a bit of spam, but: |
| 28 |
>> |
| 29 |
>> 1. Better to get problems fixed sooner than later. |
| 30 |
>> 2. The overall improved attention to QA will hopefully reduce the |
| 31 |
>> error rate and thus make the number of emails regulate themselves. |
| 32 |
>> |
| 33 |
>> One of the first steps towards reducing errors is to increase their visibility. |
| 34 |
>> |
| 35 |
> |
| 36 |
> Couldn't we just alert the people listed in the metadata for the packages affected? Even if it wasn't them that caused the breakage, aren't they ultimately responsible for making sure the package works? They could ping the actual committer... |
| 37 |
> |
| 38 |
|
| 39 |
It is best to give feedback to those who know what they did, not to a |
| 40 |
bunch of random people who have to puzzle it out. Maybe the toolchain |
| 41 |
guys change something and 200 packages break. Now, we can all sit and |
| 42 |
stare at bizarre gcc output for an hour each trying to figure out the |
| 43 |
cause of some misleading error message, or we could let the toolchain |
| 44 |
guys know and as soon as they see 200 C-based packages break after |
| 45 |
committing a toolchain change they're going to know that they're the |
| 46 |
cause and likely what is going on. I'm not sure if the toolchain team |
| 47 |
would be better served if they get hit CC'ed on 200 carefully-crafted |
| 48 |
bug reports either, over the span of a few days as the maintainers |
| 49 |
catch up on their likely-outdated emails. |
| 50 |
|
| 51 |
By all means CC the package maintainers, since they likely do care, |
| 52 |
but they may not be in the best place to debug a problem that |
| 53 |
originated in a dependency. |
| 54 |
|
| 55 |
If we're talking about sending an email to ~5 committers just do it. |
| 56 |
If I committed a change to mythtv and perl breaks, I'll probably |
| 57 |
ignore it. If I committed a change to dar and some backup utility |
| 58 |
breaks, I'll probably take a closer look. If in a month we're sick |
| 59 |
and tired of the emails we can always give up, or start beating |
| 60 |
anybody over the head who doesn't run repoman. |
| 61 |
|
| 62 |
-- |
| 63 |
Rich |
Archives