On Wed, Jun 12, 2019 at 2:42 PM E. Madison Bray <erik.m.b...@gmail.com> wrote: > > On Wed, Jun 12, 2019 at 3:14 PM Dima Pasechnik <dimp...@gmail.com> wrote: > > > > On Wed, Jun 12, 2019 at 2:03 PM E. Madison Bray <erik.m.b...@gmail.com> > > wrote: > > > > > > On Wed, Jun 12, 2019 at 2:46 PM Dima Pasechnik <dimp...@gmail.com> wrote: > > > > > > > > On Wed, Jun 12, 2019 at 1:05 PM E. Madison Bray <erik.m.b...@gmail.com> > > > > wrote: > > > > > > > > > > On Wed, Jun 12, 2019 at 11:45 AM Dima Pasechnik <dimp...@gmail.com> > > > > > wrote: > > > > > > > > > > > > On Tue, Jun 11, 2019 at 7:52 AM E. Madison Bray > > > > > > <erik.m.b...@gmail.com> wrote: > > > > > > > > > > > > > > I don't know why the rush to call this a release candidate when > > > > > > > there are clearly still several outstanding problems to be > > > > > > > resolved before the next release. > > > > > > > > > > > > > > As usual absolutely zero communication of a plan or coordination > > > > > > > with the community. > > > > > > > > > > > > > my ongoing complaint is the lack of progress on the improving the > > > > > > release procedures to make it easy to change the configure package. > > > > > > At the moment it is extremely sub-optimal, with endless merge > > > > > > conflicts resulting solely from the need to have the ticket branch > > > > > > that changes configure.ac, spkg-configure.m4 files, and its friends, > > > > > > such as sage/big/sage-env* things coming with its configure > > > > > > "package" > > > > > > tarball. This leaves tickets of this sort languishing for months, as > > > > > > it's not really possible to get them in sync with the ongoing > > > > > > release > > > > > > process (already due to configure tarballs coming with artificial > > > > > > version numbers, that should not clash etc). > > > > > > > > > > > > I continue to think that the release process should not require > > > > > > updates of configure package. Sage seems to unique in its insistence > > > > > > on the release process depending on the autogenerated dumps... > > > > > > > > > > One very easily solution to this, and I know some people will shudder > > > > > (myself included) is to simply include the configure script in the > > > > > repository. Yes, it's generated. But there's precedent for this. > > > > > > > > well, it would make running patchbots easier, but > > > > I don't see how this would help the release management, > > > > as auto-merging would be still be out of the question. > > > > > > > > The auto-generated crud is simply unmergable, by and large. > > > > > > That really depends on the change in question. Oftentimes they're > > > quite discrete. It only becomes a mess when you have to do lots of > > > AC_REQUIREs and thus things get reordered in the configure script. > > > > > > That is a problem for us right now since we're doing a lot of > > > heavy-lifting on configure. Once a lot of that is out of the way it > > > will calm down a bit. > > > > given the speed things at present move on #27330, it can easily take a > > year or two. > > And still, as we shift more into using external libraries, there is > > going to be more tweaking of > > the configure package than in the olden days... > > Absolutely; which is maybe a good reason to just include the configure > script in the repository.
as well as all the stuff in config/ and build/make/Makefile-auto.in so it's more than just one file. > True, that would not fix all the merge > issues you're struggling with, but on some level that is almost > unavoidable, at least when testing/building on systems that are not > able to run autoconf smoothly. A more complex workaround involving a > separate build system just for autoconf is probably not worth the > effort compared to that one minor concession. it's a not a workaround - the current release process is a huge bottleneck for #27330 and it is simply buggy, as merging new/updated spkg-configure.m4 files and stuff in m4/ without updatng configure is error-prone. Having this in place would simplify things and make them more robust. If merging into WIP happens on a local box (I don't recall how Volker does it), and then the result is pushed to bots (or pulled by them) I really do not see a reason for it not being in place, it's totally trivial to implement. If the merging happens on github/lab, it is still not hard to put some commit hooks/TravisCI calls/whatever into place to make it happen. All this can be also made to create a configure tarball and push it somewhere. > > Meanwhile, keeping it in the repository will make it much easier to > maintain said "tweaks". > > I'm not going to fight tooth-and-nail for it, but I'll just emphasize > > 1) We'd be far from the first project to make this concession > 2) It will make enough peoples' lives easier that it's not so bad to > have one generated (plain text) file in the repo > > > > > For the most part, when making small tweaks to > > > a single autoconf macro, the resulting change in the generated > > > configure script is more-or-less a direct translation. > > > > > > So for fixing bugs in configure alone it would be useful to keep the > > > generated script in the repository and not have to mess with this > > > configure tarball every time. > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "sage-release" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to sage-release+unsubscr...@googlegroups.com. > > > To post to this group, send email to sage-release@googlegroups.com. > > > Visit this group at https://groups.google.com/group/sage-release. > > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/sage-release/CAOTD34b3SLks2hmA_RmF24ikyW3Z9JR-gi3LtnjuAnBurwfecQ%40mail.gmail.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sage-release" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to sage-release+unsubscr...@googlegroups.com. > > To post to this group, send email to sage-release@googlegroups.com. > > Visit this group at https://groups.google.com/group/sage-release. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/sage-release/CAAWYfq2AssVut_34C0d9i85mXkAFnJMiRRv7Q9QCoWKRmDNygg%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "sage-release" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-release+unsubscr...@googlegroups.com. > To post to this group, send email to sage-release@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-release. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-release/CAOTD34Z7UnoxUd7nKchpHMiT_nSGEB2sqSWKjyjSdKGW4_GtwQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-release/CAAWYfq0HaPo3CHigqZdWVcOM715evPw89ujOYVRBZSq8bATr2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
