Gentoo Archives: gentoo-devhelp

From: Michael Palimaka <kensington@g.o>
To: gentoo-devhelp@l.g.o
Subject: [gentoo-devhelp] Re: How to properly handle deps for stabilization or version bumps?
Date: Tue, 28 Apr 2015 19:34:15
Message-Id: mhoa00$a9t$1@ger.gmane.org
In Reply to: Re: [gentoo-devhelp] Re: How to properly handle deps for stabilization or version bumps? by Andrew Savchenko
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.