gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep releases this month?


From: Ivan Vučica
Subject: Re: GNUstep releases this month?
Date: Thu, 14 Jan 2021 19:13:47 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]