Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Lisi Reisz]

On Monday 10 October 2016 19:04:22 Joe wrote:
> On Mon, 10 Oct 2016 12:20:22 +0100
>
> Lisi Reisz  wrote:
> > I accepted that analogy too easily.  In this case, the wheel isn't
> > squeaking. He dislikes the colour and design of the wheel.
>
> Or perhaps it has been squeaking for so long that nobody hears it any
> more. Aptitude does a great job of routine upgrades, but if I've left
> an unstable for a month or more without upgrading, I wouldn't consider
> using it, it doesn't deal gracefully with hundreds of upgrades.

I accept that.  But I would also suggest that jacks of all trades are usually 
masters of none, and perhaps Aptitude is the wrong tool for you for that 
particular job.

Libre Office does word processing MUCH better than Kwrite.  Does this mean 
that Kwrite is a squeaky tool because it is bad at WP, or does it mean that I 
oughtn't to try to use it for that purpose?  (LO, conversely,is bad at script 
editing, for which I love Kwrite.)

Horses for courses.  If Aptitude is not the ideal tool for everything, that 
doesn't make it a squeaky wheel.  It just means that it shouldn't be used for 
everything.

Lisi

Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Joe]

On Mon, 10 Oct 2016 12:20:22 +0100
Lisi Reisz  wrote:


> 
> I accepted that analogy too easily.  In this case, the wheel isn't
> squeaking. He dislikes the colour and design of the wheel.
> 

Or perhaps it has been squeaking for so long that nobody hears it any
more. Aptitude does a great job of routine upgrades, but if I've left
an unstable for a month or more without upgrading, I wouldn't consider
using it, it doesn't deal gracefully with hundreds of upgrades.

-- 
Joe

Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Lisi Reisz]

On Monday 10 October 2016 09:07:14 Joe wrote:
> On Sun, 9 Oct 2016 21:11:07 -0400 (EDT)
>
> Bob Bernstein  wrote:
> > On Mon, 10 Oct 2016, Lisi Reisz wrote:
> > > Why not just killfile me and go on reading everyone else?
> >
> > Umm...cuz he doesn't know how to do that? Perhaps?
> >
> > One thing's fer sure, he's giving the time-honored tradition of
> > killfiles a bad name!
>
> He's right though, isn't he? The wheel which squeaks, gets the oil.
> Without complaints, things improve slowly, if at all.
>
> A formal complaint about a piece of software is the bug report, but
> much of the time, things go wrong and there is insufficient data or
> reproducibility to waste developers' time with an incomplete report.
> Just about the only thing to do then is to moan about it publicly.
>
> If it's finger trouble, you find that out very quickly. If nobody
> replies, you have something peculiar to your own system, or at least,
> not widespread. Live with it. If there's a chorus of 'yes, I've got
> that too, but I didn't like to moan', then enough collective data may
> surface to make a bug report practical, or at least to come to the
> notice of one of the developers, who may be able to shed further light.
>
> The alternatives of putting up with a problem in silence, or going
> [back] to Windows, are not optimal.
>
> As for fixing the problem yourself, you are either:
> a) a systems programmer, but you probably knew that already, or
> b) a user, who could learn enough to contribute usefully in a year or
> two, if you didn't have a living to earn.
>
> Fixing a bug so it doesn't happen again, and fixing a bug in a way that
> doesn't break *anything* else, are two very different things. I have
> enough trouble going back to my own (non-system) programming of a year
> or more ago, and finding out how it works well enough to change
> something without breaking it. It doesn't matter how many comments I
> left, I have to get back into the same mindset as when I wrote it,
> and I haven't worked out how to achieve that with comments. Details are
> easy to see, it's the overall architecture that needs to be understood
> fully.

I accepted that analogy too easily.  In this case, the wheel isn't squeaking.  
He dislikes the colour and design of the wheel.

Lisi

Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Lisi Reisz]

