| 1 |
On Sun, 5 Apr 2015 14:50:44 -0500 William Hubbs wrote: |
| 2 |
[...] |
| 3 |
> > I wonder if maybe we should suggest to finally move ia64/alpha/sparc to |
| 4 |
> > testing (as was done for mips, sh...) :/ |
| 5 |
> |
| 6 |
> Also let's add ppc and ppc64 to this list; they were brought up in the |
| 7 |
> message starting this discussion. I personally would vote for moving all |
| 8 |
> of these arch's to exp status. |
| 9 |
> |
| 10 |
> That becomes a separate action and does not answer the underlying |
| 11 |
> question that keeps coming up. |
| 12 |
> |
| 13 |
> That question is, if a maintainer opens a stable request and assigns an |
| 14 |
> arch team to it, and that arch team has no activity on the stable |
| 15 |
> request for 90 days, what should the maintainer do? |
| 16 |
> |
| 17 |
> I would say that the maintainer can at their discression remove the |
| 18 |
> old stable version. Yes, that would temporarily break the stable |
| 19 |
> depgraph, but it could be argued that the old version is by definition |
| 20 |
> broken since the newer version the maintainer wants stabilized could |
| 21 |
> have fixes for bugs in the old version. |
| 22 |
|
| 23 |
Why to apply for actions such extreme as moving arch to dev/exp |
| 24 |
state or breaking its stable tree? There are more elegant solutions |
| 25 |
available. |
| 26 |
|
| 27 |
0. Set "deadline" to 90 days for ordinary stable requests and 30 |
| 28 |
days for security-related stable requests. Numbers are may be |
| 29 |
discussed and changed, but the idea is that time constraints for |
| 30 |
response on security issues (especially critical security issues) |
| 31 |
should be tighter than for ordinary bugs. |
| 32 |
|
| 33 |
Then if time limits above are expired: |
| 34 |
|
| 35 |
1. If developers have an access to a setup for an affected arch |
| 36 |
(e.g. can test packages on that arch), allow developers to stabilize |
| 37 |
packages themselves. |
| 38 |
|
| 39 |
2. Otherwise allow developers to drop stable keywords from affected |
| 40 |
package and _all_ its reverse dependencies. This way a part of |
| 41 |
stable tree will be removed, but only a part. With this approach |
| 42 |
arch teams will be freed of an extra burden, while they will be |
| 43 |
still able to maintain a smaller stable tree. |
| 44 |
|
| 45 |
This is a win-win solution: a stable tree will be still kept in a |
| 46 |
maintainable size and developers will not have a long-term blockers |
| 47 |
on their stabilization requests. |
| 48 |
|
| 49 |
3. And last but not the least: apply the rules above to all arches, |
| 50 |
not just minor teams (though probability that amd64/x86 will be |
| 51 |
slow is lower, of course). |
| 52 |
|
| 53 |
Best regards, |
| 54 |
Andrew Savchenko |
Archives