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. 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.
