| 1 |
El dom, 16-02-2014 a las 09:03 -0500, Rich Freeman escribió: |
| 2 |
> On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos <pacho@g.o> wrote: |
| 3 |
> > Also, keeping the bugs assigned to package maintainers will still allow |
| 4 |
> > them to try to get that pending bugs fixed (or resolved in some way) as |
| 5 |
> > they will take care more about that specific package status. If we get |
| 6 |
> > that bugs assigned to arch teams, they will likely be ignored by both |
| 7 |
> > parts, getting worse. |
| 8 |
> |
| 9 |
> Well, that depends on your perspective. If they fix them by deleting |
| 10 |
> the old version, then whether they've made things better or worse is a |
| 11 |
> matter of philosophy. |
| 12 |
|
| 13 |
I think that, if they delete del old version without breaking the tree |
| 14 |
(and, then, moving the package to testing for that arch), the situation |
| 15 |
is improved. But, if the bug is assigned to the same team that cannot |
| 16 |
handle its stabilization, I doubt they will move it to testing either. |
| 17 |
|
| 18 |
> |
| 19 |
> That's basically the counter-argument to removing old versions. If |
| 20 |
> the newer version doesn't work at all, then the old buggy version is |
| 21 |
> superior. It is better to have the bugs ignored, than to pester the |
| 22 |
> maintainer until the package is disabled entirely. |
| 23 |
|
| 24 |
But, I guess there are two major cases: |
| 25 |
- Versions that cannot be stabilized due they not working on that arch |
| 26 |
any longer |
| 27 |
- Versions that are not stabilized because arch team doesn't have the |
| 28 |
man power to do that. |
| 29 |
|
| 30 |
I am referring to the second case that is also really common. This also |
| 31 |
raises again the question about being enough to do build tests for that |
| 32 |
arches or not. If that is the case, would be nice if maintainers could |
| 33 |
have access to that machines to let us help them :) (if I would build |
| 34 |
them on that arches, I would try to help for sure) |
Archives