| 1 |
On Wed, 2020-02-26 at 10:54 -0600, William Hubbs wrote: |
| 2 |
> Agreed, this is very demoralizing. Besides your suggestion of requiring |
| 3 |
> bugs to be filed, I would consider a hard timeout of 7-14 days when a |
| 4 |
> bug is filed. Once that timeout passes with no action from comrel, the |
| 5 |
> bug goes to the council. If this happens too many times (we could |
| 6 |
> discuss/agree on a number) it brings the affectiveness of comrel into |
| 7 |
> question and the council can take action such as replacing the lead. |
| 8 |
|
| 9 |
This is not that simple. While I'm not on ComRel, I can imagine |
| 10 |
the problems they need to face. |
| 11 |
|
| 12 |
Let's say someone files ComRel request with some data. Before ComRel |
| 13 |
can take any action, it probably needs to gather more data, to verify |
| 14 |
what it has, to talk to other side. Now imagine that the other side |
| 15 |
might be away, have little time, or simply be stalling. Not to mention |
| 16 |
discussion and voting lag after collecting all this. |
| 17 |
|
| 18 |
I don't think it's feasible for all this to happen within 14 days, |
| 19 |
even 30 days may be too short in some cases. If you force hard timeouts |
| 20 |
down ComRel's throat, you're going to either cause ComRel to issue |
| 21 |
premature decisions or cause issues to repeatedly move to the Council. |
| 22 |
|
| 23 |
To give a real example, it took me almost a month to communicate with |
| 24 |
a certain developer before opening a ComRel case against him. After two |
| 25 |
weeks, he requested more time to reply. So far the bug is open for over |
| 26 |
a month waiting for the reply from the other side. Do you believe |
| 27 |
ComRel should be forced to make a decision earlier and say 'sorry, we |
| 28 |
can't wait for you'? |
| 29 |
|
| 30 |
-- |
| 31 |
Best regards, |
| 32 |
Michał Górny |
Archives