Re: Done

[Manoj Srivastava <srivasta@debian.org>]

On Thu, 11 Sep 2003 13:17:37 +0200, Marek Habersack <grendel@debian.org> said: 

> On Wed, Sep 10, 2003 at 11:40:11PM -0500, Manoj Srivastava
> scribbled:
>> On Thu, 11 Sep 2003 05:17:09 +0200, Marek Habersack
>> <grendel@debian.org> said:
>>
>> >> the user have to go on a treasuer hunt trying to determine what
>> >> a package does?
>> > Not the user, my friend. If you were calm you would have noticed
>> > that I meant that it is possible for _developers_, the _debian
>> > developers_ to find out what this or that package does and help
>> > their fellow maintainers by suggesting what the description might
>> > be. If the bugs submitted contained such hints, suggestions,
>> > propositions (and if the bug priority was something less
>> > agressive), then everything would be perfectly fine.
>>
>> If it is so very easy for other developers, whose package it is
>> not, then why is it so hard for the maintainer to provide a
>> meaningful description?

> You still refuse to accept the explanation, do you? The facts are
> that the bugs were submitted without any clues, hints nor
> suggestions. And they should have been accompanied with them. That's
> the whole point. Let me reverse what you just said: if it should be
> so very easy for a maintainer to provide a meaningful description,
> the person filling a bug report against it should provide it the
> more eagerly. And _that_ would be helpful.

	If the maintainer needs clues, hints, and suggestions to
 expand on a single line description of their package, they should
 give the package up. The project should exoect a modicum of
 competence from the developers.

	And 734 packages existing with a single line needed to be
 pointed out (well, perhaps I would not have used the same severity,
 but hey). 

>> >> better for the person who cared enough to file the bug, you do
>> >> indeed improve the package.
>> > See, this is something I don't understand in your reasoning. This
>> > is a community, right? Isn't a community a kind of a fellowship
>> > where people are supposed to help each other? Walking around and
>> > pointing fingers at other's mistakes without suggesting any
>> > solution is a waste of time, is in no way helpful. Not only
>> > intents matter, form also has its meaning.
>>
>> And the contention of a lot of people seems to be that this is a
>> trivial flaw, and we are not insulting your intelligence by
>> implying that you can't come up with a description for your own
>> package.

> It has nothing to do with intelligence. It is about willingness to
> help not just point out the weaknesses. If we all start filling such
> bugs then we will soon end up in a nice mess.

	And the maintainers just waits and has things handed to them
 on a silver platter?

>> >> So yes, as a maintainer, it is my job to stand here and listen
>> >> to people tell me how my packages can be improved.
>>
>> > Of course! But the bugs filed on the packages did NOT suggest how
>> > the packages were to be improved. That is the whole point. There
>>
>> Are you implying that there are people maintaining packages that
>> can't figure out how to come up with an long description that
>> contain enough information for new users to make their decision,
>> without having to go hunting through chains of packages to figure
>> out what a package installs?

> More or less. I'm suggesting that a maintainer may genuinely think
> his description is correct - because s/he knows the package in and
> out, because s/he is working with it daily, and because of those

	Are our maintainers really that dumb? That they can't take
 into account the fact that they know the package in and out, and that
 they need to step into the shoes of a user to craft the description?
 That even when it is pointed out that the description is inadequate,
 they are without clues, hints, and have no idea how a description
 can be expanded? And this is the class of person who has root on my
 machine? 

> things his vision might (and usually is) blurred. So, yes, if the
> maintainer doesn't know what is wrong with the description, he
> cannot correct it. And that's where people who think it's wrong

	If the maintainer does not know enough about his package to
 expand on a single line description, he should consider giving the
 package up for adoption.

> should _help_. The help is providing an explanation as to why the
> description is incorrect. Or hints, suggestions which can take a
> form of questions: "what is zlib? Why is it neccessary? Do I have to
> install it? What is python?" etc.

	Good god. And this is the person who is supposed to be the
 person who knows most about the package in Debian? Are we really so
 totally clueless about our packages?

