I updated the required files and also increased the version number in both gui and back. I think we normally do this right after a release, but this time I forgot about it. So for these two modules we are theoretically ready for a release.
Cheers, Fred > Am 14.01.2021 um 20:13 schrieb Ivan Vučica <i...@vucica.net>: > > Hi Fred, > > thanks for a quick reply! > > I suspect that's where the difference between soft- and hard-freeze > kicks in, but Yavor can maybe provide some insight in this regard. > > If I get the green lights from other maintainers, I can cut releases next > week. > > If a maintainer wishes me to release and upload anything that is not > included in the usual batch of releases on ftp.gnu.org, let me know > and I can try pushing that out as well. > > On Thu, Jan 14, 2021 at 6:27 PM Fred Kiefer <fredkie...@gmx.de> wrote: >> >> Hi Ivan, >> >> great that you remind us! The problem at the moment is that there is a know >> problem for 64bit big endian systems in gui (actually a rather long standing >> issue) and even two suitable solutions for it. But we haven’t decided which >> solution to prefer. Either we reach a consensus quickly and deploy the >> chosen solution to all affected classes or we release with this know issue. >> This sounds worse than it is. We had the issue for a few years and releases >> already and nobody noticed. >> >> Apart from that I promise to bring the release notes of gui and back up to >> date over the weekend. >> >> Cheers, >> Fred >> >>> Am 14.01.2021 um 18:40 schrieb Ivan Vučica <i...@vucica.net>: >>> >>> Hi maintainers et al! >>> >>> What's the status of our individual projects? Should I plan on cutting >>> the releases this or the next weekend? >>> >>> Debian is soft-freezing on 2021-02-12. >>> https://wiki.debian.org/DebianBullseye >>> >>> I'd like to ask maintainers who are interested in a release happening >>> to please update the release documentation (see my commits from >>> just-before-the-previous-release). Obviously, there's no need to >>> update anything that's automatically generated. >>> >>> The less time I need to spend on producing the release notes by >>> reading through the commits and trying to piece together a story, the >>> easier it is to make the release, validate it builds, sign it, upload >>> it, prepare the signed emails for sending to GNU announcements, etc. I >>> am happy to review maintainers' (or other volunteers') PRs updating >>> the docs. If the docs are not updated, I am still ok writing the >>> updates myself, it might just be messy. >>> >>> The faster we can cut a release, the higher the chance that there's >>> enough time for Debian package maintainers to get the package through >>> the bureaucracy and into the bullseye archives. >>> >> >> >