On Sun, 27 Jul 2014 05:30:26 +1000 Michael Palimaka <kensing...@gentoo.org> wrote:
> On 07/27/2014 05:21 AM, Tom Wijsman wrote: > > On Sun, 27 Jul 2014 03:12:07 +1000 > > Michael Palimaka <kensing...@gentoo.org> wrote: > > > >> On 07/26/2014 07:59 AM, Tom Wijsman wrote: > >>> On Wed, 23 Jul 2014 22:14:41 +1000 > >>> Michael Palimaka <kensing...@gentoo.org> wrote: > >>> > >>>> Shouldn't we strive to avoid the unnecessary rebuilds in the > >>>> first place? Doing updates on your schedule only avoids the > >>>> symptom, not the problem. > >>> > >>> We should strive to do both; cause less rebuilds, update less > >>> often. > >>> > >>> It is comparable to flooding on IRC channels; if you send much > >>> more messages, you are much more likely to experience a kick > >>> and/or a ban. > >>> > >>> It is easier not to flood than to convince people there is no > >>> problem with you flooding the channel; out of all the IRC channels > >>> I know of, I've only come across one where they don't mind pasted > >>> long code blocks but that's mostly because of the lack of active > >>> moderation and people. > >>> > >>> (With "flooding" as "updating" and "kick/ban" as "rebuilds") > >>> > >> Each person should update at a frequency that suits them. > >> Recommending to update every $period is not a valid solution to > >> unnecessary rebuilds. > > > > The more one floods, the more one accepts kicks and/or bans; > > expected. > > > > How about just not causing the problem in the first place? :-) That's the ideal, no revision bumps needed at all; though, the lack of resources doesn't make that possible. Attempts to do it stall the introduction of the ebuild; so, that's why we release and revbump it. This story goes further upstream; if they would list deps right, we wouldn't need to revbump. So; if we want to fix the cause, we would need to fix it upstream although they experience a lack of resources. TL;DR: With the water tap wide open, we'll keep mopping. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
