bug#81627: 30.2; [ELPA] Suggestions from my first ELPA package submission

>> Currently, `.elpaignore` is passed straight to `tar` via its `-X`
>> option, so the best place to add support for comments would be in `tar`
>> (tho it would take years before we can start using that feature).  🙁
>
> I am thinking about a more practical way: prescribe a comment prefix,
> such as ";" or "#" and filter out lines starting with that before
> passing them to tar.

Yes, we could do that.  We'd need to provide some way to escape those
things in case you want to ignore files starting with `#` or `;`, tho.
Patch welcome.

>>> 2. Document what should and should not be added to .elpaignore, maybe
>>>    with reasoning.
>>
>> What *should* be there are files that would be actively harmful.
>> These fall typically into two categories:
>> - Files which aren't needed but would, say, double the size of the
>>   tarball (typical example: snapshots or the copy of the GPL for <20kB
>>   packages).  20% size increase is negligible, OTOH, so that doesn't
>>   count as "should".
>> - Files which would cause technical problems once installed, e.g. test
>>   or maintenance files that may fail to compile on the end-user machine
>>   because they require packages that aren't in the `Package-Requires:`.
>>
>> Beyond that, it's up to the package maintainer (I recommend not adding
>> anything beyond that, simply to minimize the maintenance burden of
>> that `.elpaignore` file).
>
> I think documenting these should be useful.

I think `contributing.html` would be a good place to put it.

>>>   Also document relevant export
>>>   options. Give guidance for how to organize the content of README.org.
>> I have very little knowledge about that, so wouldn't know what to say,
> To be clear, what I have in mind when writing that is to document what
> export options are used by elpa-admin.el, such as the value of
> `elpaa--org-export-options'.

I'd rather limit how much detail we document about that, so as not to
have to update the doc every time we change the way we use those files.

IOW, I'd rather find a way to get the same end result but by documenting
more general considerations.


=== Stefan