Am 14.03.26 um 16:51 schrieb Danil Smirnov via Mailman-Developers:

Hi Matthias,

On Sat, Mar 14, 2026 at 2:52 PM Matthias Andree via Mailman-Developers < mailman-developers@python.org> wrote:

...

Are you sponsoring the completion of what the student project has left behind half-done? The projects have cost (effort) with design reviews, advice, communication, but evidently these student's projects did not complete to integration (time/quality), and nobody/nothing stepped up to take them behind the goal line outside GSoC.

I'm not sponsoring them since I believe Google handles that, but overall, I have no issue with sponsoring them to completion - both financially and man/hours-wise. No one ever asked me to do that before.

I was just wondering if these GSoC features that started to get implemented, but not completed, are so dear to you that you would invest something yourself.

...

So _how_ do you, Danil, propose, concretely, to organize the required items (resources, expertise, acceptance) to get those half-finished items completed and integrated?

As a bare minimum, we can have a list of half-done projects somewhere, since after I did an extensive manual search, I didn't find any information on them! The only place where I learn about them is this mailing list, and they are like moths: they appear for a second only to disappear forever.

Seems there is an initiative...

...

Else the GSoC graveyard as you call it is the dignified version of the scrapyard where so many other GSoC efforts landed. And maybe it's fine if it's something new and a prototype that everyone can learn from - scrap it, and then redesign, and do it right -- after you've learned from the prototype. Research is also about finding out what does not work.

This absolutely makes sense. Perhaps I should consider GSoC as a CS students' educational initiative only, rather than an effort to improve Mailman. My view on GSoC might be wrong. But the list of ideas does not sound like educational tasks at all. They sound like the most important and most wanted features, so I'm jealous that they keep disappearing into a void every year.

But that would also raise questions as to the importance. If it's important to someone, they should not delegate, especially not to an entity they don't have experience with, but make it one's own priority, should they not?

...

GSoC does not have a success warranty implied, no project has, it takes diligent work - and GSoC is deadline-constrained with a bit of regard for quality (midterm review, per 2026 rules) and the overall cost is charged to the "organization" and the mentor.

But what is your view on the expected success rate? 1 of 5? 1 of 10? Should we expect projects to be merged into the codebase at all? Based on historical data, the answer might be "no" (I haven't found any projects merged into Mailman after GSoC in the last five years).

I haven't done a proper study, I only have a one-item sample that's weak even as anecdotal evidence. There was also a fetchmail project (I am its only maintainer these days) in 2008 to get openconnect-1 based MAPI support in. It didn't land. Even though it had another person the year after and I poked at it in later years, ultimately it was put to rest on BRANCH_MAPI_OLD and later attempts on BRANCH_MAPI without ever being integrated. I couldn't get it to work, I wasn't given test accounts to play against, and that was the end of the story. (It was also a fraught with a split responsibility - the contribution was under the openconnect umbrella which had nothing to do with fetchmail to that point, and they didn't consult or look to align with fetchmail.)

There seems to be a mid-term review in GSoC these days, if there was one in 2008, I wasn't invited nor informed. And six weeks during summer can be tight to arrange for integration if those arrangements hadn't been part of the exposé/proposal/application.

The thing is, an external contribution that's not on the priority list of the maintainer(s) is not done until the contributor has shown that and how it works and the maintainer/s of the project the contributor strives to integrate into has seen it work themselves. No demo (which needs to include integration), no go.

I don't want to preempt or anticipate how each project (including mailman) will work, but that seems to be obvious to me for outside contributions that are not on the maintainer's priority list. And I might suggest that if you're contributing something that requires a certain expertise to maintain and keep working, your contributed feature might be removed later if it gets in the way of the maintainers and they don't want to take a deep dive. Not sure if any of this applies to the mailman3 contributions.

...

GSoC doesn't cover the second phase though, so integration of GSoC-made material seems like a game of luck. Hm, I didn't know that. If the current Mailman maintainers are too busy to make this happen, I'd be happy to participate and ensure that valuable contributions reach the Mailman codebase! Especially those the most wanted by the community.

