From: lee <lee@yagibdah.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] update problems
Date: Sat, 03 Oct 2015 20:10:00 +0200 [thread overview]
Message-ID: <87lhbjombr.fsf@heimdali.yagibdah.de> (raw)
In-Reply-To: <20151001103919.71f7e640@hactar.digimed.co.uk> (Neil Bothwick's message of "Thu, 1 Oct 2015 10:39:19 +0100")
Neil Bothwick <neil@digimed.co.uk> writes:
> On Tue, 29 Sep 2015 20:45:10 +0200, lee wrote:
>
>> Neil Bothwick <neil@digimed.co.uk> writes:
>>
>> > Patches are always more welcome than suggestions. "Fix it!" is never
>> > as welcome as "here's how". I think it was Canek who said "code
>> > talks".
>>
>> Do you have an example for such a case?
>
> Just look at b.g.o. Many bug reports include a patch submitted by a user
> that makes its way into the tree.
What is b.g.o.?
>> My experience has disproved
>> this claim, and I've even seen people fixing stuff multiple times after
>> I told them it's broken and provided a perfectly working version before
>> telling them, much better coded, which they could have used instead of
>> insisting on their crappy code and trying to fix it several times.
>
> You cannot judge one group of people on the behaviour of an unrelated
> group.
But I can observe the behaviour of many similar groups of people, or of
people, and come to a conclusion about what behaviour can be
expected. That with very few exceptions, neither bug reports, nor fixes
are wanted, is an observation. I suppose I should have expected the
same behaviour here, and I made the mistake to think that I might
encounter different behaviour here.
> [...]
> #!/usr/lib/python-exec/python-exec2-c
> [...]
>
> In there you will find python2.7/emerge and python3.4/emerge (depending
> on which Python versions you have installed).
ok
>> I don't believe that they let everyone modify what they're working on,
>> so they are the only ones who /can/ fix it. Besides, show me where I
>> said something like "I want the devs to fix it".
>
> They don't. You submit the modifications in the bug report and they vet
> and apply the patches.
Obviously, no patch is wanted.
>> > Adding the word "just" to a demand does not make the task any
>> > simpler, nor does it increase your chances of getting what you want.
>>
>> Go ahead and show me where I have demanded something.
>
> Your insistence that it should be changed amounts to a demand. Your
> assertion that it can be done easily only demeans the efforts of the
> devs, implying that the fix is simple but they cannot be bothered.
I'm not insisting at all. I'm merely saying that it could easily be
fixed. So people say it's not easy to fix but incredibly difficult, and
I say that fixing a "print" statement in some script can't be so
incredibly difficult to fix. Then people agree and give other reasons
--- which have nothing to do with changing a "print" statement --- for
why this is difficult to do.
Some of what they say indicates that the devs cannot be bothered. How
you conclude that something which could be done easily and isn't demeans
anyones efforts escapes me. However, you would have to blame the people
saying that the devs cannot be bothered, not me.
>> > On the contrary, it serves to illustrate that you do not grasp the
>> > complexity of the situation.
>>
>> Perhaps you can enlighten me how it is so difficult to change a message
>> from "slot conflict" to "slot conflict (can probably be ignored while
>> there are other problems)" and what the complexity is which makes it
>> impossible to do so.
>
> Changing the message is trivial, knowing when to change it is not. Unless
> you can provide a means to tell unimportant slot conflicts from important
> ones, Context is everything and the variety of Gentoo systems out there
> make it extremely difficult for portage to understand the context in
> human terms.
You don't need to know when to change it. Once someone finds that they
still cannot update after fixing all other issues, they are able to
figure out that they may not ignore the message. Apparently it rarely
happens that they may not ignore the message.
Some time, there might be a way to know when to change the message, and
even better messages could be used. Until then, a small change would go
a long way towards making the system more friendly for the users. So
why make things difficult for everyone --- for the devs by asking for an
ultimate fix and for the users by giving them misleading messages ---
rather than making things easier by using messages less misleading while
the devs can their time until they find the ultimate fix?
I'd give them credit for taking that step. Can you explain how taking
such a step, or even suggesting to take it, could demean their efforts?
--
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
next prev parent reply other threads:[~2015-10-03 18:18 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-19 19:36 [gentoo-user] update problems lee
2015-09-19 19:57 ` Alan McKinnon
2015-09-19 22:17 ` Rich Freeman
2015-09-19 22:46 ` Alan McKinnon
2015-09-20 0:37 ` Philip Webb
2015-09-20 11:52 ` Neil Bothwick
2015-09-20 12:06 ` Rich Freeman
2015-09-22 20:11 ` [gentoo-user] " James
2015-09-26 9:47 ` [gentoo-user] " lee
2015-09-26 11:33 ` Alan McKinnon
2015-09-27 19:17 ` lee
2015-09-27 21:29 ` Alan McKinnon
2015-09-28 22:52 ` lee
2015-09-28 23:46 ` Alec Ten Harmsel
2015-09-29 18:56 ` lee
2015-09-29 0:09 ` Neil Bothwick
2015-09-29 18:45 ` lee
2015-09-29 19:36 ` Alan Mackenzie
2015-10-03 17:27 ` lee
2015-10-01 9:39 ` Neil Bothwick
2015-10-01 11:10 ` Rich Freeman
2015-10-01 13:27 ` Neil Bothwick
2015-10-03 18:10 ` lee [this message]
2015-10-03 20:01 ` allan gottlieb
2015-09-20 14:25 ` lee
2015-09-20 17:24 ` J. Roeleveld
2015-09-20 17:31 ` Rich Freeman
2015-09-26 13:51 ` lee
2015-09-26 15:09 ` Rich Freeman
2015-09-27 19:35 ` lee
2015-09-26 16:28 ` Neil Bothwick
2015-09-26 13:10 ` lee
2015-09-26 15:31 ` J. Roeleveld
2015-09-26 16:47 ` Neil Bothwick
2015-09-26 18:16 ` Alan McKinnon
2015-09-26 20:58 ` Neil Bothwick
2015-09-19 20:05 ` Neil Bothwick
2015-09-19 20:11 ` Alan McKinnon
2015-09-19 20:12 ` Mick
2015-09-20 15:28 ` lee
2015-09-20 15:57 ` Rich Freeman
2015-09-20 16:29 ` Alan McKinnon
2015-09-26 15:00 ` lee
2015-09-27 13:14 ` Alan McKinnon
2015-09-20 16:35 ` Neil Bothwick
2015-09-21 1:29 ` Paul Colquhoun
2015-09-19 21:29 ` Daniel Frey
2015-09-20 18:07 ` [gentoo-user] " James
2015-09-20 19:35 ` Daniel Frey
2015-09-20 20:59 ` Dale
2015-09-22 15:55 ` James
2015-09-22 16:03 ` Alan McKinnon
2015-09-22 16:39 ` James
2015-09-22 17:17 ` Alan McKinnon
2015-09-22 16:42 ` Neil Bothwick
2015-09-22 17:08 ` Alan McKinnon
2015-09-22 17:35 ` James
2015-09-22 18:08 ` Neil Bothwick
2015-09-22 19:05 ` Dale
2015-09-20 20:24 ` Neil Bothwick
-- strict thread matches above, loose matches on Subject: below --
2015-09-29 20:00 [gentoo-user] Major site redesign, SEO, and 301 redirects Tanstaafl
2015-09-29 20:19 ` J. Roeleveld
2015-09-29 20:39 ` Alan McKinnon
2015-09-30 0:02 ` [gentoo-user] " James
2015-10-01 11:22 ` Tanstaafl
2015-10-01 11:25 ` Alan McKinnon
2015-09-30 0:28 ` [gentoo-user] " Alan McKinnon
2015-09-30 7:36 ` Mick
2015-10-01 11:26 ` Tanstaafl
2015-10-01 11:35 ` Tanstaafl
2015-10-01 11:58 ` Alan McKinnon
2015-10-01 12:21 ` Tanstaafl
2015-10-01 14:35 ` Mick
2015-10-01 23:00 ` Walter Dnes
2015-10-02 7:41 ` Mick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lhbjombr.fsf@heimdali.yagibdah.de \
--to=lee@yagibdah.de \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox