| 1 |
On Thu, 23 May 2013 23:40:42 -0600 |
| 2 |
Ryan Hill <dirtyepic@g.o> wrote: |
| 3 |
|
| 4 |
> Okay, so what are you using the STABLEREQ keyword for that you want |
| 5 |
> to set it when the bug is filed but before archs are added? If you |
| 6 |
> want to see only stabilization bugs you can search in the Keywording |
| 7 |
> and Stabilization component. Can you suggest another way to search |
| 8 |
> for stabilization bugs that don't yet have archs CC'd (which is |
| 9 |
> something I find rather useful)? |
| 10 |
|
| 11 |
We could split up [Keywording and Stabilization] into separate |
| 12 |
components, [Keywording] and [Stabilization], but then |
| 13 |
|
| 14 |
1) people would still forget to set it, at whatever stage, and |
| 15 |
2) this wouldn't fit with [Security]/[Vulnerabilities]. |
| 16 |
|
| 17 |
It's important to be able to distinguish between STABLEREQ and |
| 18 |
KEYWORDREQ. I think a KEYWORDREQ should normally be handled earlier than |
| 19 |
any STABLEREQ /unless/ the STABLEREQ fixes a security bug, since |
| 20 |
being late getting keywords back up to par with other architectures |
| 21 |
tends to make an even bigger mess further on. |
| 22 |
|
| 23 |
Alternatively, we could set CONFIRMED or IN_PROGRESS when a) the |
| 24 |
Component is [Keywording and Stabilization] and b) arch teams are |
| 25 |
CC'd, but then everyone would forget to set that half the time, too. |
| 26 |
|
| 27 |
|
| 28 |
jer |
Archives