1 |
On 27/04/15 16:33, Andrew Savchenko wrote: |
2 |
> Hi, |
3 |
> |
4 |
> On Sat, 25 Apr 2015 03:54:19 +1000 Michael Palimaka wrote: |
5 |
>> This list is pretty quiet unfortunately. |
6 |
> |
7 |
> Let's make it louder then! |
8 |
> |
9 |
>>>> II. What to do if package stabilization requires to stabilize deps |
10 |
>>>> maintained by other devs? |
11 |
>>>> |
12 |
>>>> Should I just file a bug with stabilization request to a |
13 |
>>>> corresponding dev or team? |
14 |
>>>> |
15 |
>>>> What to do if I have no version requirements for a |
16 |
>>>> version to be stabilized? E.g. app-doc/root-docs needs |
17 |
>>>> dev-haskell/pandoc-citeproc, but it seems to work with any version |
18 |
>>>> in tree. Probably in will be the best for a relevant team to pick |
19 |
>>>> up a stabilization candidate for their convenience. |
20 |
>>>> |
21 |
>>>> Should I add arches there? Since I'm not a maintainer of a |
22 |
>>>> dependency package I'm not sure if I can do that. Package may |
23 |
>>>> require some dependencies to be stabilized as well... |
24 |
>>>> |
25 |
>>>> If I'm sure that some package (e.g. dep of my package) works fine |
26 |
>>>> and I see that it has no unstable deps or critical bugs, may I CC |
27 |
>>>> arch teams and ask for stabilization myself? Pros here are that |
28 |
>>>> this will speed up stabilization process and lower overhead for |
29 |
>>>> other devs, cons are that package maintainer may be aware of some |
30 |
>>>> issues preventing stabilization of this specific version. |
31 |
>> |
32 |
>> File a bug against whichever version looks sensible, but let the |
33 |
>> maintainer CC archs (or just ask them beforehand). |
34 |
> |
35 |
> What if maintainer doesn't respond for a long time? Usual way of |
36 |
> "ping, wait 2-4 weeks, handle yourself"? |
37 |
> |
38 |
> Best regards, |
39 |
> Andrew Savchenko |
40 |
> |
41 |
|
42 |
Yeah, that's reasonable. The waiting time before taking action in the |
43 |
event of no response can be adjusted based on the situation. For |
44 |
example, it would be reasonable to act sooner in the event of some |
45 |
package being terribly broken, but prudent to wait longer in the case of |
46 |
some important, widely-used package. |