GSoC Re: [GSoC] Support for REST Callbacks in Core - design feedback
Hi Stephen,
On Wed, Mar 11, 2026 at 6:18 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
khushal via Mailman-Developers writes:
i'm thinking of a pub-sub layer inside MM3 core using a outbox + worker design,
My apologies, I should have removed that task. It was done last summer, but the contributor changed career paths midsummer and hasn't finished the integration.
I'm sorry, but what does this mean?
Does this mean that any Mailman task unfinished in previous seasons goes to a GSoC graveyard where it sits forever, effectively blocking any other effort in this direction?
It sounds awful.
I hope Mailman is a valuable product in its own right, not just a training toy for GSoC students (I don't have anything against GSoC in general, though). The most interesting ideas collected for GSoC should be implemented, not left buried in the GSoC archives.
We already had this talk before: https://mail.python.org/archives/list/mailman-developers@python.org/thread/5...
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...
Sincerely, Danil Smirnov
Danil Smirnov via Mailman-Developers writes:
Does this mean that any Mailman task unfinished in previous seasons goes to a GSoC graveyard where it sits forever, effectively blocking any other effort in this direction?
No. Don't bother me now.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Am 14.03.26 um 09:40 schrieb Danil Smirnov via Mailman-Developers:
Hi Stephen,
On Wed, Mar 11, 2026 at 6:18 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
khushal via Mailman-Developers writes:
i'm thinking of a pub-sub layer inside MM3 core using a outbox + worker design,
My apologies, I should have removed that task. It was done last summer, but the contributor changed career paths midsummer and hasn't finished the integration.
I'm sorry, but what does this mean?
Does this mean that any Mailman task unfinished in previous seasons goes to a GSoC graveyard where it sits forever, effectively blocking any other effort in this direction?
It sounds awful.
I hope Mailman is a valuable product in its own right, not just a training toy for GSoC students (I don't have anything against GSoC in general, though). The most interesting ideas collected for GSoC should be implemented, not left buried in the GSoC archives.
We already had this talk before: https://mail.python.org/archives/list/mailman-developers@python.org/thread/5...
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...
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.
So _how_ do you, Danil, propose, concretely, to organize the required items (resources, expertise, acceptance) to get those half-finished items completed and integrated?
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. 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.
GSoC doesn't cover the second phase though, so integration of GSoC-made material seems like a game of luck.
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?
-- Matthias Andree
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.
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.
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.
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).
If this is the case, my questions are definitely irrelevant, and I'd say the entire GSoC-related discussion in this list, honestly, too. If we don't expect any benefits for Mailman from GSoC, why use this list, given all the discussion? It needs its own list, dedicated primarily to GSoC rather than Mailman.
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.
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.
Sincerely, Danil Smirnov
-- Matthias Andree
Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-leave@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
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
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.
and nobody/nothing stepped up to take them behind the goal line outside GSoC.
There is no defined mechanism for that except for the contributor to complete. It is true that projects are discussed here and the old task lists remain on the wiki, so somebody who's interested can bring it up at any time. That's more catch as catch can than if you get it done during the GSoc period though, and quite rare (for Mailman anyway).
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
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.
Danil Smirnov via Mailman-Developers writes:
On Wed, Mar 11, 2026 at 6:18?PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
My apologies, I should have removed that task. It was done last summer, but the contributor changed career paths midsummer and hasn't finished the integration.
I'm sorry, but what does this mean?
Now that I have some breathing room, let me explain what it means.
Does this mean that any Mailman task unfinished in previous seasons goes to a GSoC graveyard where it sits forever, effectively blocking any other effort in this direction?
Of course it doesn't. Anybody who is not a GSoC contributor would be free to pick it up (original contributor has right of first refusal, but they have to publish a repo which implies GNU GPLv3+, so anybody else can follow along and pick it up at any time). However, GSoC has rules prohibiting cooperation among contributors when one person's work depends on another's. I don't know that continuing a previous project would violate them, but I'm not real interested in testing it when there are plenty of greenfield projects. On the other side, I'm not comfortable asking a GSoC contributor to start from scratch given that somebody already did most of the work.
It sounds awful.
Hakuna matata, man. Volunteer open source sucks that way, lots of people do not finish their projects, but you'll be a lot happier if you don't worry about that. If you look at the GSoC orgs that reliably get their projects integrated, they're either the New! Bright! Shiny! thing of the summer, or the project is basically somebody's master thesis. Projects like Mailman that are very stable, just work, and for practical purposes in maintenance mode sadly don't attract the same kind of enthusiasm from people who have a thesis to write or a job to go to.
I hope Mailman is a valuable product in its own right, not just a training toy for GSoC students (I don't have anything against GSoC in general, though). The most interesting ideas collected for GSoC should be implemented, not left buried in the GSoC archives.
Banner seen at the World Baseball Classic:
+----------------------------------+
| |
| Mom! send money or developers! |
| |
+----------------------------------+
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]
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
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
Danil Smirnov via Mailman-Developers writes:
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).
He made it clear he wants to push to trunk when he feels like it, and won't commit to finishing at all, let alone within a reasonable time frame. That's just not acceptable. I tried to get him to go there, but he explicitly refused. What do you want me to do?
- I personally can not join because of the conflict of interest.
That's up to your personal ethics, but I don't see a prohibitive conflict based on what I know (obviously, see my .sig). I deal with having a commercial interest by asking other committers for review of my MRs, and taking my time about forcing the issue if they're too busy. Obviously it's a little bit different to work on the project for 25 years and then become a consultant, but the net result is a conflict. Others manage it well. (And I've even seen people like Guido van Rossum and Glyph take crap for "conflicts" because they pushed projects others didn't think were important, but did matter for their employers or clients. Cut me a break on that, will ya? Those were useful changes for a lot of folks, even if not a majority.)
My main issue with adding you is I don't see you much on the lists, and you're not in GitLab discussing issues or MRs I'm familiar with, where I do see Mark and Abhilash a lot, and did see Barry, Terri, and pingu a lot too back in the day in all of those forums. I think that committers should serve the users and the other developers in a variety of ways, as well as demonstrating a connection to the design philosophy and architecture of the project. I don't think just speeding up code additions based on reviewing the snippets you see in a MR is that big a contribution.
None of that makes you specifically less an asset to the community in many ways (including that commercial support, just because you're supporting the community doesn't mean you have to be a volunteer). But I don't know if committer is a role you would fulfill well, and I'd be a lot more comfortable proposing you for the role if I were aware of those kinds of service (and, of course, if you said you were interested!)
A final note -- I play project leader on TV because we need a spokes- person, but Abhilash is the project leader. He has been personally very busy so we let him concentrate on architectural work and his own projects like the sample docker configuration. I've been channeling leaders for 30 years, and they tell me I'm usually accurate, or at least acceptable, so I don't stop. But if you don't like what I say, you can appeal to other committers, and in particular to Abhilash.
Regards, Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (3)
-
Danil Smirnov -
Matthias Andree -
Stephen J. Turnbull