Re: Next GNUstep release
Please also see the other thread for my thoughts so I don't repeat
them in detail, but just this:
On Mon, Apr 6, 2020 at 2:46 PM David Chisnall wrote:
> Compare these two pages:
>
> The ChangeLog file:
> https://github.com/gnustep/libs-base/blob/master/ChangeLog
>
> The Git history:
> https://github.com/gnustep/libs-base/commits/master
>
> The second is easier to skim, easier to jump to exact changes, and
> easier to use to isolate change in a particular area (only care about
> changes in the tools? Look here:
> https://github.com/gnustep/libs-base/commits/master/Tools instead of the
> main history page).
If you carefully look into individual messages over the span of a year
with limited time to examine each change -- you are likely going to
share my experience of finding individual commits are very
non-detailed.
Should we enforce each commit to be larger before publishing? Should
we enforce commit chains to end up in a merge commit which is
detailed? Should we enforce updating changelog-equivalent only when a
particular feature is finished and ready to be added -- but *enforce
it consistently*?
Again, I don't want to have to have to distinguish between "this is
adding a new class", "this is fixing a security bug", "this is
*partially* addressing a security bug", "this is a quick compile fix",
"this is a large overhaul of the build system" by having to inspect
each commit in a really long chain of commits. Not necessarily a tree,
even.
FWIW ChangeLog entries *when written* were more useful for this
purpose. The problem was *when they weren't written*.
It's not necessarily true that the ChangeLog format is useful, but we
either need something like it, or we need to hold ourselves to strict
high standards of how we write commit messages, or we need cover
letters / detailed merge commits, or each new commit *must* have a
*tracking* bug ("issue") entry that we can use to write release news.
Git commits as written today are unsustainable.
> In terms of generating the ChangeLog entries automatically: I used to do
> this when we used svn. I had a little script that would take an svn log
> and write a ChangeLog entry. I didn't write the script, and when I
> looked no one had written a version that worked with Git. I take this
> to mean that there is very little perceived requirement for ChangeLog
> files. Having a non-canonical copy of information that has a canonical
> home doesn't seem valuable. If people want it, then they can do a git
> log > MyOwnChangeLog.
This is a nonsolution if git messages keep being to the tune of
"Actually fix the implementation" <-- which implementation? how? why?
what's getting fixed? what was broken in the first place?
ChangeLog, *when written*, have been less of a problem *during this
particular release timeframe*.
>
> >
> > Then we would be saved the overhead of writing ChangeLog entries and could
> > concentrate on:
> > 1. meaningful commit entries, which of course we should all be doing
> > anyway;-)
> > 2. writing release notes for any substantive change (rather than ChangeLog
> > entries for even minor changes), to appear in the NEWS when we make a
> > release
>
> The second of these is the difficult bit, but it's *incredibly*
> valuable. For the runtime, I try to update the ANNOUNCE doc as I go,
> but I still end up having to skim the git logs to check if I missed
> anything. LLVM and FreeBSD both end up with manual steps and chasing
> contributors to update these just prior to release (FreeBSD has a
> 'Release-Notes: Yes' thing you can put in the commit message so that the
> release engineer will look at it for things to put in release notes).
>
> > If we stop writing ChangeLog entries, we should be able to write release
> > notes and still be spending less time, and of course that would make the
> > process of cutting a release less onerous.
> >
> > Does this seem a reasonable approach?
>
> +1.
Yes please. Let's do both. Let's write a note whenever you are halfway
or fully done with a new feature, whenever you fix a bug.
Enforce that commits, when merged, include this.
Whether you put it in news.texi, or write these notes in ChangeLog
(referencing exact files or not), or we keep release notes in a new
directory, with files named '-MM-DD-NN' that we flush as part of
the release process, I don't care much.
But maintainers, please just decide something and proclaim that this
is what will be done. It doesn't have to be consistent among packages,
but *within* a particular release of an individual package, I'd like
to see consistency. We can't have some people "opt-out" of the chosen
process. Maintainers need to be the ones to enforce this, including
possibly writing the log entries ('blogposts'?) themselves.
Re: Changelog and git log hygiene
I can concur it can be senseless with 1:1 mapping between commits and the
logs.
However neither is that true, not have the git commit messages been kept up
to date, nor has there been an easily interpretable log of what changes
have been made.
I would propose changelog can be mutable (if you keep working on a change,
update it over time). Or we can keep a differently formed log of changes.
Git messages are inappropriate, in my opinion, because they are about
tracking individual chunks of changes ("tactics"), not the larger change
("strategy"). Think: "there should be a cover message for commits", as is
the case with mailing list based review and merge approach. Pull request
model is a possible way out, but requires everyone to consistently adopt
it; the message ends up in there as a merge commit, editable at the time of
the merge, which is nice.
But either there's more sensible logging of changes over time, or we do
away with announcing changes in a release that happens yearly. Because as
is, it's too much for a person to spend an afternoon being effectively a
journalist of code archaeology.
Is this a fix? Is this a security fix? Is this just a part of a security
fix? Or is this a new feature? Or is this a portion of a new feature? Has
this skeleton implementation been finished before this release -- how do we
announce the work done? "Implemented" or "stubbed out"?
Either everyone please agree to keep a journal in ChangeLog file, or
another change log; or consistently write about large chunks of code you
wrote (e.g. NSOrderedSet as one entry of 3 sentences rather than 30 commits
without anything related among them) so we can put them in release notes.
But whoever is cutting the next release (likely me, I'm ok doing it) should
not have to understand and sift through one sentence commits that describe
what was done, but neither why nor on what. Treat git commits as isolated,
or treat merge commits as a unit of work, or write some descriptive log, or
elect not to announce changes.
Those are the options.
sent from phone
On Mon, Apr 6, 2020, 14:37 Gregory Casamento
wrote:
> I, honestly, believe that the ChangeLog should be phased out. Either
> that, or the git log should be used to generate it. I, need to update the
> ChangeLog as I have not added a LOT of my recent changes since they have
> been extensive. I realize I am in the wrong here, but I can see the logic
> in David C's previous assertion that the ChangeLog should be done away
> with. Just my thoughts.
>
> GC
>
> On Sun, Apr 5, 2020 at 11:51 AM Ivan Vučica wrote:
>
>> Hello!
>>
>> For sake of making future releases easier, can we please:
>>
>> - keep ChangeLog up to date
>> - ensure ChangeLog content is in vague sync with commit messages (not
>> exact, as it would defeat the purpose, but at least approximate)
>> - make sure our commit messages are cleaner
>>
>>
>> Examples with minor edits for formatting follow. Note that this looks
>> to be a problem across the board with all committers, nobody in
>> particular:
>>
>>
>> git commit message:
>> "Fix crash in gdomap when an invalid hostname is given for the -M option"
>> changelog message:
>> "* Tools/domap.c:
>> Fix crash in donames() when getaddrinfo returns an error"
>>
>> I find the first one much more useful for a newsfile; but the second
>> one is useful implementation detail. I would argue both should be in
>> both changelog and commit message. But this is still fine and
>> understandable.
>>
>>
>> git commit messages:
>> "Fix wrong \U sequence for leter `i` and short weekdays."
>> "Update ChangeLog for last commit to Ukrainian language."
>> "Merge pull request #35 from trunkmaster/master: Updates for Ukrainian
>> language"
>> changelog message:
>> "* Resources/Lanuages/Ukrainian:
>> Fix wrong \U sequence for letter 'i' and short weekdays."
>>
>> Knowing in commit message that the change was done to the Ukrainian
>> language would be useful. Sure, I can pass --stat to git log -r
>> ${PREVRELEASE}..master --reverse, but a clearer message (especially
>> the first line, the one usually up to 70ch) would be better.
>>
>> Especially since --stat actually makes the whole log way harder to read.
>>
>>
>> git commit message:
>> "Correct implementation of method."
>> "Correct method names."
>> changelog message:
>> nothing on April 9, but there is a more detailed message on April 12
>> -- presumably this is because this is a merged larger chain of
>> messages?
>>
>> This is generally fine if I could be sure ChangeLog is reliable and
>> consistently up to date. I'm reviewing logs as I am actually not sure
>> this is the case. Then, a message that says "fixed method" and nothing
>> else isn't helpful. File changed is Source/NSString.m, so I suspect
>> the longer message about character sets actually applies, but still...
>>
>>
>>
>> Clearly I can and will be happy to release as-is and I will try to
>> keep release notes useful to anyone that may want to peek at them.
Re: Next GNUstep release
On 06/04/2020 12:56, Richard Frith-Macdonald wrote: Yes, thanks to Ivan. I have spent some time thinking about this, and while in the past I've argued against dropping ChangeLog (it's more convenient than the git logs, and of course is there for peple who download tarballs etc and don't have ready access to the repositories), but I think overall I kind of agree now. It's very onerous to put comments in multiple places, but there is value to each of these things: Technical information in the repository ChangeLog for easier access Announce/News for summary of important details. What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, in that we could auto-generate ChangeLog entries from the repository, either by an automated commit hook or (assuming that's not easy to do readily), using a script to get details from the repository just before we make a realease, so that anyone getting a release of the software still gets a comprehensive ChangeLog. I think that the place I'd disagree is that the ChangeLog is easier. That was probably true with GNA, somewhat true with viewvc (though debatable), but it isn't true with modern Git toolking (GitHub, GitLab, GOGS and so on). Compare these two pages: The ChangeLog file: https://github.com/gnustep/libs-base/blob/master/ChangeLog The Git history: https://github.com/gnustep/libs-base/commits/master The second is easier to skim, easier to jump to exact changes, and easier to use to isolate change in a particular area (only care about changes in the tools? Look here: https://github.com/gnustep/libs-base/commits/master/Tools instead of the main history page). The ChangeLog is more useable only for people who don't have web access (even if you download the tarball, you can still go to the web site to view the history and if you've done a git clone then you can view and search it offline easily). The last of those is actually a valid reason for svn ChangeLog files that I missed: with svn, svn log was an online operation, so you couldn't do svn log / svn blame without a network connection, but you could read a ChangeLog. With git, that is not a concern because log / blame are offline operations. In terms of generating the ChangeLog entries automatically: I used to do this when we used svn. I had a little script that would take an svn log and write a ChangeLog entry. I didn't write the script, and when I looked no one had written a version that worked with Git. I take this to mean that there is very little perceived requirement for ChangeLog files. Having a non-canonical copy of information that has a canonical home doesn't seem valuable. If people want it, then they can do a git log > MyOwnChangeLog. Then we would be saved the overhead of writing ChangeLog entries and could concentrate on: 1. meaningful commit entries, which of course we should all be doing anyway;-) 2. writing release notes for any substantive change (rather than ChangeLog entries for even minor changes), to appear in the NEWS when we make a release The second of these is the difficult bit, but it's *incredibly* valuable. For the runtime, I try to update the ANNOUNCE doc as I go, but I still end up having to skim the git logs to check if I missed anything. LLVM and FreeBSD both end up with manual steps and chasing contributors to update these just prior to release (FreeBSD has a 'Release-Notes: Yes' thing you can put in the commit message so that the release engineer will look at it for things to put in release notes). If we stop writing ChangeLog entries, we should be able to write release notes and still be spending less time, and of course that would make the process of cutting a release less onerous. Does this seem a reasonable approach? +1. David
Re: Next GNUstep release
Richard, On Mon, Apr 6, 2020 at 7:56 AM Richard Frith-Macdonald < rich...@frithmacdonald.me.uk> wrote: > > > > On 6 Apr 2020, at 09:53, David Chisnall > wrote: > > > > I second that, thank you Ivan, but Fred your proposed solution is going > to add more barriers to entry. > > > > ChangeLog files made sense when people were submitting patches on the > mailing list and distributing code in tarballs. > > > > They were slightly anachronistic when CVS became standard for F/OSS > projects and incorporated per-file change messages but they were still > useful when people used them to describe the relationship between changes > in multiple files. > > > > They were mostly obsolete when projects moved to svn and commits became > atomic. Commit messages then referred to a set of related changes, rather > than to single files. The one remaining argument for them was that VCS > history may get lost in moves between revision control systems. > > > > There was also a minor justification for them based on tooling: commit > messages for svn were written after code review and some tools did not > support reviewing the commit message along with the code (things like > Phabricator did), so you could enforce a ChangeLog message in code review > but you could not enforce a commit message at the same time. > > > > We have now seen projects move from CVS to SVN and then to Git, > preserving commit messages. Git commits have evolved a structure that is > well supported by a load of tooling (vim even gives nice syntax > highlighting to ensure that you confirm to this structure, all of the Git > GUIs, including GitHub, are designed to render it), where the first line is > short and gives a very high-level summary of the changes and the remainder > gives a detailed overview. No equivalent tooling exists for ChangeLog files. > > > > In addition, a branch-and-PR workflow makes it possible to do code > review of commit messages before merging. Git makes it easy to edit and > amend commit messages and force-push a branch, so individual commits can > have their messages edited before a branch is merged. > > > > I would much rather see code review enforcing good commit messages, > which is a workflow that contributors to any other open source project will > be familiar with. I fail to see any benefit in having ChangeLog entries. > > > > Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file > that captures high-level user-visible improvements. We don't necessarily > need PR authors to write that, but the person merging a PR probably should > if not. This is far less granular than a commit message and serves a > separate purpose. > > > > David > > Yes, thanks to Ivan. > > I have spent some time thinking about this, and while in the past I've > argued against dropping ChangeLog (it's more convenient than the git logs, > and of course is there for peple who download tarballs etc and don't have > ready access to the repositories), but I think overall I kind of agree now. > > It's very onerous to put comments in multiple places, but there is value > to each of these things: > Technical information in the repository > ChangeLog for easier access > Announce/News for summary of important details. > > What I'd like to suggest is sort-of (but not entirely) scrapping > ChangeLog, in that we could auto-generate ChangeLog entries from the > repository, either by an automated commit hook or (assuming that's not easy > to do readily), using a script to get details from the repository just > before we make a realease, so that anyone getting a release of the software > still gets a comprehensive ChangeLog. > > Then we would be saved the overhead of writing ChangeLog entries and could > concentrate on: > 1. meaningful commit entries, which of course we should all be doing > anyway ;-) > 2. writing release notes for any substantive change (rather than ChangeLog > entries for even minor changes), to appear in the NEWS when we make a > release > > If we stop writing ChangeLog entries, we should be able to write release > notes and still be spending less time, and of course that would make the > process of cutting a release less onerous. > > Does this seem a reasonable approach? > > I believe this is entirely reasonable. -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron
Re: Changelog and git log hygiene
I, honestly, believe that the ChangeLog should be phased out. Either that,
or the git log should be used to generate it. I, need to update the
ChangeLog as I have not added a LOT of my recent changes since they have
been extensive. I realize I am in the wrong here, but I can see the logic
in David C's previous assertion that the ChangeLog should be done away
with. Just my thoughts.
GC
On Sun, Apr 5, 2020 at 11:51 AM Ivan Vučica wrote:
> Hello!
>
> For sake of making future releases easier, can we please:
>
> - keep ChangeLog up to date
> - ensure ChangeLog content is in vague sync with commit messages (not
> exact, as it would defeat the purpose, but at least approximate)
> - make sure our commit messages are cleaner
>
>
> Examples with minor edits for formatting follow. Note that this looks
> to be a problem across the board with all committers, nobody in
> particular:
>
>
> git commit message:
> "Fix crash in gdomap when an invalid hostname is given for the -M option"
> changelog message:
> "* Tools/domap.c:
> Fix crash in donames() when getaddrinfo returns an error"
>
> I find the first one much more useful for a newsfile; but the second
> one is useful implementation detail. I would argue both should be in
> both changelog and commit message. But this is still fine and
> understandable.
>
>
> git commit messages:
> "Fix wrong \U sequence for leter `i` and short weekdays."
> "Update ChangeLog for last commit to Ukrainian language."
> "Merge pull request #35 from trunkmaster/master: Updates for Ukrainian
> language"
> changelog message:
> "* Resources/Lanuages/Ukrainian:
> Fix wrong \U sequence for letter 'i' and short weekdays."
>
> Knowing in commit message that the change was done to the Ukrainian
> language would be useful. Sure, I can pass --stat to git log -r
> ${PREVRELEASE}..master --reverse, but a clearer message (especially
> the first line, the one usually up to 70ch) would be better.
>
> Especially since --stat actually makes the whole log way harder to read.
>
>
> git commit message:
> "Correct implementation of method."
> "Correct method names."
> changelog message:
> nothing on April 9, but there is a more detailed message on April 12
> -- presumably this is because this is a merged larger chain of
> messages?
>
> This is generally fine if I could be sure ChangeLog is reliable and
> consistently up to date. I'm reviewing logs as I am actually not sure
> this is the case. Then, a message that says "fixed method" and nothing
> else isn't helpful. File changed is Source/NSString.m, so I suspect
> the longer message about character sets actually applies, but still...
>
>
>
> Clearly I can and will be happy to release as-is and I will try to
> keep release notes useful to anyone that may want to peek at them.
> However, continued vigilance *when* making a commit -- it means not
> only people stay up to date *at the time of making a commit*, but also
> helps whomever happens to be cutting the release 15 months later.
>
> Please, write the commit messages as if people view the commits
> standalone. Please, write them as if someone is reading through them
> without context over a year later.
>
>
> Am I myself writing commit messages and changelog entries right? No
> idea; I can only share with you the experience while cutting a
> release. For entertainment purposes, take 1-2min and try to consider
> how you'd write release notes from the output of this:
>
> PREVRELEASE=$(git describe --abbrev=0) # should be: base-1_26_0
> git log -r ${PREVRELEASE}..master --reverse
> git diff -r ${PREVRELEASE}..master ChangeLog
>
> :-)
>
>
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron
Re: Incremental linking
On Thu, 2020-04-02 at 18:18 +0200, Wolfgang Lux wrote: > On Thu, 2020-04-02 at 11:06 +0100, David Chisnall wrote: > > Hello, > > > > For various reasons, I have been reading the binutils ld > > documentation > > and there is a note that -Ur is needed instead of -r for > > incremental > > linking of C++ programs that contain constructors. I suspect that > > this > > is just badly written documentation - can someone try patching > > -make > > to > > use -Ur instead of -r and see if Additions links correctly with BFD > > ld? > > > > David > > I did give it a quick try by recompiling the Additions library with > messages=yes to see the commands being executed by make and then > reexecuted the link command with -Wl,-Ur instead of -Wl,-r. > Unfortunately, that doesn't help for me (Ubuntu 18.04 with clang-9 > and > bfd). Programs still segfault. :-( And just adding on that, it doesn't look like an issue of using the correct flags or not. GNUstep-base works fine for me on a Debian system with Testing, i.e., the upcoming version 11, installed. But there the binutils package is at version 2.34 already. On the other hand, on Debian 10, where I get segfaults when using bfd for the linker, binutils is at 2.31. So it seems likely there was bug in binutils that got fixed somewhere in between those releases. Wolfgang
Re: Next GNUstep release
> On 6 Apr 2020, at 09:53, David Chisnall wrote: > > I second that, thank you Ivan, but Fred your proposed solution is going to > add more barriers to entry. > > ChangeLog files made sense when people were submitting patches on the mailing > list and distributing code in tarballs. > > They were slightly anachronistic when CVS became standard for F/OSS projects > and incorporated per-file change messages but they were still useful when > people used them to describe the relationship between changes in multiple > files. > > They were mostly obsolete when projects moved to svn and commits became > atomic. Commit messages then referred to a set of related changes, rather > than to single files. The one remaining argument for them was that VCS > history may get lost in moves between revision control systems. > > There was also a minor justification for them based on tooling: commit > messages for svn were written after code review and some tools did not > support reviewing the commit message along with the code (things like > Phabricator did), so you could enforce a ChangeLog message in code review but > you could not enforce a commit message at the same time. > > We have now seen projects move from CVS to SVN and then to Git, preserving > commit messages. Git commits have evolved a structure that is well supported > by a load of tooling (vim even gives nice syntax highlighting to ensure that > you confirm to this structure, all of the Git GUIs, including GitHub, are > designed to render it), where the first line is short and gives a very > high-level summary of the changes and the remainder gives a detailed > overview. No equivalent tooling exists for ChangeLog files. > > In addition, a branch-and-PR workflow makes it possible to do code review of > commit messages before merging. Git makes it easy to edit and amend commit > messages and force-push a branch, so individual commits can have their > messages edited before a branch is merged. > > I would much rather see code review enforcing good commit messages, which is > a workflow that contributors to any other open source project will be > familiar with. I fail to see any benefit in having ChangeLog entries. > > Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file that > captures high-level user-visible improvements. We don't necessarily need PR > authors to write that, but the person merging a PR probably should if not. > This is far less granular than a commit message and serves a separate purpose. > > David Yes, thanks to Ivan. I have spent some time thinking about this, and while in the past I've argued against dropping ChangeLog (it's more convenient than the git logs, and of course is there for peple who download tarballs etc and don't have ready access to the repositories), but I think overall I kind of agree now. It's very onerous to put comments in multiple places, but there is value to each of these things: Technical information in the repository ChangeLog for easier access Announce/News for summary of important details. What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, in that we could auto-generate ChangeLog entries from the repository, either by an automated commit hook or (assuming that's not easy to do readily), using a script to get details from the repository just before we make a realease, so that anyone getting a release of the software still gets a comprehensive ChangeLog. Then we would be saved the overhead of writing ChangeLog entries and could concentrate on: 1. meaningful commit entries, which of course we should all be doing anyway ;-) 2. writing release notes for any substantive change (rather than ChangeLog entries for even minor changes), to appear in the NEWS when we make a release If we stop writing ChangeLog entries, we should be able to write release notes and still be spending less time, and of course that would make the process of cutting a release less onerous. Does this seem a reasonable approach?
Re: Next GNUstep release
I second that, thank you Ivan, but Fred your proposed solution is going to add more barriers to entry. ChangeLog files made sense when people were submitting patches on the mailing list and distributing code in tarballs. They were slightly anachronistic when CVS became standard for F/OSS projects and incorporated per-file change messages but they were still useful when people used them to describe the relationship between changes in multiple files. They were mostly obsolete when projects moved to svn and commits became atomic. Commit messages then referred to a set of related changes, rather than to single files. The one remaining argument for them was that VCS history may get lost in moves between revision control systems. There was also a minor justification for them based on tooling: commit messages for svn were written after code review and some tools did not support reviewing the commit message along with the code (things like Phabricator did), so you could enforce a ChangeLog message in code review but you could not enforce a commit message at the same time. We have now seen projects move from CVS to SVN and then to Git, preserving commit messages. Git commits have evolved a structure that is well supported by a load of tooling (vim even gives nice syntax highlighting to ensure that you confirm to this structure, all of the Git GUIs, including GitHub, are designed to render it), where the first line is short and gives a very high-level summary of the changes and the remainder gives a detailed overview. No equivalent tooling exists for ChangeLog files. In addition, a branch-and-PR workflow makes it possible to do code review of commit messages before merging. Git makes it easy to edit and amend commit messages and force-push a branch, so individual commits can have their messages edited before a branch is merged. I would much rather see code review enforcing good commit messages, which is a workflow that contributors to any other open source project will be familiar with. I fail to see any benefit in having ChangeLog entries. Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file that captures high-level user-visible improvements. We don't necessarily need PR authors to write that, but the person merging a PR probably should if not. This is far less granular than a commit message and serves a separate purpose. David On 05/04/2020 21:49, Fred Kiefer wrote: Thank you Ivan for the great work you are doing here. And I promise to try to lighten the work on the next release by making sure every pull request gets it proper ChangeLog entry. Fred Am 05.04.2020 um 22:42 schrieb Ivan Vučica : I have cut new releases: - gnustep-make 2.8.0 - gnustep-base 1.27.0 - gnustep-gui 0.28.0 - gnustep-back 0.28.0 They've been pushed to GitHub as commits and signed-tags, signed using GPG key of yours truly. The signed tags, interpreted as releases by GitHub, have been marked as 'prerelease', and tarballs + GPG signatures made using the maintainer key have been attached to them. https://github.com/gnustep/tools-make/releases/make-2_8_0 https://github.com/gnustep/libs-base/releases/base-1_27_0 https://github.com/gnustep/libs-gui/releases/gui-0_28_0 https://github.com/gnustep/libs-back/releases/back-0_28_0 As a temporary download URL, they're also available at https://badc0de.net/gs/2020/ for anyone who does not use GitHub. Please, have a go at them, and let me know if there are any critical issues. Please particularly review ANNOUNCE files as these will customarily go out to info-...@gnu.org. ANNOUNCE files should be the same ones that have been committed into our Git repositories. Please validate .sig files in case I made a mistake; that would be rather embarrassing. If there are none, one of the evenings next week I will: - upload tarballs to the default distribution point at ftp.gnustep.org - flip the 'prerelease' bit on GitHub - send ANNOUNCE emails to info-...@gnu.org and to discuss-gnus...@gnu.org as was done for previous releases. Thank you everyone for your work! While preparing these was a lot of work, I am also impressed by the amount of changes all across the board: tons of new classes, tons of work on Android; very very impressive amount of changes.
