Re: Can we enforce beta release for the freeze

[Michael Catanzaro <mcatanzaro gnome org>]

FWIW I agree that freeze should apply to tarballs, i.e. any features or 
UI changes not in a tarball release by the beta tarball deadline ought 
to be delayed until the next release cycle. Dropping major changes a 
week later isn't fair to Shaun and anyone else working on 
documentation. But that's pretty harsh.

On the other hand, a solution that requires cloning Georges is not 
really a solution....

On Tue, Feb 23, 2021 at 1:53 pm, Emmanuele Bassi via desktop-devel-list 
<desktop-devel-list gnome org> wrote:
> In the end, though, releases are manual labour; only the maintainer 
> can say: "okay, this is good enough for other people to use" (where 
> "people" defines different audiences depending on the stage of the 
> development cycle). No amount of automation is going to solve that 
> because if it did we would not need per-project maintainers in the 
> first place, and we would only need people reviewing code and 
> pressing the "Merge" green button.

Wellll...

I think we *could* automatically tag the .alpha .beta .rc and .0 
tarballs, since I expect these to be created at specific predetermined 
times regardless of whether the code is "ready" or not. This would 
solve Shaun's problem. It would require a bunch of infrastructure work, 
though. We would lose manually-written NEWS files. But automation would 
probably not be able to handle library versioning, like libtool C:R:A 
or the meson equivalent, so maintainers would need to handle that 
manually in advance.

For stable releases after .0, I agree only a human can judge when a 
release is required.