Re: GNUstep releases this month?

Ivan Vučica <[email protected]>
Newsgroups gmane.comp.lib.gnustep.devel
Message-ID <CAGPLYoTi9nXoqBFp3ui_oxyhT9en2yksjm+w_-0eTWivn0LgHg@mail.gmail.com>
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 <[email protected]> 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 <[email protected]>:
> >
> > 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.
> >
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.