| 1 |
On Mon, Jun 28, 2010 at 3:08 AM, Markos Chandras <hwoarang@g.o> wrote: |
| 2 |
> On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote: |
| 3 |
>> Now *this* is a problem. We have some bugs, some security bugs that |
| 4 |
>> have been completely ignored by some arches. Mips as usual is one, but |
| 5 |
>> recently hppa (and to a much lesser extent, ppc64) have become slow. |
| 6 |
>> |
| 7 |
>> To fix this, I suggest the following heuristic: |
| 8 |
>> |
| 9 |
>> * If an arch cannot stabilize *security bugs* after 3 months, the |
| 10 |
>> maintainers are free to drop the vulnerable version. |
| 11 |
> |
| 12 |
> What if this version is the only one that is stabled for this arch. Can |
| 13 |
> you imagine the possible breakage that this action might cause? |
| 14 |
> |
| 15 |
> The problem is exactly here. |
| 16 |
> |
| 17 |
> If a package has only one version stable for an exotic arch, you cannot |
| 18 |
> drop it because: |
| 19 |
> |
| 20 |
> * you will break packages that depend on it |
| 21 |
> * you will make users angry |
| 22 |
> |
| 23 |
|
| 24 |
I agree. I didn't mean to imply that these heuristics were in any way |
| 25 |
complete. I wrote them in a hurry; I only wanted to give an idea of |
| 26 |
what my opinion on the matter is. We can add the following: |
| 27 |
|
| 28 |
* For each arch, stable keywords are to be removed from |
| 29 |
vulnerable/broken versions one week after newer versions are |
| 30 |
stabilized on that arch. |
| 31 |
* If removing stable keywords will lead to a large cascading effect of |
| 32 |
reverse dependencies losing stable keywords, the 3 month wait should |
| 33 |
be extended to 6 months or 12 months depending on the brokenness and |
| 34 |
no. of packages that will get their keywords dropped. |
| 35 |
* Maintainers are free to wait as long as they wish for arches, the |
| 36 |
above guidelines merely give a lower bound to the wait time. |
| 37 |
* In extenuating circumstances (critical vulnerabilities, complete |
| 38 |
brokenness, etc), with the permission of the QA team, the wait can be |
| 39 |
shortened, but it should never be less than a month. |
| 40 |
|
| 41 |
This means that old broken/vulnerable ebuilds are not visible to any |
| 42 |
arches except those that are slow. And if an arch cannot take out the |
| 43 |
time to stabilized a vulnerable and/or badly broken version for a full |
| 44 |
year, there's nothing we can do. If this is a chronic problem, we |
| 45 |
should consider marking the arch as "Experimental". |
| 46 |
|
| 47 |
-- |
| 48 |
~Nirbheek Chauhan |
| 49 |
|
| 50 |
Gentoo GNOME+Mozilla Team |
Archives