gnu.emacs.sources: Only sources and patches, please (was: linum.el -- Display line numbers to the left of buffers)

gnu.emacs.sources: Only sources and patches, please (was: linum.el -- Display line numbers to the left of buffers)

[Reiner Steib]

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...

| List-Id: GNU Emacs source code postings and patches <gnu-emacs-sources.gnu.org>

I'd suggest to add...
| Followup-To: gnu.emacs.help
and/or
| Mail-Followup-To: help-gnu-emacs@gnu.org
headers (and a note in the body[1]), ideally in the original source
posting or at least when following up.

It's easy to miss sources if they are buried deep in a discussion like 
Markus' updated version (in article <87ps6ytc80.fsf@gmx.at>).

Bye, Reiner.

[1] The fact that the lists/newsgroups are gated makes it harder to
    do this only on a technical basis.

Crosspost & Followup-To: gnu.emacs.help
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Michael Olson]

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?

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

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

[Tim X]

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