Talk:Mailing lists

From FlightGear wiki
Revision as of 16:50, 10 May 2015 by Johan G (Talk | contribs) (Headings: Capital first letter; New section: Bug reports on mailing lists?)

Jump to: navigation, search

Template for mailing list URLs

we should set up a template for the rows in the table, so that we can easily reuse/localize everything elsewhere (as per the git/repo link templates)

  • address
  • archives
  • subscribe
  • comments
  • description (localized)
  • status

--Hooray (talk) 10:58, 20 April 2015 (EDT)

Additional info

Cquote1.png One additional thing to keep in mind is that our flightgear-commitlogs

mailing list has a maximum message size configured to 160Kb. Messages
larger than this get sent over to the list moderator. That may be why some
of these messages are delayed. I mentioned this to Torsten offline and it
sounded like he had some ideas for ensuring that extra long diffs get
trimmed to a reasonable size for a mailing list.

Cquote1.png Both the post-commit-email and

git-multimail scripts have an option for this (hooks.emailmaxlines and
multimailhook.emailMaxLines respectively). Maybe 10,000 lines would
be a good limit? The interesting part of the diff might be preceded
by a lot of 'noise', especially if multiple files are touched, so long
messages are not a bad thing. And as this is a read-only list, users
won't be attaching large binary files to their messages. So would it
be good, in addition to setting these line limits, to increase the
size limit a little? It will be hard to match line number to a KB
number, so it might save admins from having to check and accept
messages via the Mailman web interface. It could be a good long term
time saver.

Cquote1.png The default mailman option is 40kb, so we have doubled the allowable size

twice now. :-) I don't have a big emotional attachment to the current
limit, but I suspect that it's starting to get close to being big enough.
I don't think too many people are going to spend the time to review a 160Kb
diff in an email browser ... at that point there are probably better tools
for evaluating the differences. I think Torsten is planning to experiment
with limiting the message sizes as a first step. But going forward we can
certainly tune the numbers on both the sending side and the mailing list
side and move towards a more optimal balance.


Bug reports on mailing lists?

Is not that bad advice? Should not bug reports be redirected to the issue tracker in order to lessen unproductive/disruptive noise, in particular on the developer mailing list?

Johan G (Talk | contribs) 16:50, 10 May 2015 (EDT)