Re: gnu.emacs.sources: Only sources and patches, please

[Tim X <timx@nospam.dev.null>]

Michael Olson <mwolson@member.fsf.org> writes:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> Hi,
>>
>> please let's move _discussions_ about packages posted to
>> gnu-emacs-sources/gnu.emacs.sources to help-gnu-emacs/gnu.emacs.help
>>
>> gnu-emacs-sources is intended only for code and patches...
>
> I don't like this convention.  The name "gnu.emacs.help" does not
> particularly suggest to me that discussion for posts to
> gnu.emacs.sources should be followed up there -- that is, I have no
> certainty that program authors who post to .sources are also
> subscribed to .help, and little hope that they can find replies to
> their code submissions in .help, due to the relatively high volume of
> that group.
>
> Also, even if I am totally mistaken about my other assertions, I think
> if replies to posts in .sources include new/revised source code, it is
> disingenuous to tell people to send them to a different list.
>
> If we must insist on different destinations for source and comments,
> how about a separate, low-volume list (measured relative to
> gnu.emacs.help) called gnu.emacs.sources.discuss?
>
> -- 

My understanding is that this group/list is for sources rather than discussion.
However, I think patches are probably OK, though its probably better to send
them directly to the author to prevent multiple patches for similar
bugs/features and leave it to the author to apply.

What I think definitely needs to be avoided is long threads debating particular
issues relating to a package, especially if that discussion moves away from
specific code issues to more philosophical ones. Part of the reason I have this
perspective is that a number of places I know of archive the contents of this
list and it can be a handy resource to find code. If it ends up with lots of
discussion posts and the ratio of code to posts drops, it would lose part of
this stremgth. 

I don't think another list is a good idea. Discussion of package/code issues
could be done in g.e.h and in fact would possibly be a benefit there. Another
list would just dilute things further.

Of course, just my 2 cents worth. If the general consensus is different, I have
no problem with following that.

Tim


-- 
tcross (at) rapttech dot com dot au