From Usenet Big-8 Management Board

Present: RL, JE, TM

  • Administration
    • E-mail from Paul Schleck re removal of rec.radio.broadcasting rec.radio.broadcasting on Google Groups
      • Agreed to defer initiating the removal process for one year for this recently defunct group to give others in the community the opportunity to take over moderation and revitalize the group
    • E-mail from Kathy Morgan re removal of comp.software.shareware.*
      • Agreed that TM would review and initiate/continue the removal process for these long-dead groups
    • Moderation test group
      • JE proposed creating a moderation test group which could be used for testing moderation software such as STUMP. That is, the group would be moderated with the moderator e-mail address set to a spam-filtered mailing list operated by the Board. People wishing to test their moderation software setup with a peered newsgroup could (temporarily) subscribe to the mailing list and approve or reject posts, though of course they would need access to a news server that accepts posts with Approved: headers. Russ Allbery and Todd M. McComb gave the proposal a favourable reception.
      • Agreed that JE would initiate the group creation process with an RFD.
    • RL reported on his work to replace C code with Perl scripts (following issues raised by TM) and on merging contributions from Owen Rees
    • JE asked about a new (tarball) release. It was agreed that this should wait until the latest round of changes from Owen Rees was complete.
    • JE asked about packaging STUMP and WebSTUMP via OBS. TM indicated that due to the lack of per-group access control, and the system's recommendation to use separate user accounts for this purpose, packaging the software in an RPM would be tricky. RL said that Owen Rees has ideas for merging STUMP and WebSTUMP and introducing per-group access control. TM said that if/when this is implemented, we could revisit the issue of packaging via OBS.
    • JE noted that the documentation instructs users to rename directories and asked whether this could be avoided. TM indicated that this is probably a deliberate design decision to allow for in-place upgrades that don't overwrite the user's local configuration files. TM agreed to check the issue as part of preparations for the next release.
  • Misc
    • TM and JE gave apologies for next meeting
    • Agreed to cancel the remaining meetings in December