[MIR] mailman3 to replace mailman, or drop mailman to universe and off server iso

[Dimitri John Ledkov]

mailman is python2, mailman3 is python3, but also it has new dependency stack.

Do we want src:mailman3 in main? bin:mailman3 pulls in above listed dependencies (*)
(*) and lynx, but dropped to suggests

Do we want bin:mailman3 or bin:mailman3-full in main? (the latter pulls in src:mailman-suite as well)

src:mailman-suite has potentially more things - django, hyperkitty, ruby-sass, uwsgi...

MIRs needed for all of the above listed.

Before proceeding further with assignment/doing technical work in driving above MIRs, a product level yes/no answers should probably be answered for above two questions.

[Dimitri John Ledkov (xnox)]

@powersj @dpb1 - ping? i thought there was consensus the other day...

[Dimitri John Ledkov (xnox)]

mailman-suite / mailman3-web should change packaging to launch as python3, not python2 webapp.

[Joshua Powers (powersj)]

There is consensus to do this, we need the work broken down to determine if we can get it all done next cycle or over 2 cycles.

[Dimitri John Ledkov (xnox)]

@powersj I think the biggest blocker would be security reviews of all of these things.

[Joshua Powers (powersj)]

Assigning to Christian for investigation

[Christian Ehrhardt  (paelzer)]

Time to get it started, I assume this will accompany us for a while at least, but we have to start at some point.

Thanks xnox for the initial list of affected packages, but I assume it is much worse.
I agree that mass-MIR handling is probably the biggest step to take here.

[Christian Ehrhardt  (paelzer)]

I wanted to eventually file MIRs for all of these and reference the bugs here.
I wondered to drive all in this MIR, but that will break discussions as e.g. python-flufl and zope are so damn different that doing that in just this bug will make us loose track too much.
OTOH now that I did the deep check on dependencies, I'm afraid this just is too much either way.

I began with re-tracing those dependencies to be sure they are still valid.
It was time to tune my dependency check helper anyway and my fear of "more than we thought" was confirmed depending on what we select.

If you'd just (and only) look at the mailman3 binary from the mailman3 source, then the current dependency list is almost correct, just zope.i18nmessageid needs to be added which is a second level dependency.

But I think users would actually expect mailman3-full being the main package we'd want.
Read the description of mailman3:

 Description: Mailing list management system
  This is GNU Mailman version 3, a mailing list management system. This package
  provides the core delivery engine of the system, which handles the mailing
  lists data, receives messages, handles the moderation and processing of these
  messages and delivers them to the mailing lists subscribers. It communicates
  with the other components through a private administrative REST API.
  .
  Default database backend is SQLite3 in order to not break automated
  installations. For productive setups, PostgreSQL or MySQL are much better
  options though. See README.Debian for further information.
  .
  In order to get the full Mailman3 system, the metapackage 'mailman3-full'
  should be installed.

But using mailman3-full pulls in way too many dependencies by mailman3-web and python3-mailman-hyperkitty. Then we would explode from 15 to 49 dependencies including very non-server'ish ones like fonts and way more zope.

But as I said coming from mailman (2) you'd expect just that - as formerly the web integration and all of it was part of mailman (2).

We'd also want the lazr related packages be owned by foundations I guess who own the rest of lazr already.

I'll attach the full list of dependencies, so everyone interested can read into it.
My recommendation would be to declare only the core mailman3 for main inclusion, not mailman3-full.
I'll bring it up for team discussion later today.

[Christian Ehrhardt  (paelzer)]

Summary (mostly as a working theory for now):
Seeding/Unseeding:
- we would only select and fully support the core mailman3 (to keep things reviewable and supportable)
- all the web bits pulled in by mailman3-full via mailman3-web and hyperkitty would not get into main
- once migrated mailman2 would be demoted (another nail in the python2 coffin)
Ownership:
- flufl*, lazr.*, python-*, nose as listed are generic python libraries which I'd ask foundations to own
- zope.* as listed would be on Server Team
- mailman3 itself would be on Server Team

next: I will talk to various people to get some acks on that approach

[Christian Ehrhardt  (paelzer)]

To help the discussions to come I isolated the dependencies of mailman3-web
mailman-hyperkitty is very similar.

[Christian Ehrhardt  (paelzer)]

Discussed in the Team, and the conclusion is that we have to go the big route of mailman3-full
Maybe breaking out hyperkitty to a suggests, but that is not helping too much.

I'll update the bug tasks tomorrow and prep a summarized Dependency list of the planned approach. I will then send a few mails about taking over ownership (as mentioned not all we need is server'ish).

Once those are acknowledged we can start to do the mass filing of per package MIR requests.

[Christian Ehrhardt  (paelzer)]

Existing option left, let mailman[23] go - not my decision thou - might bring it up on the sprint thou.