Maintaining the chunk module after it has been removed from the standard library

[malemburg (Marc-André Lemburg)]

Thanks, @jscuster

I think this is a perfect example of how the community maintainer role for stdlib modules (discussion: see further up) could work.

[vstinner (Victor Stinner)]

@malemburg

I think this is a perfect example of how the community maintainer role for stdlib modules (discussion: see further up) could work.

I think that it’s a perfect example that having a module in the Python prevents people to contribute and evolve the module (since the chunk was unmaintained for years in the stdlib), whereas maintaining it outside Python gives more freedom and makes its maintenance easier. The development was faster since the author doesn’t have to be a core developer to merge pull requests, there is more freedom on the coding style and reviews (or lack of review). For me, it confirms that the PEP 594 was a good move.

[malemburg (Marc-André Lemburg)]

@vstinner

The development was faster since the author doesn’t have to be a core developer to merge pull requests, there is more freedom on the coding style and reviews (or lack of review).

Exactly, and that’s why having such an official new role as a community maintainer makes a lot of sense for currently unmaintained stdlib modules.

They can work outside the core dev environment and then submit their changes back to the core once they are happy with the results. This reduces the work load on core devs (a single review and check-in vs. having to deal with the development process itself), improves the modules and creates a much more open and scalable development approach.

@vstinner

For me, it confirms that the PEP 594 was a good move.

Not in all cases. PEP 594 simply removes modules from the stdlib without trying to find new maintainers. That really goes against the “batteries included” theme, Python is appreciated for, and is not a good solution to the problem.

[vstinner (Victor Stinner)]

@malemburg

They can work outside the core dev environment and then submit their changes back to the core once they are happy with the results. This reduces the work load on core devs (a single review and check-in vs. having to deal with the development process itself), improves the modules and creates a much more open and scalable development approach.

Let’s make the the assumption that the chunk module comes back into Python stdlib but is also maintained externally. Who is going to review big changes which updates chunk in the stdlib? Are you going to do these reviews? If you don’t have time, can you please give the name of 1 or 2 core devs who are volunteers to do that?

[malemburg (Marc-André Lemburg)]

Determining how this should work and who would be responsible to do such reviews would be part of declaring someone a community maintainer and yes, I would do the reviews, if needed and wanted – just like I do now for some of the PRs.