| 1 |
On Thu, 22 Aug 2013 12:28:24 +0100 |
| 2 |
Markos Chandras <hwoarang@g.o> wrote: |
| 3 |
|
| 4 |
> Wow! That is something we actively encourage people to avoid. Mixed |
| 5 |
> systems are totally |
| 6 |
> unsupported and I am sure quite a few bugs are closed as invalid when |
| 7 |
> a mixed system is detected. |
| 8 |
|
| 9 |
Mixing stable and testing is precisely what arch teams (hopefully) do in |
| 10 |
testing and stabilising: building and running new software on a known |
| 11 |
to be stable platform in order to merge the new software into the |
| 12 |
stable branch (or not). |
| 13 |
|
| 14 |
Mixing stable and testing is precisely what package |
| 15 |
maintainers (hopefully) do when committing new versions: building and |
| 16 |
running new software on a known to be stable platform on the premise |
| 17 |
that the new software is likely to be merged into the stable branch |
| 18 |
(before the platform changes too much). |
| 19 |
|
| 20 |
Mixing stable and testing is what triggers users to file useful |
| 21 |
bug reports about incompatibilities between new software and stable |
| 22 |
(reverse) dependencies. |
| 23 |
|
| 24 |
Cases where reporting bugs about mixing stable and testing is (likely) |
| 25 |
invalid is when unmasking one package in the unstable branch causes |
| 26 |
(reverse) dependency resolution issues with another package in the |
| 27 |
stable branch (since users should know how to resolve those - there is |
| 28 |
generally no bug for maintainers to fix). |
| 29 |
|
| 30 |
There is a lot more to it than this, of course. I'm just pointing out |
| 31 |
some of the obvious scenarios in which mixing stable and testing should |
| 32 |
be encouraged. |
| 33 |
|
| 34 |
|
| 35 |
jer |
Archives