On Fri, Oct 3, 2025 at 12:08 PM John H Palmieri <[email protected]> wrote:
> 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. > Run "make" nowadays, yes :-) Under half an hour on Gentoo with everything installed, yes. Several times longer on macOS, where everything dependent on openblas must be built, most Python packages must be built, GAP and eventually its packages must be built, etc. A part of the price you pay for demanding that every PR builds and doesn't break any relevant test is that some changes need to be done as huge patchbombs, of which #39030 is a prime example (81 commits, 200+ files touched, etc). I probably fully built it 30 or more times as a reviewer (and a minor contributor). And it took much longer than it would have been if it was done in pieces, some of them resulting in broken builds in corner cases or on some platforms. > > 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 > <https://groups.google.com/d/msgid/sage-devel/e302dfd4-f764-4e4c-a109-b5da4b4d893dn%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/CAAWYfq1JqjMwXqG5%3DNMVeeV%2BTgp6GeEV4BCay_YxT0e7WFPytA%40mail.gmail.com.
