| 1 |
On Sun, 16 Feb 2014 15:53:57 +0100 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
|
| 4 |
In this case: |
| 5 |
|
| 6 |
> > > - Versions that are not stabilized because arch team doesn't have |
| 7 |
> > > the man power to do that. |
| 8 |
> > |
| 9 |
> > As above, package.mask would be a good intermediate solution, |
| 10 |
> > communicating the problem to the arch users for, say, thirty days. |
| 11 |
> > Of course it may just delay solving the problem when a new set of |
| 12 |
> > stabilisations is due and again no one responds. |
| 13 |
> |
| 14 |
> I disagree in this case as the package can still be in "testing", not |
| 15 |
> like the above case that, if the package is broken, it shouldn't be |
| 16 |
> neither in testing tree. |
| 17 |
|
| 18 |
In this case, a newer version hasn't been (sufficiently) tested on a |
| 19 |
certain architecture, so it is still in the "testing" phase. In this |
| 20 |
case, you haven't established that it's broken. |
| 21 |
|
| 22 |
Also, the general idea is to temporarily mask the _old_ stable |
| 23 |
version(s) on the arch profile and not _all_ versions. |
| 24 |
|
| 25 |
|
| 26 |
jer |
Archives