Re: ELPA commit freeze

[Dmitry Gutov <dgutov@yandex.ru>]

On 22.08.2013 23:35, Stefan Monnier wrote:
>>> Why couldn't that be fixed?  Why should usage info not be in README.md?
>> Because it's customary to put at least something into Commentary, usage info
>> seems to be the most natural info to put there, and duplicating text is not
>> nice. See my previous emails for better arguments.
>
> OK.  let's try to take a step back.  You're suggesting that we need
> 2 places where we put different info (one being the Commentary: and
> another being the README.*).

That's what often happens already anyway.

> I just don't see it.  If you want to put info in the README, then you
> can put all the relevant info in the README, and the Commentary: can
> be trivial.  And vice versa.

Yes, nothing's stopping us from arranging the information in any 
arbitrary way. Except for social factors.

To have the description recognized by both Elpa and Melpa, currently I'd 
have to keep the same text in README.md and Commentary. And 
`describe-package' buffer from Melpa would end up looking better due to 
not having extraneous info.

To switch Melpa over to preferring text from README.md over Commentary, 
you'd have to make an argument that it would result in better, more 
relevant descriptions for packages that they distribute, overall.

And they are tracking ~300 multi-file and ~2700 single-file packages, so 
it's not like we can easily change a significant portion of them over to 
a different convention.

>>>> Take company's README.md, for example.  It's barren, but Commentary in
>>>> company.el contains what you'd expect from a description.  I'd like to keep
>>>> things that way there.
>
> Why?  Why not move the info from company.el to README.md (where it can
> be made prettier while you're at it)?

It already has a homepage that has all that info. It's prettier than the 
github page due to having some dedicated styling.

Putting the same stuff on the homepage and in README.md would, again, 
result in duplication, or at least some non-trivial work by automating 
the export from the latter into the former. It's doable, but the link 
works just as good.