1 |
Olivier Crête wrote: |
2 |
> |
3 |
> ~arch is for testing ebuilds, not the upstream package |
4 |
> |
5 |
|
6 |
I'm pretty sure this isn't the case - at least not as cleanly as you |
7 |
suggest. Certainly testing the ebuilds themselves is part of the reason |
8 |
for having ~arch, but upstream readiness is part of it as well. If a |
9 |
package hit ~arch and we got 10 serious bugs that were all upstream |
10 |
problems and then somebody filed a STABLEREQ I know that I wouldn't be |
11 |
the one to stabilize it. |
12 |
|
13 |
The whole point of having QA is so that people who don't want to be |
14 |
bothered with bleeding-edge packages aren't bothered with them. Masking |
15 |
is for packages with known serious problems, ~arch is for packages that |
16 |
we think are fine but don't have much production history with, and |
17 |
stable is for packages that are known to be decent with history. |
18 |
|
19 |
However, I'm not convinced that the 3.1 issues need to be a showstopper |
20 |
for going stable. Others have made some of these suggestions, but let |
21 |
me consolidate some ideas that have come up: |
22 |
|
23 |
1. A tracking bug should be created to track 3.1 stabilization issues |
24 |
(assuming it doesn't already exist). |
25 |
2. Portage (and other system packages) deps should be checked to ensure |
26 |
it pulls in the current version. This should be carefully coordinated. |
27 |
3. -dev-announce message sent out to check your python deps and fix |
28 |
them (logging blockers as needed). This need not be carefully coordinated. |
29 |
4. einfo message about not eselecting the new version of python. News |
30 |
message as well. |
31 |
|
32 |
As long as the current version doesn't go anywhere and the current |
33 |
version can be re-selected at-will, then I don't see how users can get |
34 |
themselves into a corner. |
35 |
|
36 |
The ability to support stuff like this is the reason we have SLOTs in |
37 |
the first place. |