>> > were no suggestions there, just a single statement of
>> > incorrectness. Now that you've confirmed my point of view, I hope
>> > we will agree and carry on?
>>
>> No, I don't think I agree with you.
> Apparently. Although I had a feeling we were talking about the
> same. I was wrong. And, somehow, I don't think you're ever going to
> agree on that issue.

	No. I have a minimum standard of what I expect from my fellow
 developers. 

>> >> If you think that is telling you that your work sucks, you
>> >> probably do not have the right attitude to be a maintainer.
>>
>> > Sure, sure. Whatever. Again, I have closed the bugs by correcting
>> > the descriptions - so I would assume that my attitude is
>> > correct. Unlike yours or Javier's (at the moment of filling the
>> > bugs, now he's working hard to fix his mistakes - and that's a
>> > very encouraging thing.). What would you tell if I told you that
>> > kernel-package is buggy because it clears the linux source tree
>> > after build, filed an important bug and didn't care to suggest
>> > any solution to that? You would probably close the bug and told
>> > me to buzz off.
>>
>> No. Unlike you, I actually do not tell people to buzz off, or yell
>> at people who are tryign to improve my package.

> Manoj, you're losing your piece of mind I think. Where did I tell
> anybody to buzz off? Haven't I closed all the Javier's bugs by
> _fixing_ them? Is that telling him to 'buzz off'? Where did I
> address Javier directly? Where have I "yelled" at him? In fact, look
> several lines above, in the parentheses. Does that account as
> "yelling"? Again, why don't you just calm down?

	Some people did close the bugs with exactly the words "Buzz
 Off, pest". I know, I reopened that bug.

>> IU would, insted, point you to the manual page, and the
>> documentation about the option for turning that feature off. And
>> invite you to present your argument for changing the default,
>> keeping in mind that there is an installed base for kernel-package,
>> and people may have come to expect the old behaviour (I certainly
>> have).

> And if you received 18 such bugs filed automatically? See, do yo
> know why I haven't filed such bug? Because I have taken the time to
> read the manpages and find the answer - which, according to your
> suggestions, I'd have a right not to do as a user (as I don't think
> a regular user would have discovered kernel-img.conf(5) easily.)

	How does it matter how many bugs I receive? Theya re all
 potential possibilities to improve my package. Are you sure you
 really enjoy being a maintainer? 

>> > Or that make is crap because it segfaulted for me?  Wouldn't you
>> > consider that rude, inadequate and less than helpful?
>>
>> I would ask for more information, certainly. I would ask for ways
>> to reproduce the failure, core dumps, etc
>>
>> These questions are certainly informative, though -- apparently the
>> standards of behaviour for debian developers have decayed since my
>> day.

> Apparently. Well, not everybody can live to your high standards.

>> >>
>> >> Ok, here is one at random.
>> >>
>> >> Package: pike7.2-gz Description: Gz module for Pike
>> >>
>> >>
>> >> What on goddesses good earth is a Gz module? Even though the
>> >> report was about the long description, this short description
>> >> does not meet, in my opiunion, the minimum satandards of a
>> >> package description.  What is pike?
>>
>> > Description: Gz module for Pike
>> >  This Pike module provides access to the zlib compression
>> >  functions. The compression algorithm implemented in zlib is used
>> >  by the gzip program (among others).  .  Pike is an interpreted,
>> >  object-oriented, dynamic programming language with a syntax
>> >  similar to C. It includes many powerful data types and a module
>> >  system that, for instance, provides image manipulation, database
>> >  connectivity and advanced cryptography.
>>
>> > This is the description of the module. Isn't it sufficient? And I
>> > had the impression we were discussing the long descriptions,
>> > weren't we?
>>
>> I think you are mistaken. Here is the output from apt-cache working
>> off Sid.
> Am I?:

>>
>> If you have changed in long description in response to the Bug,
>> then good for you: it also means the bug reports were required.
> For god's sake, Manoj! I have repeated several times that they
> _were_ required. But the _way_ they were done was less than helpful.

