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 <
[email protected]> 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
_______________________________________________
Mailman-Developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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
