Please don't!
+1 for sure
> The modularization project (making pip-installation packages that contain
portions of the sage library) started years ago with a general consensus of
the sage community. Matthias led the project and did most of hard works.
Many others did not care much about the project and still do not feel the
impact except when encountered with the (annoying) "# needs ..." tags.
Matthias is also managing much of the sage build system and the CI (mostly
testing infrastructure) on github, partly to support the modularization
project. Many of us would appreciate that.
Also +1 for sure
> Such allegations will have no effect other than to antagonize the other
party. This is not helpful in fostering constructive debate. Please keep
this thread to a simple explanation of the issues at hand, so that
interested community members can make an informed decision on their vote
(or on whether to vote at all).
+1 to both times this was said (even though I'm violating "issues at hand"
with this comment)
It's worth noting that "whether to vote at all" is, as typical in Sage,
mostly being honored by not voting. Trac was similar - it was often hard
to get people to review even simple tickets that weren't squarely in
people's domain of experience within the vast Sage library. For those of
us who don't really know that much about .toml files, packaging, or
modularization, we would like to trust that some roadmap that addresses all
concerns *in an acceptable, if quite imperfect, compromise* can be come up
with by those who *do* have expertise in those matters.
But they'll have to ignore the personal/political matter, hard as it might
be. *Even if it's true* that there is "sabotage" or "refusing to assess"
(which this post remains neutral on), if it is *possible* to interpret a
code change request as being well-intentioned and helping some aspect of
packaging, then that should be done. Until such time as another Sage Days
*in person* could be held on a topic like packaging, the best operating
procedure for online-only discussions is to give the most charitable
possible interpretation to a given code request - and refrain from any
comments that imply ill will on the part of another, *even if you think
there is ill will*. (Then the truly ill willed statements will be clear,
at least, instead of currently sometimes being themselves ambiguous.)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/bb7c57ca-1f3d-4d07-8761-6214a150a179n%40googlegroups.com.
