I think a priority should be making sure that Sage builds, so just get a fresh git clone and run 'make build'. That might take under half an hour depending on the machine and how many system packages get used, so even less time if building will actually fail.
On Thursday, October 2, 2025 at 11:50:37 AM UTC-7 [email protected] wrote: > On Thu, Oct 2, 2025 at 12:15 PM John H Palmieri <[email protected]> > wrote: > >> >> >> On Tuesday, September 30, 2025 at 4:29:28 AM UTC-7 [email protected] >> wrote: >> >> Hey there, >> >> I am very grateful that people put their time into working on the build >> system, packaging, and these little developer annoyances. After some >> initial hiccups, it's been a joy to work with meson, not having the docs >> build all the time is imho the right thing to do, and installing with conda >> has proved much easier (and at the very least it fails much faster, at >> least when I am doing the hand-holding.) That's my personal experience and >> I understand that for others such changes might have been much more >> annoying. >> >> Personally, I was not too surprised by any of these changes. Maybe >> because I happened to stumble upon the relevant PRs on GitHub before things >> were merged. But apparently that didn't work for many other people. I think >> it's a good idea to announce anything that is likely going to affect >> developers before it's merged. I don't think this means that everything >> that affects developers needs a vote but announcing things is a friendly >> gesture and if people then have doubts that this is the right way forward, >> we can still call for a vote. >> >> On Monday, September 29, 2025 at 11:34:44 PM UTC+3 Nils Bruin wrote: >> >> Autocratic rule by just forcing decisions through does not invite buy-in >> and ultimately will narrow the community; not grow it. >> >> >> I think a friendlier aspect would be to call this do-ocracy but of course >> I understand what you mean. Ultimately, many open source projects work to >> some extent like that. The project (by whatever governance) might decide on >> a direction but if nobody is willing to implement things, then such a >> decision doesn't really matter. Instead, when somebody is willing to >> improve things, I think the general attitude should be a supportive one. Of >> course people should invite buy-in and listen to criticism (and in our >> system this might ultimately lead to disputed PRs or a vote on sage-devel.) >> >> On Monday, September 29, 2025 at 7:12:49 PM UTC+3 John H Palmieri wrote: >> >> If someone is working on the build system and neither the author nor the >> reviewer think to try it out on a fresh git clone, I think it's also fair >> to call that careless. >> >> Others may disagree with me. >> >> >> Yes, I think I do disagree :) I would have expected the automated testing >> (buildbot) to catch such an issue somehow. I personally think it's too much >> to ask from a reviewer to try something like this. After all, what would >> have been thorough? Whether it builds from a git clone & from a tarball & >> from a previous build on Linux & macOS…then I'd rather not review to be >> honest. I don't have the changeset in front of me but I think it's a call >> for the author to make which scenarios to check (and I am sure the author >> checked some scenarios that they saw most likely affected.) When you make >> changes on the foundations, stuff breaks, people are sorry, and we move on. >> That's unfortunate but that's life. I think that's one of the main reasons >> for CI, i.e., to detect unexpected breakage. >> >> >> I think that building from a fresh git clone is not an unreasonable thing >> to expect a careful reviewer and author to do. It's certainly something I >> do if I'm testing a change that affects the build system. This is >> especially the case for the particular situation here: the PR deleted a >> filed called, I don't know, blah.py.in or something. If you are doing an >> incremental build, the file blah.py will likely already be present from a >> previous build, so maybe the only way to see an impact of this change is to >> build from a fresh clone. (Does "make distclean" remove all of these >> autogenerated files? I don't think so, but I'm not sure.) I would also say >> that a careful reviewer will absolutely use the automated testing >> framework, but they will also know that this framework has its limitations. >> > > Even on a fast machine with most packages pre-installed system-wide > (running e.g. Gentoo Linux), > cleaning the repo, > configuring with `--enable-system-site-packages`, and > build+tests+docbuild still takes ~1.5 hours (longer if you do long tests, > have lots of optional packages, etc). > Another hour if `--enable-system-site-packages` is not used. Another hour > or 2 if you updated something that a lot is relying on, e.g. flint, > and have to build many big packages, like Singular. > So, assuming you don't review more than 1 PR in parallel, it can easily > take 2-3 hours on average. > OK, I often review seemingly unrelated PRs in parallel. And yes, I often > don't test in such a throughout way something that, seemingly, > is not potentially breaking things (but then, well, indeed, a silly typo > can break things far down, in a test, or in docbuild). > > Docbuild is a major drag, it needs to get dependency tracking to avoid > rebuilding the whole thing. > > By the way, to give you an example of careless, in my book, reviewing: > #40877. > (it wasn't actually even reviewed, the release manager just pushed it > through, over our protests). > It reverted #40765, which in particular made sure that there is a way to > find > Sage's cython directories, via sage.config. Now for instance > sage_numerical_backends_* (coin, etc) cannot be built because the old way > to find cython > directories is gone, and the new way got reverted. > > So now, there is a request to revive sage_numerical_backends_coin, and one > has to dig through the branch of #40765 to fish out the necessary bits. > > Dima > > > > > > > > > > >> >> >> julian >> >> -- >> 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 [email protected]. >> > To view this discussion visit >> https://groups.google.com/d/msgid/sage-devel/58dee9b6-ec90-4e4a-ae7c-0d4f055e0777n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/sage-devel/58dee9b6-ec90-4e4a-ae7c-0d4f055e0777n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/e302dfd4-f764-4e4c-a109-b5da4b4d893dn%40googlegroups.com.
