[gentoo-devhelp] Re: How to properly handle deps for stabilization or version bumps?

[Michael Palimaka <kensington@gentoo.org>]

On 27/04/15 16:33, Andrew Savchenko wrote:
> Hi,
> 
> On Sat, 25 Apr 2015 03:54:19 +1000 Michael Palimaka wrote:
>> This list is pretty quiet unfortunately.
> 
> Let's make it louder then!
> 
>>>> II. What to do if package stabilization requires to stabilize deps
>>>> maintained by other devs?
>>>>
>>>> Should I just file a bug with stabilization request to a
>>>> corresponding dev or team?
>>>>
>>>> What to do if I have no version requirements for a
>>>> version to be stabilized? E.g. app-doc/root-docs needs
>>>> dev-haskell/pandoc-citeproc, but it seems to work with any version
>>>> in tree. Probably in will be the best for a relevant team to pick
>>>> up a stabilization candidate for their convenience.
>>>>
>>>> Should I add arches there? Since I'm not a maintainer of a
>>>> dependency package I'm not sure if I can do that. Package may
>>>> require some dependencies to be stabilized as well...
>>>>
>>>> If I'm sure that some package (e.g. dep of my package) works fine
>>>> and I see that it has no unstable deps or critical bugs, may I CC
>>>> arch teams and ask for stabilization myself? Pros here are that
>>>> this will speed up stabilization process and lower overhead for
>>>> other devs, cons are that package maintainer may be aware of some
>>>> issues preventing stabilization of this specific version.
>>
>> File a bug against whichever version looks sensible, but let the
>> maintainer CC archs (or just ask them beforehand).
> 
> What if maintainer doesn't respond for a long time? Usual way of
> "ping, wait 2-4 weeks, handle yourself"?
> 
> Best regards,
> Andrew Savchenko
> 

Yeah, that's reasonable. The waiting time before taking action in the
event of no response can be adjusted based on the situation. For
example, it would be reasonable to act sooner in the event of some
package being terribly broken, but prudent to wait longer in the case of
some important, widely-used package.