Hi all, and long time no see, hope everyone is doing well...
On Tue, 2021-02-23 at 08:37 -0600, Michael Catanzaro wrote:
[...]
> On Tue, Feb 23, 2021 at 1:53 pm, Emmanuele Bassi via desktop-devel-list
> 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.
>
> We...
>
> 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.
I think this is a wonderful idea, I've been toying with something
similar for years now, I never ended up taking it to d-d-l as I did not
get much traction from within the release team yet.
>From my perspective, the main pain point that I would like to solve, is
that we are not running integrated builds of the same software we end
up releasing, if we were releasing the same thing we were running
integrated builds of, then we would obviously have much less issues at
release time.
Bringing releases inline with regular CI throughout the cycle would
also make actual integration work more meaningful (i.e. work like
testing pam setups for gnome-keyring, getting the ibus working
properly, ensuring the GOA stuff is all working, etc).
As this topic came up, I'll try to throw up a tentative outline of how
I think this could work.
* We would need to support opting in and opting out of this.
For maintainers who want to keep manually tagging and releasing
tarballs, we would only ever build tarballs for those in the
integrated builds.
Those maintainers are responsible for updating the tarball
references in gnome-build-meta every time they release a tarball.
Some policy would need to be drawn up on what happens when
introducing an updated tarball of your platform library into the
build causes the overall GNOME build to break.
* For maintainers who opt in to the automation (which I would think
would have to be more than 80%, ideally 95%, for this approach to
be worthwhile), we would enforce a GNOME-wide standard release tag
nomanclature.
* Maintainers would be responsible for updating the `track` reference
in gnome-build-meta for the active release cycle.
With something like this, the release builds would just track the
latest of every maintainer chosen branch at the time of release, and
tag the modules which have changed in any way since the last release
tag - tagging the module would result in automatically also generating
a tarball and publishing it (possibly without any NEWS updates as
Micheal pointed out) - the tarballs are only generated for the
convenience of certain downstreams which still want to consume them.
> For stable releases after .0, I agree only a human can judge when a
> release is required.
Once the first stable release is out, there are different ways we can
handle things, but I don't think that it is entirely necessary to have
the maintainer decide when to make a stable release of their modules -
if any new commits are available on the active stable branch listed in
the corresponding gnome-build-meta stable branch, they will be included
in the next stable release and a release will be made for them
automatically (tag + tarball published).
Instead, if there are critical security patches which need to go out on
a module in a stable series, the maintainer can just request that the
release team make an additional releases for that exception (if the
automation is good, this should not require effort on the part of the
release team anyway).
There are surely risks and downsides, like ensuring libtool versioning
bumps happen correctly, and ensuring good enough communication (such
that we select the correct branches for CI at the *beginning* of a new
cycle as well as when the freezes start), but in general I think this
would be a good avenue to pursue and would be happy to lend a hand
where I can to help us get there.
Cheers,
-Tristan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
