Differences between revisions 2 and 4 (spanning 2 versions)
Revision 2 as of 2017-08-20 08:04:59
Size: 5502
Editor: ?LarsKruse
Comment: formatting
Revision 4 as of 2017-08-20 09:09:23
Size: 3406
Editor: ?LarsKruse
Comment: clarify title
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Mailinglists for collaborative maintenance = = Mailinglists for collaborative package maintenance =
Line 48: Line 48:
 * prepare a howto (targetting current list-owners on alioth) for requesting a new mailinglist on lists.d.o and how to import the original mailinglist  * (./) prepare a howto (targetting current list-owners on alioth) for requesting a new mailinglist on lists.d.o and how to import the original mailinglist
Line 50: Line 50:
 * prepare a description (targetting users of the new development platform) for requesting a mailinglist on lists.d.o  * (./) prepare a description (targetting users of the new development platform) for requesting a mailinglist on lists.d.o
Line 54: Line 54:


= Howto proposals =
== Migrate mailinglists from alioth ==
Recipients of the following text:
* alioth accounts with project admin rights
* mailing lists owners (yes, they might be different and the latter not aware of alioth at all)


The lists eligible for migration must follow the requirements outlined on the "How to ask a mailing list" guide (https://www.debian.org/MailingLists/HOWTO_start_list). The process is also the same as outlined on the guide.

That is to say, the list is expected to be useful, to have a purpose and an audience.
A public discussion or support list is probably OK, but commits or bug notifications should use the dedicated features of gitlab instead, and if you're interested in a package's bug, you're expected to subscribe to it using the BTS features.

Short version: file a bug on the pseudo-package lists.debian.org with the severity 'wishlist', with the following information:
 * List Name
 * Rationale (why do you need this list, stating that you had one on Alioth is not enough!)
 * Short Description (for display in list indices)
 * Long Description (targeted to people that need to decide if they want to join)
 * Category

Lists migrated from Alioth are expected to be open, that is:
 * Open Subscription Policy (no closed lists)
 * Open Post Policy (anybody can post)
 * Open Archive

If you do want the archive and/or the subscribers to be imported into your new mailing list, please:
 * on alioth, using your ssh access, run 'sudo /usr/local/bin/export-list <mailing_list_name>' to get gzipped tar archive (on stdout) containing:
  * mbox file of the archive
  * subscribers list in simple text file
 * import the resulting mbox file in your favorite e-mail reader and clean the spam,
 * send the compressed archive and/or the list of subscribers along with your request.
 
Also, please understand that the requirements and features for lists on lists.debian.org are not the same as for a mailing list on Alioth, and the listmaster might reject your request. Lists.debian.org cannot replace all mailing lists and aliases on Alioth.

Mailinglists for collaborative package maintenance

The following thoughts were exchanged during the Alioth Sprint 2017.

Discussion summary

  • the most recent user survey showed wide interest for the mailinglists feature

  • currently there are 1384 lists on alioth
    • the most widely used list types:
      • 500 commits
      • 383 devel
      • 220 maintainers
      • 40 discuss
      • 35 users
      • 19 announce
      • 15 general
      • 10 bugs
    • the above list was compiled via:

      list_lists | sed 1d | awk '{print $1}' | tr '[A-Z]' '[a-z]' | grep -- - | sed 's/^.*-//' \
          | sed 's/^user$/users/; s/^commit$/commits/; s/^dev$/devel/; s/^maint$/maintainers/; s/^changes$/commits/; s/^team$/maintainers/; s/^maintainer$/maintainers/; s/^vcs$/commits/; s/^cvs$/commits/; s/^cvslog/commits/; s/^scm$/commits/; s/^developers$/devel/; s/^pkgs$/packages/; s/^group$/maintainers/' \
          | sort | uniq -c | sort -n
    • the "commmits" list functionality is superseded by the notification feature of the new development platform
    • "bugs" lists are superseded by the issue tracker
    • the list types "devel", "maintainers", "discuss", "users", "announce" and "general" are probably acceptable for being hosted on lists.d.o service
  • we also contemplated to host a mailing list service that would be integrated in to the new development platform, but there were some objections:
    • mail-based services are a heavy maintenance burden (spam, IP blacklists, ...)
    • there is already a lists.d.o mailing list service within Debian, which would probably suffice for most of the above use cases (based on a quick assessment of the lists.d.o requisites for new mailinglists)

Possible manual migration of Alioth mailing lists to lists.d.o

Listmasters are willing to have some more lists on lists.debian.org, but not all that are currently on alioth.

Lists may be granted on request based on the following requirements:

  • team discussion list would be OK
  • support lists maybe as well (ask for it)
  • commit lists are not OK (use the notification system) (1/3 of current lists)
  • aliases for maintainers are not OK (subscribe on tracker.d.o instead)
  • getting a new mailinglist: file a wishlist bug against lists.debian.org (https://www.debian.org/MailingLists/HOWTO_start_list.en.html)

New lists will have common list settings - open list, free subscription, open archives.

Every list owner needs to request a list manually. There will be no automatic migration.

We prepared a minimal export script for retrieving the mailing list archive and the subscriber list from alioth. These can be imported by the listmasters.

Migration tasks

  • (./) prepare a howto (targetting current list-owners on alioth) for requesting a new mailinglist on lists.d.o and how to import the original mailinglist

  • discuss the above draft with list-master
  • (./) prepare a description (targetting users of the new development platform) for requesting a mailinglist on lists.d.o

  • bonus: embed/link this description in the new development platform
    • this could help to prevent requests "where the mailing list feature went"
    • encourage collaborative packaging teams to establish a communication channel