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

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]

Hello,

I have a couple of concerns about a proper way of handling
complicated dependencies during version bumps or stabilization.

I. With some USE flags combinations package foo depends on bar and
vice versa. While with a properly set deps (e.g. PDEPEND) this is
not a problem for users during updates; but this is a problem
during commits: repoman doesn't allow to commit multiple packages
at once, so for a short period of time deptree will be broken
during version bumps or stabilization.

E.g.:
sci-physics/root: PDEPEND on ~app-doc/root-docs
app-doc/root-docs[api] DEPEND on ~sci-physics/root

I see three possible solutions:

1) commit both packages with short window between (e.g. minute or
two);

2) ask infra to block cvs <-> rsync tree syncs for a while;

3) temporarily mask USE="api" for root-docs, commit root-docs,
commit root, unmask USE="api".

Second option looks like overkill and IMO should be used only for
large scale operations like mass eselect package moves.

Third option is formally correct, but it requires double
modification of tree-wide file where any mistake may broke the
whole tree. I think this approach brings more risks than benefits
for a simple issue described above.

Currently I use first option, since probability of broking deptree
is low and affected audience will be very limited.

Any idea how to handle this issue better?


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.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

Hi,

On Sun, 12 Apr 2015 02:20:33 +0300 Andrew Savchenko wrote:
> Hello,
> 
> I have a couple of concerns about a proper way of handling
> complicated dependencies during version bumps or stabilization.
> 
> I. With some USE flags combinations package foo depends on bar and
> vice versa. While with a properly set deps (e.g. PDEPEND) this is
> not a problem for users during updates; but this is a problem
> during commits: repoman doesn't allow to commit multiple packages
> at once, so for a short period of time deptree will be broken
> during version bumps or stabilization.
> 
> E.g.:
> sci-physics/root: PDEPEND on ~app-doc/root-docs
> app-doc/root-docs[api] DEPEND on ~sci-physics/root
> 
> I see three possible solutions:
> 
> 1) commit both packages with short window between (e.g. minute or
> two);
> 
> 2) ask infra to block cvs <-> rsync tree syncs for a while;
> 
> 3) temporarily mask USE="api" for root-docs, commit root-docs,
> commit root, unmask USE="api".
> 
> Second option looks like overkill and IMO should be used only for
> large scale operations like mass eselect package moves.
> 
> Third option is formally correct, but it requires double
> modification of tree-wide file where any mistake may broke the
> whole tree. I think this approach brings more risks than benefits
> for a simple issue described above.
> 
> Currently I use first option, since probability of broking deptree
> is low and affected audience will be very limited.
> 
> Any idea how to handle this issue better?
> 
> 
> 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.

Any comments?
Should I redirect these questions to gentoo-dev mail list?

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Michael Palimaka]

This list is pretty quiet unfortunately.

On 24/04/15 22:12, Andrew Savchenko wrote:
> Hi,
> 
> On Sun, 12 Apr 2015 02:20:33 +0300 Andrew Savchenko wrote:
>> Hello,
>>
>> I have a couple of concerns about a proper way of handling
>> complicated dependencies during version bumps or stabilization.
>>
>> I. With some USE flags combinations package foo depends on bar and
>> vice versa. While with a properly set deps (e.g. PDEPEND) this is
>> not a problem for users during updates; but this is a problem
>> during commits: repoman doesn't allow to commit multiple packages
>> at once, so for a short period of time deptree will be broken
>> during version bumps or stabilization.
>>
>> E.g.:
>> sci-physics/root: PDEPEND on ~app-doc/root-docs
>> app-doc/root-docs[api] DEPEND on ~sci-physics/root
>>
>> I see three possible solutions:
>>
>> 1) commit both packages with short window between (e.g. minute or
>> two);

This is almost always used and is usually fine - even fairly large sets
of changes such as KDE bumps run without issue. You can always time your
commits to avoid the cvs -> rsync update if you're worried.

>> 2) ask infra to block cvs <-> rsync tree syncs for a while;

This has been indeed been used rarely in the past for mass changes, such
as qt x11-libs -> dev-qt pkgmove.

>>
>> 3) temporarily mask USE="api" for root-docs, commit root-docs,
>> commit root, unmask USE="api".
>>
>> Second option looks like overkill and IMO should be used only for
>> large scale operations like mass eselect package moves.
>>
>> Third option is formally correct, but it requires double
>> modification of tree-wide file where any mistake may broke the
>> whole tree. I think this approach brings more risks than benefits
>> for a simple issue described above.
>>
>> Currently I use first option, since probability of broking deptree
>> is low and affected audience will be very limited.
>>
>> Any idea how to handle this issue better?
>>
>>
>> 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).

> Any comments?
> Should I redirect these questions to gentoo-dev mail list?
> 
> Best regards,
> Andrew Savchenko
>

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Michael Palimaka]

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.