Closed Feichtmeier closed 6 years ago
@Feichtmeier Do you think there is time to fix this and push a freeze exception?
Can the same be applied here:
I have time for sure. I am still confused by these UIFe I thought we passed this UIFe deadline last Monday? @didrocks please enlighten me and sorry for being slow again
UIF is passed for a long time already, have a look at the calender (that I linked many times btw…): https://wiki.ubuntu.com/CosmicCuttlefish/ReleaseSchedule. We requested for an UIFe (https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions), which is a one time grand to "break" the exception (read the wiki page again that I linked: https://wiki.ubuntu.com/UserInterfaceFreeze).
We did the upload corresponding with the UIFe content last Monday, before beta. I hope this time, I won't get asked once more what the UIF process is TBH, I'm under the impression to have linked those pages a lot of times and they weren't read, hence your confusion. :/
However, we can still do some small uploads with fixes until Final Freeze (see the release schedule). I think we should aim making a final Yaru upload next Wednesday, just before Final Freeze. Those uploads (since FF and UIF) are for bug fixes only (and so, very minor changes, which won't really impact documentation). I suggest this particular fix is one of those and can be merged thus, without an UIFe.
@didrocks I did read it but why does it need less hassle to merge AFTER a freeze point than before? This just doesn't make sense to me.
Pre freeze date xyz: Merge what you like Post freeze date xzy: Make request with a big why report Two weeks later: Merge without the report again
???
Because this is considered a bug fix
No, you didn't understand me :/
Pre freeze date xyz:
Merge what you like
The above is correct ^
Post freeze date xzy:
* Make request with a big why report *if there a noticeable UI change* (see the wiki page on what qualifies as an UIF breakage)
* For fixes (changes we can't really notice if I give you 2 screenshots), merge as before
And we are here, and that PR is considered as a fix.
Thanks @madsrh! I'm not as unclear thus ;)
Well in my "other" job we have those freeze points too.
But even a bug fix needs these big talks. So it's not like this is the only way in the universe to handle this. Thus I don't understand your behaviour, sorry.
Not in ubuntu until Final Freeze, which is the starting point where every uploads needs to be lenghtly discussed as the goal is to converge to a finale working iso.
(then, once release, it's another process, but same idea: only bug fixes, with a test case for every issues to check that a fix is correct). Everything is linked in the release schedule wiki page I linked.
Aha ok Then I PR this later
Thanks!
@Feichtmeier: on your comment you removed about this being unlogical versus code safety.
We are not talking about crashers, here, but taking again definition of https://wiki.ubuntu.com/UserInterfaceFreeze:
The user interface must be stabilized at some point, so that documentation writers and translators can work on a fixed target that doesn't obsolete screenshots or documentation.
-> It's about what can you notice in the documentation or screenshot that changes? The icon to start an application can be confused versus documentation. A simple "highlight" selector is not that noticeable.
Restarting the test since several dozen times. When it made it I tag you guys to test the snap
Seems there is a build failure due to gtk-common-themes, looking at it…
@Feichtmeier Ok, it worked, please merge your branch with master to get the fix, then, it should pass again (apart if we get other snaprevs udpate fails).
Something like this