On Thu, Jan 14, 2021 at 11:04 am, Bastien Nocera <had...@hadess.net>
wrote:
I don't think you quite understand just how much trust was lost when a
member of the release team can't follow the goals we set ourselves as
a
project.
You broke that trust, then bumbled into breaking it again, fixed the
code, but never actually cleaned up after yourself (see below).
There's no putting back together that broken trust. And I'm likely not
going to be able to trust the release-team's work until there's a
technical means to avoid the sort of breach of trust that just
happened.
There was nothing to deescalate, it was already too late.
Hi Bastien,
The release team has been discussing how to handle build breakage
situations better in the future. Our proposal is that we will create
MRs for any build fixes and wait at least 24 hours for maintainers to
review them before merging. (This does not apply to modules that
disable merge requests.)
24 hours are probably not enough time for every maintainer to respond
to a merge request, but we are not comfortable with having modules
failing to build for extended periods of time. GNOME components are
interconnected and GNOME can only be successful if we work together to
keep the whole thing building. We hope you can overlook issues like
suboptimal commit messages in build fix MRs if you are not able to
respond to a build failure within that timeframe.
If you would like to completely opt-out of release team pushing to your
modules, we can change your module's buildstream element to build from
a tarball instead. That will guarantee that changes in your module's
git repo will not cause any build failures, and therefore will not
attract any unwanted commits from release team.
Michael
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