>>
>> >> compression facilities are present in pike natively? Do I
>> >> nabsolutely need this module to compress stuff in pike?
>>
>> > A Pike extension module is native to Pike, per se. And since it
>> > is provided here, it is also clear and implied that it is not
>> > present in the core. I assume the users interested in programming
>> > will be able to deduce that.
>>
>> Not necesarily. There could be other, native, compression libraries
>> shipped with pike for all I know, and the zlib functions are extra.
>> How am I to deduce that there is no core compression library?

> You are going a bit to far in nit picking. Rest assurred that if
> there was such a situation, I would have informed people that the
> module is an alternative. Besides, reading the apt-cache show output
> above you should notice tha the source is pike7.2 - which alone
> suggests the module comes from the core package.

	How would I know? When the bugs were filed, there were 18
 packages from you with inadequate descriptions. How would I know to
 what extent the laziness extended?

>> >> Not when I am in the middle of a initial install, and the
>> >> machine is not yet up, and I am trying to decide between 10000
>> >> packages. If every single package made me do one extra lookup,
>> >> you have done a lot to blow the quality of the install for me.
>>
>> > So what is the solution to that weakness? To consolidate the
>> > packages into a single monolithic one? If your answer is 'give a
>> > good description' then I have done it - please read the
>> > descriptions of all my packages and feel free to file a bug if
>> > you find something unclear in them (with the suggestion on what
>> > is wrong in your opinion, of course).
>>
>> I did.
> Perhaps, but your suggestions were based on old descriptions (which
> I have fixed after Javier's bug report but before your rant here.)

	The descriptions were based  on the state of the archive when
 the bugs were filed.

>> Or are you trying to state you have recently fixed the long

> I'm not trying to state it, I have stated it several times
> already. But with your vision blurred with anger or whatever other
> nice feeling you have conveniently missed the facts. Maybe a short
> summary:

> 1. I do think reports of the kind like Javier's are necessary

	I think they are. They made you improve 18 packages to what
 are now good descriptions. You had never done anything to fix them
 until those bugs were reported. 

> 2. I think Javier's original bug reports were less than helpful as
>    they did nothing to suggest the improvements.

	If maintainers need more clues about their own packages, they
 ought not to be maintaining them

> 3. I have fixed the bugs despite #2 above.

	Good. Wonderful. I applaud your work ethic.

> 4. I think developers filling such bugs should do a bit more than
>    grep the descriptions and post a boilerplate report to all
>    packages "affected". If somebody is taking upon him the
>    responsibility of filling 'important' bugs they should be ready
>    to help and answer all the questions. More, they should step
>    forward with suggestions _before_ any possible questions from the
>    maintainer(s)

	So, people point out flaws in your package (which you fix,
 thanks), and you are yelling at them for not doing more work, and
 handing you a solution on a silver platter?

>> Pissed? perhaps. Descend immediately into unprofessional conduct?
>> no. I'd run a spellcheck, fix the errors, and ask id I had fixed
>> them all.
> What is 'unprofessional conduct'? Is fixing the bugs and _then_
> saying that I didn't like the way they were done is unprofessional?
> What is professional then? Fixing them and shutting up?

	Screaming and ranting at the person who points out the flaws
 is not very professional conduct.

>> It is my baby, after all. My package. My reputation, for what it is
>> worth.

> High words.

	Point out a case where I do not live by them.

> Well, in my (crippled and lowly) opinion I have done
> everything I should have regarding my packages. All the bugs filed
> by Javier are fixed by uploading corrected versions of

	Good to know.

> packages. And, if you cared to check when the fixes were uploaded,
> the first batch was the same day I received the bug reports, the
> next batch the day after. And the posts here came another day after
> that.

	This was never about whether you fixed your packages after
 javi pointed the mistakes out, this was abnout you trying to give him
 grief when it was your packages that were at fault in the first
 place.

	manoj
-- 
I'm pretending I'm pulling in a TROUT!  Am I doing it correctly??
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C