[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Done



On Thu, 11 Sep 2003 18:36:51 +0200, Marek Habersack <grendel@debian.org> said: 

> On Thu, Sep 11, 2003 at 10:39:18AM -0500, Manoj Srivastava
> scribbled: [snip]
>> > 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.

> You're really seem to fail to understand. Since you're adressing me,
> I will answer. I am a co-founder of the Caudium project
> (caudium.net), have been an upstream for Pike until recently (still
> working with it but not "oficially") for the past 3 years. So, I
> think I would make a competent maintainer of the packages, don't you
> think? Why are you being so dense and refuse to note the real

	No. Not if you think you need clues and hints to help create a
 description for the package. A maintainer is not a developer; and
 nothing you have said above indicates  anything to the contrary. 

> problem discussed instead of its meaningless parts? Let me repeat it
> once again and maybe you will understand this time: the problem is
> that sometimes the developers might not even KNOW their description
> is unclear to somebody else, because they are too close with the
> package and it simply doesn't occur to them that it might be
> unclear. And until this is pointed out and explained why and what is
> unclear in the description, they won't know how to fix it - since
> they won't know what others don't understand.  Is that clear to you
> now?

	Wehn told to expand on the one line description, if they are
 "too close" to be able to create that description , then they are
 "too close" to be a good maintainer.  Lacking the imagination
 required to put yourslef into the users shoes is not a fatal flaw;
 expecting people to hand  you descriptions is. The maintainer could
 ask, perhaps on -user. And no one asked for a perfect desciption --
 just an expanded one. 


>> 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).

> Yes, they needed to be pointed out their shortcomings. That's
> cooperation, my friend. Have you still failed to notice what Javier
> is doing now? He is going over the list and suggesting what might be
> wrong. Are you going to still persist at your opinion?

	Cooperation is not demanding that bug submitters do your job
 for you. 

>> >> >> So yes, as a maintain
>> Are our maintainers really that dumb? That they can't take

> What the hell does it have to do with being dumb for christ's sake?

	Inability to expand on a one line description of your own
 package does seem to be a working definition of dumbness.

>> 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?

> OK, I will try to explain it as to a child. People don't always know
> what others think/know/understand/don't understand. The process of
> learning about those things is called a "communication". One person
> explains to another person what s/he doesn't understand. Then the
> person asked to clarify the problem explains it to the asking
> party. This usually observed in schools, on universities and other
> educational facitilities. But can and should be applied in
> communities, teams which work together on some product.

	And you need all this to expand from a one line description to
 something more sustantive?

> [snip]
>> > 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?
> I don't enjoy conversating with somebody as dense as you. And yes, I
> enjoy being a developer. How many bugs do you see open in my
> packages? I wrote it somewhere to you already, but let me repeat -
> it's not the bug reports themselves that are the problem, but their
> quality.

	*I* am dense? And yet, I am notr asking people who tell me to
 expand on a one line description of my package for clues, help,
 suggestions.

> [snip]
>> >> 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?

> Beg you pardon? Are you bold enough as to accuse me of being lazy?

	Yes.

> How do you know there were 18 inadequate descriptions if you butted
> in to one of them that was already corrected at the time you picked
> it up? How many useful comments have you provided? How many

	You corrected it once bugs were filed, and then whined about
 the iniquities of having to create them on your own, with no clues,
 help, and suggestions in the bug report itself.

	What do _you_ ascribe all that whining to?

> suggestions have you given? How many times you said something that
> wasn't a rant? Where are your high standards?

	I have given suggestion to people who were policte, and whose
 packages I knew well enough to do so. Note that I am not complaining
 about work required on _my_ packages.

> [snip]
>> >> > 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.

> Bullshit. Pike was updated in the archive in the yesterday's
> round. You posted after that.

	But the descriptions were based on the state of the archive
 when the bugs were filed. Can't you read? 


>> >> 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.

> How can you tell that? You have never read those 18 descriptions so
> you have no comparison.

	Are you telling me that you did not chjange those descriptions
 after the bugs were filed?

>>
>> > 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

> OK, wanna show me how to maintain Pike and Caudium? I will give them
> to you and learn.

	The least you can do is follow propoer procedure: send mail to
 wnpp and orphan the packages as developers normally do.

>> > 3. I have fixed the bugs despite #2 above.
>>
>> Good. Wonderful. I applaud your work ethic.
> Great, I'm honored.

>> > 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?
> I asked you before and you conveniently ignored the question - where
> have I yelled at Javier? Show me.

>> >> 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.
> Where have I screamed and ranted at Javier?

>> >> 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.
> Nope, unlike you I don't find it amusing. It's not me who boasts
> about high standards, I don't have to prove you're wrong, you should
> prove you're living up to your standards. It's you who is
> questioning my standards, ethics, professionalism, accuse me of
> being lazy etc. etc. - I have said naught of it about you until this
> mail.

>> > 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.
> I've said that a few mails before. You ignored it in your anger.

>> > 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.

> Note that I'm arguing with you not with Javier. Are you his
> advocate? It's you who is yelling, shouting and acting like a
> lunatic. I haven't seen anything like that from Javier. He is
> working hard on fixing his mistakes, instead. Unlike you.

	_I_ am acting like a lunatic, when it is not I complaining
 about bug reports that point problems in my packages? And Javier can
 bend over backwards all he wants to help developers unable to expand
 the one line descriptions of their packages; I expect better from the
 developers ion the first place.

	manoj

-- 
Neurotics build castles in the sky, Psychotics live in them, And
psychiatrists collect the rent.
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



Reply to: