On Wed, Sep 20, 2017 at 4:50 AM, Allan Day <aday gnome org> wrote:
> Extend the UI freeze (or create a freeze period for major UI changes)
> and require that breaks get design approval.
What would extending the freeze accomplish? We already have a long UI
freeze (five weeks). Wouldn't extending the freeze just make it harder
to land changes? In general, we've been operating under the assumption
that making freeze breaks easy to obtain will usually result in a
higher-quality release, so I'm surprised by the request to make it
harder to get a freeze break.
I don't understand how that would make it harder to land changes? Unless you are saying that something else gets shorter because we are extending the freeze? I am in favor of moving release dates to accommodate changes if they are of high value to the community and to our reputation. Speaking as an engagement person of course.
Why should UI freeze breaks require design approval? I'm not aware of
any instance of us approving a freeze break that introduced a
controversial design change. Do you have an example of a freeze break
I think it is because design time is limited as Allan mentioned above. They had to scramble and review design changes and thus other projects didn't get the design review they could have gotten.
that you wish we had not approved? I think it's reasonable to require
design team approval if you want to add this requirement, but there is
no design mailing list so designers will have to follow the
release-team list if we take this route. I'm not sure it will really be
beneficial, though: I suspect you'll find yourself needing to approve a
bunch of pretty mundane requests, and adding another point of failure
will probably not please module maintainers.
Maybe not a hard and fast rule. I think we can apply common sense here. Most of us know what is a non-trivial UX change is and what is a small one off.
> Give marketing a say in whether UI freeze breaks are accepted. (And
> find someone other than me to take responsibility for this!)
Is this in reference to the nautilus freeze break request? I don't
think we want to allow major UI changes late in the cycle just because
it would make the release notes more interesting. This is the only
recent case that I remember of a UI freeze break being denied: in
general, it's quite easy to get a freeze break because you only have to
convince two release team members. In this case, it was a pretty clear
"no" IMO because it required lots of new code but was not at all
urgent: exactly the sort of thing that should be stabilized over the
course of the next cycle.
I think it is more about what is the impact on community or users. It is what allows us determine if we should reject something. I'm happy to look at it if someone requests me to do it.
The other case that went badly this cycle was the transparency freeze
break request. I think this was a combination of you taking time off at
an awkward point right after making the request, leaving nobody to
ensure it was actually implemented, and possible confusion due to
Mathias not liking the request and due to me forgetting that Andre had
given his approval (conditional on docs team's approval, which came
from Sean). I wrote a mail saying that another approval was required,
when in fact you already had the two required approvals if we count
Andre's. But none of the gnome-shell developers actually followed up on
the request or implemented the change. I think this was mainly a
coordination issue rather than an actual issue with our process.
Yeah, that could have gone better. Sadly, too many things came altogether at once. Lesson learned. I think we can revert back in the .1 release. Although now it is out there. One thing we need to keep in mind now is that the delta between when GNOME releases and when it gets into the hands of users is now a lot smaller. That means, that impact is that much more than it has been when users upgrade a couple months later.
> Make sure that JHBuild isn't broken, particularly around release time.
Unfortunately some module maintainers do not use JHBuild, and so do not
notice if their module is broken. E.g. gnome-shell has been broken for
ages to the point where there is no way anybody could possibly build it
(some core-dep is at too low a version, I forget exactly what), and
I've gotten bored of fixing such hugely obvious problems when module
maintainers don't. I do make sure that the release modulesets always
build on my computer for the releases that I make, but those are
tarball modulesets that are different from what developers use. E.g. in
the gnome-shell case, there was a dependency branch in the master
branch of some module, which has not been released yet, so the release
modulesets are fine.
We need to stop using JHbuild and move to Continuous. It's high time that we start moving to a continuous integration service not using jhbuild for everything. At this stage of the game, having breakages creates difficulties that can be easily avoided.
We do have a technical solution to this: replace JHBuild with
BuildStream. Tristan has continuous integration for BuildStream already
working, so such build failures will not go undetected and unfixed
anymore. Hopefully we will not be using JHBuild anymore at all by the
end of this release cycle. I wonder how the efforts to switch our
release infrastructure to BuildStream are progressing.
I would approve of anything that would make this situation better.
sri
Michael
_______________________________________________
release-team gnome org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.