GSoC 2026 sets a term of 12 weeks, which can be extended with mutual understanding to max 22. If it's not integrated at the end of the time and the students turn their attention elsewhere, what's the obvious consequence? I wouldn't expect anything else than the situation you've described in the previous message.

And again, if it's "most wanted by the community" but not at the same time a priority of the maintainer/s, there is a serious mismatch in expectations. It may still be completed (much) later if maintainer/s land their priority items and get around to it, or it may not happen at all if they find it unimportant.

Because "most wanted by the community" is not "most important and urgent" for those who do the actual work.

...

That being said, if your concern is mailman being valuable, what makes you think it critical that past GSoC bits that haven't fallen into the place you'd wished for? Why would one value a half-finished GSoC material package more highly than Mailman?

I didn't get it, sorry, please elaborate.

Someone needs to work on those "most wanted by community" wishes. Code doesn't write itself magically, and especially not the design of use case, interface, architecture, and potential counter-side groundwork that's required for integration (which might include refactoring!)

If it's really important for Mailman, it CANNOT be delegated to an unknown party that's an unknown outsider to that point.

If it's really important for the community, the community needs to find ways to enable the solution. Finding someone to do it, doing something else for them...

And expecting the same quality of work for a student's pocket money as a 500-hour programming contract with a freelancer or service provider (with references or other track record in that same area of expertise and in similar environments) would deliver -- that is expecting too much, too. 12 weeks are damn short.

A GSoC term can only cover a small sufficiently delineated well-specified feature at best, and only if at the same period maintainers have time to work with student and mentor. If a project or organization is pressed for their own working capacity already, they shouldn't try to offer a GSoC project because they can't see it through, and the project is just the tapestry in the room the student happens to spend their summer.

-- Matthias Andree

Am 17.03.26 um 16:14 schrieb Stephen J. Turnbull:

Matthias Andree via Mailman-Developers writes:

...

Are you sponsoring the completion of what the student project has left behind half-done?

I generally agree with your post, but "half-done" is s a bit unfair -- it is a requirement that GSoC projects be on the way to integration to be passed. It's often a significant amount of work that's mostly drudgery (documentation, tests), of course.

My apologies, I did not mean to have "half-done" be understood as an exact quantification nor to belittle anyone's GSoC efforts or treat honest endeavours unfairly - that was my terse way of saying "incomplete with pending polishing and integration work to complete". I should have written that. Sorry.

Hi Stephen,

Thank you for your comments, I have only two more cents to add (see below)

On Tue, Mar 17, 2026 at 5:06 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:

Banner seen at the World Baseball Classic:

          +----------------------------------+
          |                                  |
          |  Mom! send money or developers!  |
          |                                  |
          +----------------------------------+

This is funny, of course, but I'm already sending money monthly for a while as a Mailman official donor mentioned on the page https://wiki.list.org/COM/Donors

Also, I make a lot of contributions to various Mailman repositories, you can see them on the page https://gitlab.com/danil-smirnov

As per the Opus 4.6-powered investigation, code-wise, I contributed 45 commits with 2,657 line insertions and 576 deletions in 2025-26.

I think there are about 10 committers still, but as you know only Mark and I are active on the lists, and only Mark and Abhilash are doing a lot of reviewing outside of GSoC. None of us are paid to do Mailman development, or even get "release time" from our employers from it.[1]

If I were you, I'd definitely consider expanding the reviewer team*. You look very much like a bottleneck on this project now (see Дилян's email).

• • I personally can not join because of the conflict of interest.

Sincerely, Danil Smirnov

...

and we still don't have the "List Configuration Tool" available after 3 years, so I suppose I have the right to raise this issue...

You have the right to do (or fund[2]) the work too. The last time I talked to the contributor he wanted to finish the work, but if I had an offer I'd talk to him and most likely he'd be willing to let somebody else finish up. In the meantime I had other things I wanted to work on, which is, you know, how we volunteers roll.

Footnotes: [1] OK, Mark and I are now retired, but we do have non-Mailman lives.

[2] Note that funding the work gets you the feature, but it doesn't necessarily guarantee it gets in to the public distribution. Most likely work that was solicited for GSoC would get in, but I've seen a few implementations of solicited features that were "good enough" for the developer, but unacceptable for some reason to various projects.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan