Re: GNUstep releases this month?

[Fred Kiefer]

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 <ivan@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 <fredkiefer@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 <ivan@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.
>>> 
>> 
>> 
>