[csw-pkgsubmissions] newpkgs py_lxml

[Philip Brown]

On Tue, Mar 2, 2010 at 10:49 AM, Sebastian Kayser <skayser at opencsw.org> wrote:
> * Philip Brown <phil at bolthole.com> wrote:
>>
>>
>> Our descriptions need to have meaningful information to them.
>> That means, the name of the software, and what it does, AND some level
>> of ambiguity reduction when there are multiple similar packages.
>
> nginx vs. apache vs. lighttpd. postfix vs. sendmail vs. exim vs. qmail.
> vi vs. nano vs. emacs. perl vs. ruby vs. python vs. lua vs. php. iozone
> vs bonnie. ttcp vs. iperf vs whatever. That discussion is seriously ill
> headed and a questionable time investment for all of us (to say it
> mildly).

you are grossly exagerating. It should not take a huge amount of time,
to simply expand a one-line description, to be a little more
descriptive.
The cases above, have vast complex differences, that are not easily
described in one line.
This is not the case for the specific package we are discussing here.




> The following is a list of the short package descriptions for lxml from
> the Python Package Index, the major Linux distros, and OpenSolaris.
> Please pick one and let me know which one it should be.
>

The OpenSolaris one obviously sucks, it contains no information.
The others all mostly say,

"A Pythonic binding for the libxml2 and libxslt libraries"

All I'm asking you to do at this point, is translate "pythonic" into
something a little more comprehensible, without having someone pull up
google to figure out what "pythonic" means (if they even realize that
there is a difference between "pythonic binding", and "python
bindings", and so bother to look it up.)

This is not a "huge time investment". This is not even a medium time investment.
This is a matter of choosing to use jargon ("Pythonic") instead of
something more easily comprehensible to our users.

I'll remind you of the core principle:
"To provide a straightforward, easy-to-use experience for the user"

An important part of that, is to use straightforward, easy to
understand language, rather than masking it in jargon.

So I'll ask you to abide by that, and expand the description a little please.
If you wish to put (Pythonic) in there too, I have no objection to
that :) but please also explain, in the description itself, what that
means.