On Monday 10 October 2016 09:07:14 Joe wrote:
> On Sun, 9 Oct 2016 21:11:07 -0400 (EDT)
>
> Bob Bernstein  wrote:
> > On Mon, 10 Oct 2016, Lisi Reisz wrote:
> > > Why not just killfile me and go on reading everyone else?
> >
> > Umm...cuz he doesn't know how to do that? Perhaps?
> >
> > One thing's fer sure, he's giving the time-honored tradition of
> > killfiles a bad name!
>
> He's right though, isn't he? The wheel which squeaks, gets the oil.
> Without complaints, things improve slowly, if at all.
>
> A formal complaint about a piece of software is the bug report, but
> much of the time, things go wrong and there is insufficient data or
> reproducibility to waste developers' time with an incomplete report.
> Just about the only thing to do then is to moan about it publicly.
>
> If it's finger trouble, you find that out very quickly. If nobody
> replies, you have something peculiar to your own system, or at least,
> not widespread. Live with it. If there's a chorus of 'yes, I've got
> that too, but I didn't like to moan', then enough collective data may
> surface to make a bug report practical, or at least to come to the
> notice of one of the developers, who may be able to shed further light.
>
> The alternatives of putting up with a problem in silence, or going
> [back] to Windows, are not optimal.
>
> As for fixing the problem yourself, you are either:
> a) a systems programmer, but you probably knew that already, or
> b) a user, who could learn enough to contribute usefully in a year or
> two, if you didn't have a living to earn.
>
> Fixing a bug so it doesn't happen again, and fixing a bug in a way that
> doesn't break *anything* else, are two very different things. I have
> enough trouble going back to my own (non-system) programming of a year
> or more ago, and finding out how it works well enough to change
> something without breaking it. It doesn't matter how many comments I
> left, I have to get back into the same mindset as when I wrote it,
> and I haven't worked out how to achieve that with comments. Details are
> easy to see, it's the overall architecture that needs to be understood
> fully.

I quite agree with the idea that squeaks are needed.  But there is a limit to 
how OFTEN it is useful to say it in the one thread.

Lisi

Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Joe]

On Sun, 9 Oct 2016 21:11:07 -0400 (EDT)
Bob Bernstein  wrote:

> On Mon, 10 Oct 2016, Lisi Reisz wrote:
> 
> > Why not just killfile me and go on reading everyone else?  
> 
> Umm...cuz he doesn't know how to do that? Perhaps?
> 
> One thing's fer sure, he's giving the time-honored tradition of 
> killfiles a bad name!
> 

He's right though, isn't he? The wheel which squeaks, gets the oil.
Without complaints, things improve slowly, if at all.

A formal complaint about a piece of software is the bug report, but
much of the time, things go wrong and there is insufficient data or
reproducibility to waste developers' time with an incomplete report.
Just about the only thing to do then is to moan about it publicly.

If it's finger trouble, you find that out very quickly. If nobody
replies, you have something peculiar to your own system, or at least,
not widespread. Live with it. If there's a chorus of 'yes, I've got
that too, but I didn't like to moan', then enough collective data may
surface to make a bug report practical, or at least to come to the
notice of one of the developers, who may be able to shed further light.

The alternatives of putting up with a problem in silence, or going
[back] to Windows, are not optimal.

As for fixing the problem yourself, you are either:
a) a systems programmer, but you probably knew that already, or
b) a user, who could learn enough to contribute usefully in a year or
two, if you didn't have a living to earn.

Fixing a bug so it doesn't happen again, and fixing a bug in a way that
doesn't break *anything* else, are two very different things. I have
enough trouble going back to my own (non-system) programming of a year
or more ago, and finding out how it works well enough to change
something without breaking it. It doesn't matter how many comments I
left, I have to get back into the same mindset as when I wrote it,
and I haven't worked out how to achieve that with comments. Details are
easy to see, it's the overall architecture that needs to be understood
fully.

-- 
Joe

Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Bob Bernstein]

On Mon, 10 Oct 2016, Lisi Reisz wrote:


Why not just killfile me and go on reading everyone else?


Umm...cuz he doesn't know how to do that? Perhaps?

One thing's fer sure, he's giving the time-honored tradition of 
killfiles a bad name!


--
IMPORTANT: This email is intended for the use of the individual
addressee(s) named above and may contain information that is
confidential, privileged or unsuitable for overly sensitive
persons with low self-esteem, no sense of humour or irrational
metaphysical beliefs.