1 |
El dom, 16-02-2014 a las 15:46 +0100, Jeroen Roovers escribió: |
2 |
> On Sun, 16 Feb 2014 15:18:42 +0100 |
3 |
> Pacho Ramos <pacho@g.o> wrote: |
4 |
> |
5 |
> > I think that, if they delete del old version without breaking the tree |
6 |
> > (and, then, moving the package to testing for that arch), the |
7 |
> > situation is improved. But, if the bug is assigned to the same team |
8 |
> > that cannot handle its stabilization, I doubt they will move it to |
9 |
> > testing either. |
10 |
> |
11 |
> And when you do break the tree when you threaten to effectively remove |
12 |
> an arch keyword, then you may need to dig deeper and remove more |
13 |
> keywords elsewhere until you've found an "unstable" solution. As long |
14 |
> as you communicate the solution to that team, and maybe prod someone on |
15 |
> IRC until they make the time to look at it and (reluctantly) agree, |
16 |
> there should be no problem in dropping stable for them. |
17 |
|
18 |
Yeah, I know that problem of "chain reaction" will appear (I am thinking |
19 |
in Gnome stuff for example :S), but I can't think on any better |
20 |
alternative. Will be a lot of work but will save time in the future :| |
21 |
|
22 |
> |
23 |
> > But, I guess there are two major cases: |
24 |
> > - Versions that cannot be stabilized due they not working on that arch |
25 |
> > any longer |
26 |
> |
27 |
> It's probably a good idea to package.mask the affected versions on the |
28 |
> arch profile(s) (with references to bug reports, and so on) so all users |
29 |
> of that profile get to see it. Treat it like a "last rites" process. |
30 |
> Currently that's the only way for users to find out when and why a |
31 |
> package becomes unsupported on a given profile, and it should work |
32 |
> well enough. Give them thirty days to respond or become arch team |
33 |
> members or ATs or just give the nod to an arch developer to say "it |
34 |
> works" - it may even lead to actual stabilisation of a newer ebuild. |
35 |
|
36 |
Looks interesting, maybe that would indeed help to get more people |
37 |
involved on that arch teams :O |
38 |
|
39 |
> |
40 |
> > - Versions that are not stabilized because arch team doesn't have the |
41 |
> > man power to do that. |
42 |
> |
43 |
> As above, package.mask would be a good intermediate solution, |
44 |
> communicating the problem to the arch users for, say, thirty days. Of |
45 |
> course it may just delay solving the problem when a new set of |
46 |
> stabilisations is due and again no one responds. |
47 |
|
48 |
I disagree in this case as the package can still be in "testing", not |
49 |
like the above case that, if the package is broken, it shouldn't be |
50 |
neither in testing tree. |
51 |
|
52 |
> |
53 |
> > I am referring to the second case that is also really common. This |
54 |
> > also raises again the question about being enough to do build tests |
55 |
> > for that arches or not. |
56 |
> |
57 |
> No, "compile only" is never enough to call something "stable". |
58 |
> |
59 |
> > If that is the case, would be nice if maintainers could have access |
60 |
> > to that machines to let us help them :) (if I would build them on |
61 |
> > that arches, I would try to help for sure) |
62 |
> |
63 |
> http://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Machines |
64 |
> |
65 |
> |
66 |
> jer |
67 |
> |
68 |
|
69 |
Thanks for the link :D, but I don't think I could do much more than |
70 |
building+running the tests of the packages while doing that in most |
71 |
cases (I am thinking in "graphical" stuff). If that would be enough, |
72 |
nice, if not... :S |