On Wed, Sep 20, 2017 at 8:58 AM <mcatanz...@gnome.org> wrote: > On Wed, Sep 20, 2017 at 4:50 AM, Allan Day <a...@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. >
_______________________________________________ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
