Counting .info files

On Oct 25, 2006, at 5:23 PM, inkfree press wrote:

> Nope.
>
> I have a folder full of 4.7.x downloaded modules, and
that's what I
> searched. I have no idea what's in CVS.  I'm talking
about what  
> users get if
> they download a module: only 3 have such a file.

this is obviously wrong.  those 3 .info files (in 4.7.x) are
clearly  
a mistake, since the .info files don't mean anything to
drupal 4.7.x  
core.  a) the maintainers of those 3 modules didn't know
what they  
were doing, and b) you don't understand what you're really
looking for.

you need to (as tobias has already done) count the .info
files in the  
DRUPAL-5 or HEAD branches of the contrib repository, since
those are  
the only places where maintainers *should* add the .info
files.

make sense?

cheers,
-derek (dww)

"Derek Wright" wrote:

> b) you don't understand what you're really looking for.

Well, I think that understand perfectly what I was really
looking for:

I was looking for module directories for files with the
extension ".info".


Now, what I think you meant to use as your attempted insult
was:

    "You don't know where to look."

In that case, your rudeness respects reality.

I have not looked in CVS, nor was I attempting to do so.

~

-- 
inkfree

"Civility is free."

The implication is valid though - how would the correct
.info file be
determined for purposes of display on the project page? If
you use the
default release authors will have to update releases just to
change the
project description. Using HEAD is inaccurate if its
functionality
differs significantly from that of the default release - the
.info files
and the project page should independently be able to reflect
these
differences.

I don't see the benefit to merging these two descriptions
given that
they have different purposes.

Back to the original topic, I recommend that any project
description
revisions be conducted as informal "reviews" that
are posted to the
module's issue queue and can then be accepted, rejected, or
modified by
the maintainer. This preserves the contributors' autonomy
while
encouraging quality improvements. I do agree that the module
descriptions are often of poor quality.

Guidelines or best practices in module descriptions, via
http://drupal.org/node/77
65, would also help without forcing changes
upon maintainers.

.ck

Derek Wright wrote:
> 
> On Oct 25, 2006, at 5:23 PM, inkfree press wrote:
> 
>> Nope.
>>
>> I have a folder full of 4.7.x downloaded modules,
and that's what I
>> searched. I have no idea what's in CVS.  I'm
talking about what users
>> get if
>> they download a module: only 3 have such a file.
> 
> this is obviously wrong.  those 3 .info files (in
4.7.x) are clearly a
> mistake, since the .info files don't mean anything to
drupal 4.7.x
> core.  a) the maintainers of those 3 modules didn't
know what they were
> doing, and b) you don't understand what you're really
looking for.
> 
> you need to (as tobias has already done) count the
.info files in the
> DRUPAL-5 or HEAD branches of the contrib repository,
since those are the
> only places where maintainers *should* add the .info
files.
> 
> make sense?
> 
> cheers,
> -derek (dww)
> 
> 

> Back to the original topic, I recommend that any
project description
> revisions be conducted as informal "reviews"
that are posted to the
> module's issue queue and can then be accepted,
rejected, or modified by
> the maintainer. This preserves the contributors'
autonomy while
> encouraging quality improvements. I do agree that the
module
> descriptions are often of poor quality.

michelle and friends are *volunteering* to *improve our
site* with *more 
accurate project descriptions*. the process above is
cumbersome and almost 
guarantees that almost few descriptions get changed. less
friction please.

On Oct 25, 2006, at 7:06 PM, Moshe Weitzman wrote:

>> Back to the original topic, I recommend that any
project description
>> revisions be conducted as informal
"reviews" that are posted to the
>> module's issue queue and can then be accepted,
rejected, or  
>> modified by
>> the maintainer. This preserves the contributors'
autonomy while
>> encouraging quality improvements. I do agree that
the module
>> descriptions are often of poor quality.
>
> michelle and friends are *volunteering* to *improve our
site* with  
> *more accurate project descriptions*. the process above
is  
> cumbersome and almost guarantees that almost few
descriptions get  
> changed. less friction please.

Seconded. +1

Jonathan

On 10/25/06, Moshe Weitzman <weitzmantejasa.com> wrote:
> > Back to the original topic, I recommend that any
project description
> > revisions be conducted as informal
"reviews" that are posted to the
> > module's issue queue and can then be accepted,
rejected, or modified by
> > the maintainer. This preserves the contributors'
autonomy while
> > encouraging quality improvements. I do agree that
the module
> > descriptions are often of poor quality.
>
> michelle and friends are *volunteering* to *improve our
site* with *more
> accurate project descriptions*. the process above is
cumbersome and almost
> guarantees that almost few descriptions get changed.
less friction please.

Michelle, we may as well take this back to documentation.
Myself and
Kieran have done this over time, generally without
pre-notifying
maintainers, etc.. e.g. look at Event, which has manual
links to
dependent modules, etc. Although, looking at it, I took out
the
"recommended" link to flexinode...and replace it
to one for CCK.

If it doesn't involve issues, it's usually best to keep it
off the dev list :P

-- Boris Mann