Freeze break request for gnome-shell

[Florian Müllner]

Hey,

unlike any other password dialogs in gnome-shell, the new network
dialogs have a switch to reveal the password. However, the solution has
been deemed insufficient by the design team, so I'd like to request
permission to remove it (bug 658948).

Thanks for your consideration,
Florian

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

Hey,

I'd like to request a freeze break for the following bug:
https://bugzilla.gnome.org/show_bug.cgi?id=659827

A recent commit broke menu items under certain circumstances when run in
an RTL locale - a known case is the user's name in the user menu, which
does not show up at all in RTL locales. The fix is small and low-risk,
and fixes a very visible problem for some users.

Regards,
Florian

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

There is a problem with the new shell keyring dialogs, as demonstrated in
this[0] video. The proper fix in bug 672543[1] is small but intrusive, so
for the 3.4 release, I am proposing a safe workaround instead. It consists
of giving checkbox labels a fixed height of two lines of text - as the
widget is only used in keyring dialogs, no other UI is affected. A height
of two lines should work correctly for most locales - for translations that
are significantly shorter than English, there'll be some additional
whitespace, for translations that are significantly longer (as far as I can
tell, only Spanish is affected (yeah, German translation is missing ;-)),
the last words will be cut off (we might consider using a height of three
lines instead to only ever err on the safe side).

The change does not affect either documentation or translations.


Regards,
Florian


[0] https://bugzilla.gnome.org/show_bug.cgi?id=652459#c13
[1] https://bugzilla.gnome.org/show_bug.cgi?id=672543
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

freeze break request for gnome-shell

[Matthias Clasen]

 See https://bugzilla.gnome.org/show_bug.cgi?id=684459
I'd like to get a very small patch committed.

It addresses a problem related to user switching. When clicking the
'Switch user' menuitem, we switch vts, which causes the shell to stop
whatever it is doing. When we later switch back, the screen has been
locked (ie the shield is down), but the user menu is still showing -
on top of the shield, and over at the other edge of the screen. This
is very noticable (people will be playing with the shiny new lock
screen and discover it), and arguably some sort of privacy leak.

The patch makes a simple change: unpost the menu before initiating the
vt switch.

I already gave my +1 in the bug, looking for a second approval here.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for GNOME Shell

[Florian Müllner]

Hey,

looks like I have to request another UI freeze break for GNOME Shell :-)

https://bugzilla.gnome.org/show_bug.cgi?id=685201 is about a UI glitch
in the login screen that was accidentally introduced when updating the
lock screen style. Rather than just fixing the glitch in question, we
think it makes sense to slightly change the layout and thereby bring
it closer to the lock screen (and design mockups) - the change boils
down to moving the password entry from its current position next to
the user's avatar to a new one below avatar / username as in the lock
screen[0].

Thanks,
Florian


[0] http://people.gnome.org/~fmuellner/Login%20Screen%20update.png
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Cosimo Cecchi]

Hi all,

This cycle we redesigned the Shell overview, hiding the message tray by
default from the view.
The original design also added a new messages indicator to make the tray
more discoverable, but it didn't make it in time for 3.7.90. Bug 687797 [1]
contains a patchset that adds the indicator.
Patches have been reviewed already and the request comes from the design
team. OK to commit this?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=687787

Thanks,
Cosimo
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for GNOME Shell

[Florian Müllner]

Oh my, it's this time of the year again ...

When the new status menu work landed, the "Notification" switch that
used to be in the user menu was removed, although according to the
mockups[0] it should be included in the message tray menu - I'd like
to land this[1] now for 3.10.1.

At this point in time, this constitutes both a UI and string freeze
break, though it restores functionality that has been around for quite
some time (3.4?) and was only removed late this cycle, so I suspect
that there are translations/documentation that can be resurrected.


Cheers,
Florian

[0] https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
[1] https://bugzilla.gnome.org/show_bug.cgi?id=707073
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Piñeiro]

This bug:
https://bugzilla.gnome.org/show_bug.cgi?id=736821

makes gnome-shell mostly inaccessible. The fix is trivial, and was
already reviewed and accepted by gnome-shell developers.

Andre already give a 1/2 from release team on the bug. I could do the
same, but I guess that it would be strange to give a release-team vote
on an own bug.

Best regards

-- 

Alejandro Piñeiro

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

Hey,

I'd like to request a freeze break for bug
https://bugzilla.gnome.org/show_bug.cgi?id=736910. When opening an
empty folder in the app picker, the shell ends up in a confused state
- there is no folder popup, but icons are faded out and become
non-reactive to clicks as if a folder had been opened. It is possible
to get back to a normal state again (either by closing the app picker
or by opening a "proper" app folder), but the behavior is clearly and
obviously broken.
The proposed patch avoids this issue in a very simple way - there is
nothing users can do with empty app folders, so there's no reason to
show them in the first place. The patch to hide folders in that case
is a simple one-line patch.


-- Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

Hey folks,

I'm sorry I didn't catch this before the freeze. It turns out gnome-shell's
extension-prefs tool is another victim of GTK+'s ScrolledWindow changes
this cycle:

https://people.gnome.org/~fmuellner/Extension-prefs-nay.png

The trivial patch in https://bugzilla.gnome.org/show_bug.cgi?id=771391
restores its intended look again:

https://people.gnome.org/~fmuellner/Extension-prefs-yay.png

Thanks,
Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

Hey,

I'm sorry to ask for yet another break. We finally fixed the
'cycle-windows' shortcut this cycle (that is, switching between windows
without showing a switcher popup - alt+esc by default). It's not a
super-common feature, which is probably why we didn't catch these before:

https://bugzilla.gnome.org/show_bug.cgi?id=771536

To sum up the bug:
When using the shortcut with hidden windows, those windows are not only
shown temporarily, but stick around as "ghosts" after the operation
finishes (the windows are visible, but cannot be interacted with). This is
very clearly broken, so I'm hoping for a freeze break for at least the
first two patches which address this issue (the first makes a mutter
function available to gnome-shell, the second uses that function to get the
correct visibility).

The two remaining patches fix glitches when selecting a hidden window - it
is odd to switch to a window and have it disappear briefly before animating
back in, so I would still like to see an exception for them as well. Those
glitches only show up temporarily during the finishing animation though, so
fixing them isn't quite as urgent as the first issue (in case you'd rather
keep that part for .1)

Cheers,
Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

Hey everyone,

I'd like to land some improvements to the date+time drop-down before
entering beta. The bugs in question are:

 * https://bugzilla.gnome.org/show_bug.cgi?id=754031
   which adds weather information according to the location configuration
   from gnome-weather. This has been fairly high on the wishlist for a while
   (at least since 3.16), so I'm sure this will be a very welcome addition
   (and I'm sorry I only found time recently to finish up the patches)

  Note to translators:
   There's a big patch that adds non-capitalized versions of
libgweather's condition
   strings. We will not land this, so there'll be a moderate eight additions.


 * https://bugzilla.gnome.org/show_bug.cgi?id=775763
   which streamlines the notification area's visuals according to Allan's latest
   mockups - see
https://blogs.gnome.org/aday/2016/12/13/improving-notifications-in-gnome/

For reference, this is what the result looks like:
https://people.gnome.org/~fmuellner/gnome-shell-calendar-refresh.png

In my opinion, both items make for some nice polish improvements in
that area with low risk (the weather section is very isolated, and the
visual refresh is mostly a style update), so they would make for a
good (while late) 3.24 addition.

Cheers,
Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

Hey,

I'm not entirely sure whether this is freeze-break worthy considering
that the issue is partly cosmetic, but it has been annoying for long
enough to try :-)

Last cycle gjs added a warning for JS code that accesses objects that
are being destroyed, resulting in plenty of "invalid access" warnings
in the journal (I'm sure you've seen them!)

We've had

  https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/4

for a while to address this, but it's still stuck in review because
one of the patches is still contended.

In order to get at least some progress on the issue, I asked to split
out the patch still under discussion, so now we have

  https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/209

to land the gros of the patches that have been accepted months ago.
I'm sorry this leaked into the hard-code freeze period, landing
patches piece-wise isn't gitlab's strength :shrug:

Cheers,
Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[verdre]

Hi,

I'd like to request a freeze break for MR 207, it contains a fix for the 
issues with oversized titles in the overview appearing when using Wayland.


The changes have been split out of the larger MR 136 which didn't get 
enough reviews to be merged in time.


https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/207

Thanks a lot,
verdre
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for GNOME Shell

[Florian Müllner]

Hey,

I'd like to request a freeze break for a crash introduced by the
fractional scaling support that landed in 3.31.92:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/450

The particular case in the bug report are "Foo-bar is now ready"
notifications for windows with no .desktop file, but it's entirely
possible for extensions to trigger the same assertion.

The merge request only fixes the issue properly for the reproducer we
have in gnome-shell, but at least the crash will be addressed for
everyone (there'll be empty icons instead). In particular on wayland
where we bring down the whole session, this should be an acceptable
drawback :)

Thanks for the consideration,
Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request for gnome-shell

[Florian Müllner]

Hey everyone!

This is embarrassing, but since a minor IO optimization in 3.35.92,
dates in gnome-shell are now off by 1900 years.

I would rather not stay in the year 120 until 3.36.1 is released, so
I'd like a freeze break exception for the following fix:

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1061

The change is trivial (replace getYear() with getFullYear()) and safe,
and addresses a quite visible bug.

Regards,
Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Andre Klapper]

On Mon, 2011-09-19 at 15:23 +0200, Florian Müllner wrote:
> unlike any other password dialogs in gnome-shell, the new network
> dialogs have a switch to reveal the password. However, the solution has
> been deemed insufficient by the design team, so I'd like to request
> permission to remove it (bug 658948).

1st OK from release-team, if docs team is fine with this.

andre
-- 
mailto:ak...@gmx.net | failed
http://blogs.gnome.org/aklapper | http://www.openismus.com

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Luca Ferretti]

011/9/19 Florian Müllner 

> Hey,
>
> unlike any other password dialogs in gnome-shell, the new network
> dialogs have a switch to reveal the password. However, the solution has
> been deemed insufficient by the design team, so I'd like to request
> permission to remove it (bug 658948).
>
>
It's a -1 from me. A small visual incoherence is better then feature
regression. Better wait 3.4 for a proper solution.
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Florian Müllner]

On lun, 2011-09-19 at 15:39 +0200, Luca Ferretti wrote:
> 
> It's a -1 from me. A small visual incoherence is better then feature
> regression. Better wait 3.4 for a proper solution.

I'm less worried about visual incoherence here, but rather about wrong
usage of the switch widget[0], which might get picked up by application
authors.
(Quoting from #gnome-design: "the switch suggests that it's a global
thing - that it'll affect all password fields")

Regards,
Florian

PS: With regard to the feature regression, see bug 659275


[0] https://live.gnome.org/Design/Whiteboards/SwitchGuidance

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Luca Ferretti]

2011/9/19 Florian Müllner 
>
> On lun, 2011-09-19 at 15:39 +0200, Luca Ferretti wrote:
> >
> > It's a -1 from me. A small visual incoherence is better then feature
> > regression. Better wait 3.4 for a proper solution.
>
> I'm less worried about visual incoherence here, but rather about wrong
> usage of the switch widget[0], which might get picked up by application
> authors.
> (Quoting from #gnome-design: "the switch suggests that it's a global
> thing - that it'll affect all password fields")
>
> Regards,
> Florian
>
> PS: With regard to the feature regression, see bug 659275

Yes, I know the isseu you could have trying to type an unknown long
password for a brand new wireless network, that's the reason I like to
keep a way to show that password.
If the switch is really an issue, may I suggest another (improper, I
know) solution?

 ( Cancel )( Show Password )  ( Connect )

that will change to

 ( Cancel )( Hide Password )  ( Connect )

once clicked
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

On Mon, Sep 19, 2011 at 10:00 AM, Florian Müllner  wrote:
> On lun, 2011-09-19 at 15:39 +0200, Luca Ferretti wrote:
>>
>> It's a -1 from me. A small visual incoherence is better then feature
>> regression. Better wait 3.4 for a proper solution.
>
> I'm less worried about visual incoherence here, but rather about wrong
> usage of the switch widget[0], which might get picked up by application
> authors.

And I assume we don't have checkboxes for shell dialogs...:-(

I am not too worried about the 'feature' that we are temporarily losing here.
I assume we can get context menus (and thus the ability to show
passwords) in 3.2.1, Florian ?
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Frederic Peters]

Luca Ferretti wrote:

> 011/9/19 Florian Müllner 
> 
> > Hey,
> >
> > unlike any other password dialogs in gnome-shell, the new network
> > dialogs have a switch to reveal the password. However, the solution has
> > been deemed insufficient by the design team, so I'd like to request
> > permission to remove it (bug 658948).
> >
> >
> It's a -1 from me. A small visual incoherence is better then feature
> regression. Better wait 3.4 for a proper solution.

It's quite minor, in most cases the password will be saved, and with
some luck we will have context menus in shell entries in 3.2.1, I'll
give my +1 on this one.


Fred
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Florian Müllner]

On mar, 2011-09-20 at 16:30 -0400, Matthias Clasen wrote:
> I am not too worried about the 'feature' that we are temporarily losing here.
> I assume we can get context menus (and thus the ability to show
> passwords) in 3.2.1, Florian ?

The code is awaiting review and not overly complicated, so I'm
optimistic for 3.2.1.

Florian

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Andre Klapper]

On Thu, 2011-09-22 at 15:57 +0200, Florian Müllner wrote:
> I'd like to request a freeze break for the following bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=659827
> 
> A recent commit broke menu items under certain circumstances when run in
> an RTL locale - a known case is the user's name in the user menu, which
> does not show up at all in RTL locales. The fix is small and low-risk,
> and fixes a very visible problem for some users.

r-t approval 1/2.

andre
-- 
mailto:ak...@gmx.net | failed
http://blogs.gnome.org/aklapper | http://www.openismus.com

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

On Thu, Sep 22, 2011 at 10:20 AM, Andre Klapper  wrote:
> On Thu, 2011-09-22 at 15:57 +0200, Florian Müllner wrote:
>> I'd like to request a freeze break for the following bug:
>> https://bugzilla.gnome.org/show_bug.cgi?id=659827
>>
>> A recent commit broke menu items under certain circumstances when run in
>> an RTL locale - a known case is the user's name in the user menu, which
>> does not show up at all in RTL locales. The fix is small and low-risk,
>> and fixes a very visible problem for some users.
>
> r-t approval 1/2.

2/2
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Colin Walters]

On Thu, 2011-09-22 at 15:57 +0200, Florian Müllner wrote:
> Hey,
> 
> I'd like to request a freeze break for the following bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=659827

Approval 2/2

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Javier Jardón]

On 13 October 2011 15:03, Florian Müllner  wrote:
> So I'd like to request a UI freeze break for the addition of context
> menus (screenshot attached) and a string freeze break for the four
> strings introduced in the patch ("Copy", "Paste", "Show Text", "Hide
> Text").

+1 from me, thanks for complete this for 3.2.1

-- 
Javier Jardón Cabezas
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Shaun McCance]

On Thu, 2011-10-13 at 16:03 +0200, Florian Müllner wrote:
> On mar, 2011-09-20 at 16:30 -0400, Matthias Clasen wrote:
> > On Mon, Sep 19, 2011 at 10:00 AM, Florian Müllner  
> > wrote:
> > > On lun, 2011-09-19 at 15:39 +0200, Luca Ferretti wrote:
> > >>
> > >> It's a -1 from me. A small visual incoherence is better then feature
> > >> regression. Better wait 3.4 for a proper solution.
> > >
> > > I'm less worried about visual incoherence here, but rather about wrong
> > > usage of the switch widget[0], which might get picked up by application
> > > authors.
> > 
> > And I assume we don't have checkboxes for shell dialogs...:-(
> > 
> > I am not too worried about the 'feature' that we are temporarily losing 
> > here.
> > I assume we can get context menus (and thus the ability to show
> > passwords) in 3.2.1, Florian ?
> 
> I'm not sure everyone is aware, but Owen was uncomfortable with the
> feature regression, so I backed out for 3.2 despite release team
> approval. I'm bringing it up again for 3.2.1, as the context menu patch
> is now ready to land[0] (but obviously requires another freeze break).
> 
> So I'd like to request a UI freeze break for the addition of context
> menus (screenshot attached) and a string freeze break for the four
> strings introduced in the patch ("Copy", "Paste", "Show Text", "Hide
> Text").

It doesn't appear we mention the switch in the help, so this won't
invalidate anything. I would like to add a note about right-clicking
to see the password to step 2 in net-wireless-connect.page. I can't
do that now, because gnome-user-docs is frozen for 3.2.1.

I'll give a docs team approval, with the understanding that we won't
add the note in the help until 3.2.2.

--
Shaun


___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Shaun McCance]

On Thu, 2011-10-13 at 16:03 +0200, Florian Müllner wrote:
> On mar, 2011-09-20 at 16:30 -0400, Matthias Clasen wrote:
> > On Mon, Sep 19, 2011 at 10:00 AM, Florian Müllner  
> > wrote:
> > > On lun, 2011-09-19 at 15:39 +0200, Luca Ferretti wrote:
> > >>
> > >> It's a -1 from me. A small visual incoherence is better then feature
> > >> regression. Better wait 3.4 for a proper solution.
> > >
> > > I'm less worried about visual incoherence here, but rather about wrong
> > > usage of the switch widget[0], which might get picked up by application
> > > authors.
> > 
> > And I assume we don't have checkboxes for shell dialogs...:-(
> > 
> > I am not too worried about the 'feature' that we are temporarily losing 
> > here.
> > I assume we can get context menus (and thus the ability to show
> > passwords) in 3.2.1, Florian ?
> 
> I'm not sure everyone is aware, but Owen was uncomfortable with the
> feature regression, so I backed out for 3.2 despite release team
> approval. I'm bringing it up again for 3.2.1, as the context menu patch
> is now ready to land[0] (but obviously requires another freeze break).
> 
> So I'd like to request a UI freeze break for the addition of context
> menus (screenshot attached) and a string freeze break for the four
> strings introduced in the patch ("Copy", "Paste", "Show Text", "Hide
> Text").

Just to be sure: We're only talking about gnome-shell's password prompt
here, and not the password entry on the Wireless Security tab when you
edit a connection, right?

--
Shaun


___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Florian Müllner]

On jue, 2011-10-13 at 13:09 -0400, Shaun McCance wrote:
> Just to be sure: We're only talking about gnome-shell's password prompt
> here, and not the password entry on the Wireless Security tab when you
> edit a connection, right?

Right.

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Johannes Schmid]

Hi!

I think we discussed that already for the original break request, so 1
of 2 from i18n.

Regards,
Johannes

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Gabor Kelemen]

2011-10-13 21:20 keltezéssel, Johannes Schmid írta:

Hi!

I think we discussed that already for the original break request, so 1
of 2 from i18n.


Important enough for me, i18n approval 2/2.

Regards
Gabor Kelemen
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

In case it is still needed, I'm fine with these changes, second
release team approval.
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

On Mon, Mar 26, 2012 at 6:45 AM, Florian Müllner  wrote:
> There is a problem with the new shell keyring dialogs, as demonstrated in
> this[0] video. The proper fix in bug 672543[1] is small but intrusive, so
> for the 3.4 release, I am proposing a safe workaround instead. It consists
> of giving checkbox labels a fixed height of two lines of text - as the
> widget is only used in keyring dialogs, no other UI is affected. A height of
> two lines should work correctly for most locales - for translations that are
> significantly shorter than English, there'll be some additional whitespace,
> for translations that are significantly longer (as far as I can tell, only
> Spanish is affected (yeah, German translation is missing ;-)), the last
> words will be cut off (we might consider using a height of three lines
> instead to only ever err on the safe side).
>
> The change does not affect either documentation or translations.
>
>
> Regards,
> Florian
>
>
> [0] https://bugzilla.gnome.org/show_bug.cgi?id=652459#c13
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=672543
>

2 or 3 lines sounds safe to me, and this bug is a pretty visible wart
in a new feature. So, approval 1 for the release team.
___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Andre Klapper]

On Mon, 2012-03-26 at 08:07 -0400, Matthias Clasen wrote:
> On Mon, Mar 26, 2012 at 6:45 AM, Florian Müllner  wrote:
> > There is a problem with the new shell keyring dialogs, as demonstrated in
> > this[0] video. The proper fix in bug 672543[1] is small but intrusive, so
> > for the 3.4 release, I am proposing a safe workaround instead. It consists
> > of giving checkbox labels a fixed height of two lines of text - as the
> > widget is only used in keyring dialogs, no other UI is affected. A height of
> > two lines should work correctly for most locales - for translations that are
> > significantly shorter than English, there'll be some additional whitespace,
> > for translations that are significantly longer (as far as I can tell, only
> > Spanish is affected (yeah, German translation is missing ;-)), the last
> > words will be cut off (we might consider using a height of three lines
> > instead to only ever err on the safe side).
> >
> > The change does not affect either documentation or translations.
> >
> >
> > Regards,
> > Florian
> >
> >
> > [0] https://bugzilla.gnome.org/show_bug.cgi?id=652459#c13
> > [1] https://bugzilla.gnome.org/show_bug.cgi?id=672543
> >
> 
> 2 or 3 lines sounds safe to me, and this bug is a pretty visible wart
> in a new feature. So, approval 1 for the release team.

Approval 2 of 2 if the proper patch gets applied soonish after the 3.4.0
tarball.

andre
-- 
mailto:ak...@gmx.net | failed
http://blogs.gnome.org/aklapper

___
release-team@gnome.org
http://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

UI freeze break request for gnome-shell

[Giovanni Campagna]

Hello release team,

I'm requesting a UI freeze break for the following bug:
https://bugzilla.gnome.org/show_bug.cgi?id=682285
(only the two patches marked accepted-commit_now are significant, the
rest are dubious code cleanups)

The scope of the bug is to replace the arrow handle in the screen lock
curtain with an animation that makes it clear the curtain is meant to
be lifted up with a mouse or touch gesture.

Screenshot before:
https://dl.dropbox.com/s/wu4iv9w5avl33ry/lock-screen-before.png
Screenshot after: https://dl.dropbox.com/s/wlo6o1ny5urelkn/lock-screen-after.png
(The second screenshot is hopefully usable as-is for release notes and
documentation, as taking it required careful timing and a good amount
of luck)

Thanks in advance,

Giovanni
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

UI freeze break request for gnome-shell

[Giovanni Campagna]

Hello release team,

As promised, I'm here again with another request for UI freeze break.
This time, it's about https://bugzilla.gnome.org/show_bug.cgi?id=682544
What it does is replacing the "Authentication failed" banner
notification on password failure, as well as other PAM messages, in
gdm and in the unlock dialog with an orange prompt below the entry, in
the style of the mockup at
https://github.com/gnome-design-team/gnome-mockups/raw/master/system-lock-login-boot/authentication-failure.png
, except without the icon.
The feature is listed in the BoF page at priority 0 for the login dialog.
I had this prepared for 3.5.91, but a required gdm change appeared
after gnome-shell 3.5.91 was released, so this won't make it, unless a
3.5.91.1 is released.

Thanks in advance

Giovanni
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

String freeze break request for gnome-shell

[Giovanni Campagna]

Hello release team, hello translators,

I'd like to break the string freeze for gnome-shell for bug
https://bugzilla.gnome.org/show_bug.cgi?id=683060. The main part of it
is already solved, what is left out is handling DBus errors that might
happen even if GDM is available and the right version.
There is only one string, "Authentication error", and in the normal
case it should be never shown to the user. In fact, I've never
experienced such problems myself, but
https://bugzilla.gnome.org/show_bug.cgi?id=684172 tells me otherwise.
Without the patch, the shell is left with a broken greeter (half
animated avatar, no prompt) or unlock dialog (full grey screen). With
the patch, "Authentication error" is shown for a few seconds under the
entry (in the same place as "Authentication failed"), and the greeter
is reset or the lock screen curtain falls down again.

Thanks in advance,

Giovanni
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: freeze break request for gnome-shell

[Frederic Peters]

Matthias Clasen wrote:

> I already gave my +1 in the bug, looking for a second approval here.

+1.

Fred
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[Matthias Clasen]

On Fri, Oct 5, 2012 at 11:52 AM, Florian Müllner  wrote:
> Hey,
>
> looks like I have to request another UI freeze break for GNOME Shell :-)
>
> https://bugzilla.gnome.org/show_bug.cgi?id=685201 is about a UI glitch
> in the login screen that was accidentally introduced when updating the
> lock screen style. Rather than just fixing the glitch in question, we
> think it makes sense to slightly change the layout and thereby bring
> it closer to the lock screen (and design mockups) - the change boils
> down to moving the password entry from its current position next to
> the user's avatar to a new one below avatar / username as in the lock
> screen[0].

Sorry you didn't get any reply to this yet. It looks fine to me and
moves things closer to the design, so +1 from me, but we should wait
to hear from the documentation team.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[Colin Walters]

On Fri, 2012-10-05 at 17:52 +0200, Florian Müllner wrote:
> Hey,
> 
> looks like I have to request another UI freeze break for GNOME Shell :-)
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=685201 is about a UI glitch
> in the login screen that was accidentally introduced when updating the
> lock screen style. Rather than just fixing the glitch in question, we
> think it makes sense to slightly change the layout and thereby bring
> it closer to the lock screen (and design mockups) - the change boils
> down to moving the password entry from its current position next to
> the user's avatar to a new one below avatar / username as in the lock
> screen[0].

Kind of a nontrivial amount of code change, but if it's been tested
I'm OK with it.  So that's RT 2/2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

UI freeze break request for GNOME Shell

[Florian Müllner]

Hey!

I am really sorry for this, but I'd like to request another freeze
break for GNOME Shell. As you may know, notifications in the message
tray now spot a small close button, which may be used to dismiss the
notification. While we managed to match the mockups pretty well, the
designers did not agree at all with the implemented behavior of the
button once they actually were able to try the code[0] - which was
fairly late unfortunately.
Yesterday we finally managed to land the requested changes to master,
but unless we push out a 3.6.2 release including those, we will give
users six months to become accustomed to the "wrong" behavior, making
the change far more painful than necessary.
I have done a quick check on the documentation, it does not look like
either behavior is currently documented; in terms of code, the changes
are very small and unintrusive. So my only concern is really to
irritate users by pushing a change like this in a stable series, which
is of course far from ideal. Still, I believe it will be much more
disruptive at a later point, so including it in a 3.6.2 release
constitutes the lesser evil in my opinion.

Thoughts?

Florian

[0] https://bugzilla.gnome.org/show_bug.cgi?id=682237
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

On Fri, Mar 1, 2013 at 9:20 AM, Cosimo Cecchi  wrote:
> Hi all,
>
> This cycle we redesigned the Shell overview, hiding the message tray by
> default from the view.
> The original design also added a new messages indicator to make the tray
> more discoverable, but it didn't make it in time for 3.7.90. Bug 687797 [1]
> contains a patchset that adds the indicator.
> Patches have been reviewed already and the request comes from the design
> team. OK to commit this?
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=687787

Could you attach a screenshot to the bug ? That makes it much easier
to judge such requests...
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Cosimo Cecchi]

On Fri, Mar 1, 2013 at 10:10 AM, Matthias Clasen

Could you attach a screenshot to the bug ? That makes it much easier
> to judge such requests...
>

Yeah I forgot about it...attached a screenshot now.

Thanks,
Cosimo
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Frederic Peters]

Cosimo Cecchi wrote:

> This cycle we redesigned the Shell overview, hiding the message tray by
> default from the view.
> The original design also added a new messages indicator to make the tray
> more discoverable, but it didn't make it in time for 3.7.90. Bug 687797 [1]
> contains a patchset that adds the indicator.
> Patches have been reviewed already and the request comes from the design
> team. OK to commit this?

1 of 2 for the release team.

https://bugzilla.gnome.org/show_bug.cgi?id=687787#c26 says:

  As for the style, I think it's best to leave that for Jakub or Allan
  to tweak - right now it's using a simple light gray to transparent
  gradient.

It would be really great if those potential changes could also happen
soon.


Fred
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

On Fri, Mar 1, 2013 at 9:20 AM, Cosimo Cecchi  wrote:

.
> Patches have been reviewed already and the request comes from the design
> team. OK to commit this?

Thanks for the screenshot, looks good to me; I'll give an approval for
the release team
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[Piotr Drąg]

2013/10/10 Florian Müllner :
> Oh my, it's this time of the year again ...
>
> When the new status menu work landed, the "Notification" switch that
> used to be in the user menu was removed, although according to the
> mockups[0] it should be included in the message tray menu - I'd like
> to land this[1] now for 3.10.1.
>
> At this point in time, this constitutes both a UI and string freeze
> break, though it restores functionality that has been around for quite
> some time (3.4?) and was only removed late this cycle, so I suspect
> that there are translations/documentation that can be resurrected.
>

It's a bit too late, but since we already accepted bigger changes, I
give 1/2 from i18n. Please note that this the last time I'm going to
approve a break in this cycle.

-- 
Piotr Drąg
http://raven.fedorapeople.org/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[Javier Jardón]

On 10 October 2013 15:38, Piotr Drąg  wrote:
> 2013/10/10 Florian Müllner :
>> Oh my, it's this time of the year again ...
>>
>> When the new status menu work landed, the "Notification" switch that
>> used to be in the user menu was removed, although according to the
>> mockups[0] it should be included in the message tray menu - I'd like
>> to land this[1] now for 3.10.1.
>>
>> At this point in time, this constitutes both a UI and string freeze
>> break, though it restores functionality that has been around for quite
>> some time (3.4?) and was only removed late this cycle, so I suspect
>> that there are translations/documentation that can be resurrected.
>>
>
> It's a bit too late, but since we already accepted bigger changes, I
> give 1/2 from i18n. Please note that this the last time I'm going to
> approve a break in this cycle.

+1 for release team


-- 
Javier Jardón Cabezas
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[Petr Kovar]

Piotr Drąg , Thu, 10 Oct 2013 16:38:42 +0200:

> 2013/10/10 Florian Müllner :
> > Oh my, it's this time of the year again ...
> >
> > When the new status menu work landed, the "Notification" switch that
> > used to be in the user menu was removed, although according to the
> > mockups[0] it should be included in the message tray menu - I'd like
> > to land this[1] now for 3.10.1.
> >
> > At this point in time, this constitutes both a UI and string freeze
> > break, though it restores functionality that has been around for quite
> > some time (3.4?) and was only removed late this cycle, so I suspect
> > that there are translations/documentation that can be resurrected.
> >
> 
> It's a bit too late, but since we already accepted bigger changes, I
> give 1/2 from i18n. Please note that this the last time I'm going to
> approve a break in this cycle.

2/2 for i18n. 

Florian, please try to push the change ASAP so that translators have
enough time to get their translations updated for the point release.

Thank you,
Petr Kovar
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[Matthias Clasen]

On Thu, Oct 10, 2013 at 10:59 AM, Javier Jardón  wrote:

>
>
> +1 for release team
>

Second approval for the release team
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Feature freeze break request for gnome-shell

[Carlos Garnacho]

Hey,

I would like to request a feature freeze break for gnome-shell in order to
include https://bugzilla.gnome.org/show_bug.cgi?id=735625 , Now that the
shell has gestures support it's a bit of a shame that the one feature that
was truly inaccessible through touch remains like that :). This was made to
follow https://wiki.gnome.org/Design/OS/Gestures btw.

Cheers,
  Carlos
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

String freeze break request for gnome-shell

[Florian Müllner]

Hey folks,

sorry for the late request, but the bug in question[0] only came in today ...

In the system menu, we'd like to link to the corresponding Settings
panel in the Location submenu (like all other submenus do), which
would add the new string "Privacy Settings".

-- Florian

[0] https://bugzilla.gnome.org/show_bug.cgi?id=736542
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Frederic Peters]

Piñeiro wrote:
> This bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=736821
> 
> makes gnome-shell mostly inaccessible. The fix is trivial, and was
> already reviewed and accepted by gnome-shell developers.
> 
> Andre already give a 1/2 from release team on the bug. I could do the
> same, but I guess that it would be strange to give a release-team vote
> on an own bug.

Ok, 2/2


Fred
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Frederic Peters]

Hi Florian,

> I'd like to request a freeze break for bug
> https://bugzilla.gnome.org/show_bug.cgi?id=736910. When opening an
> empty folder in the app picker, the shell ends up in a confused state
> - there is no folder popup, but icons are faded out and become
> non-reactive to clicks as if a folder had been opened. It is possible
> to get back to a normal state again (either by closing the app picker
> or by opening a "proper" app folder), but the behavior is clearly and
> obviously broken.
> The proposed patch avoids this issue in a very simple way - there is
> nothing users can do with empty app folders, so there's no reason to
> show them in the first place. The patch to hide folders in that case
> is a simple one-line patch.

First approval.


Fred
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

On Fri, Sep 19, 2014 at 8:10 AM, Frederic Peters  wrote:
> Hi Florian,
>
>> I'd like to request a freeze break for bug
>> https://bugzilla.gnome.org/show_bug.cgi?id=736910. When opening an
>> empty folder in the app picker, the shell ends up in a confused state
>> - there is no folder popup, but icons are faded out and become
>> non-reactive to clicks as if a folder had been opened. It is possible
>> to get back to a normal state again (either by closing the app picker
>> or by opening a "proper" app folder), but the behavior is clearly and
>> obviously broken.
>> The proposed patch avoids this issue in a very simple way - there is
>> nothing users can do with empty app folders, so there's no reason to
>> show them in the first place. The patch to hide folders in that case
>> is a simple one-line patch.
>
> First approval.
>

Second approval
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Florian Müllner]

Danke & merci!

On Fri, Sep 19, 2014 at 2:39 PM, Matthias Clasen
 wrote:
> On Fri, Sep 19, 2014 at 8:10 AM, Frederic Peters  wrote:
>> Hi Florian,
>>
>>> I'd like to request a freeze break for bug
>>> https://bugzilla.gnome.org/show_bug.cgi?id=736910. When opening an
>>> empty folder in the app picker, the shell ends up in a confused state
>>> - there is no folder popup, but icons are faded out and become
>>> non-reactive to clicks as if a folder had been opened. It is possible
>>> to get back to a normal state again (either by closing the app picker
>>> or by opening a "proper" app folder), but the behavior is clearly and
>>> obviously broken.
>>> The proposed patch avoids this issue in a very simple way - there is
>>> nothing users can do with empty app folders, so there's no reason to
>>> show them in the first place. The patch to hide folders in that case
>>> is a simple one-line patch.
>>
>> First approval.
>>
>
> Second approval
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

UI freeze break request for gnome-shell

[Giovanni Campagna]

Hello release-team,

long time no see :)

I'd like to request a UI freeze break to solve bug 660293 (which is a dupe
of 740750).

There are no screenshots in the bug, but what it does is fairly simple:
instead of popping up a network password modal dialog out of the blue, it
shows a notification asking for password.
You click on the notification and you get the usual dialog. You dismiss the
notification and the connection fails.
The UI was acked by designers.

I made sure to reuse existing strings (including some typographical fixes
which are not visible in the patch attached to the bug, but I have
locally), so this is only a UI freeze break, not a string freeze break.

Cheers

Giovanni
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Michael Catanzaro]

On Tue, 2016-09-13 at 21:27 +, Florian Müllner wrote:
> I'm sorry I didn't catch this before the freeze. It turns out gnome-
> shell's
> extension-prefs tool is another victim of GTK+'s ScrolledWindow
> changes
> this cycle:

Approval 1/2
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

Approval 2/2

On Tue, Sep 13, 2016 at 6:26 PM, Michael Catanzaro  wrote:
> On Tue, 2016-09-13 at 21:27 +, Florian Müllner wrote:
>> I'm sorry I didn't catch this before the freeze. It turns out gnome-
>> shell's
>> extension-prefs tool is another victim of GTK+'s ScrolledWindow
>> changes
>> this cycle:
>
> Approval 1/2
> ___
> 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.

Re: Freeze break request for gnome-shell

[Michael Catanzaro]

On Fri, 2016-09-16 at 17:01 +, Florian Müllner wrote:
> The two remaining patches fix glitches when selecting a hidden window
> - it
> is odd to switch to a window and have it disappear briefly before
> animating
> back in, so I would still like to see an exception for them as well.
> Those
> glitches only show up temporarily during the finishing animation
> though, so
> fixing them isn't quite as urgent as the first issue (in case you'd
> rather
> keep that part for .1)

r-t 1/2 for all of them

IMO it's safer to throw these all into .0 and fix in .1 if there is an
unexpected regression, rather than introduce a regression in .1 and
have it broken until .2. But let's hope for no regression. ;)

Michael
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Frederic Peters]

Hi Florian,

Michael Catanzaro wrote:
> On Fri, 2016-09-16 at 17:01 +, Florian Müllner wrote:
> > The two remaining patches fix glitches when selecting a hidden window
> > - it
> > is odd to switch to a window and have it disappear briefly before
> > animating
> > back in, so I would still like to see an exception for them as well.
> > Those
> > glitches only show up temporarily during the finishing animation
> > though, so
> > fixing them isn't quite as urgent as the first issue (in case you'd
> > rather
> > keep that part for .1)
> 
> r-t 1/2 for all of them

2 of 2, let's get those in for 3.22.0.



Fred
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

On Tue, Feb 28, 2017 at 12:49 PM, Florian Müllner 
wrote:

>
>
> In my opinion, both items make for some nice polish improvements in
> that area with low risk (the weather section is very isolated, and the
> visual refresh is mostly a style update), so they would make for a
> good (while late) 3.24 addition.
>

I concur. +1 for the release team from me.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Michael Catanzaro]

On Tue, 2017-02-28 at 13:06 -0500, Matthias Clasen wrote:
> On Tue, Feb 28, 2017 at 12:49 PM, Florian Müllner  g> wrote:
> > 
> > In my opinion, both items make for some nice polish improvements in
> > that area with low risk (the weather section is very isolated, and
> > the
> > visual refresh is mostly a style update), so they would make for a
> > good (while late) 3.24 addition.
> 
> I concur. +1 for the release team from me. 

I'm torn. I like the changes too: it looks like a good improvement. But
it's a pretty major UI change in a significant component of the desktop
shell, and going in very late in the release cycle. I'd prefer to save
it for 3.26 to give users more time to comment on the change. So I
won't give +1 myself, but I also won't block it if someone else wants
to give the second +1.

Michael
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Matthias Clasen]

fwiw, I'm +1 _because_ this is a visible improvement and new feature in
gnome shell - we don't have much else to show in that area, this
cycle...maybe thats me wearing a marketing rather than rel-eng hat
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Florian Müllner]

On Tue, Feb 28, 2017 at 7:52 PM Matthias Clasen 
wrote:

> we don't have much else to show in that area, this cycle...maybe thats me
> wearing a marketing rather than rel-eng hat
>

I was afraid of mentioning the 'm' word, but that was indeed a main
motivator behind the push for finishing up those branches
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Javier Jardón]

On 28 Feb 2017 19:02, "Florian Müllner"  wrote:

On Tue, Feb 28, 2017 at 7:52 PM Matthias Clasen 
wrote:

> we don't have much else to show in that area, this cycle...maybe thats me
> wearing a marketing rather than rel-eng hat
>

I was afraid of mentioning the 'm' word, but that was indeed a main
motivator behind the push for finishing up those branches

___
gnome-doc-list mailing list
gnome-doc-l...@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-doc-list


2/2 for release team
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Rui Tiago Cação Matos]

[ Re-sending since it seems this didn't make it to the release team list ]

> Hi,
>
> I'd like to request a freeze break request for this gnome-shell UI addition:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=783550 - it's basically an
> Alt+Tab style switcher to cycle through multi-monitor configurations
> on laptops.
>
> Thanks,
> Rui
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Michael Catanzaro]

This looks pretty self-contained, and I presume you originally sent the 
request a week and a half ago when we were earlier in the cycle. So +1 
of 2 from me.


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[mcatanzaro]

I'm nervous about this one for three reasons:

* It's gjs, so any subtle flaw in this changeset could cause entire 
functions to be skipped over
* We're two days before the tarball deadline, so there's really no 
time left to notice if any such flaws were to sneak in

* It's also drag-and-drop code, which is tricky to get right

I would have given +1 to this if requested earlier this week, but at 
this point I'll be quite cautious and suggest committing immediately 
after 3.30.0, so that it has a couple weeks to bake it git before 
3.30.1, just in case.


I'm happy to see the invalid access warnings will be fixed. Almost as 
happy as I would be to see tweener fixes. :P


Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Andre Klapper]

On Sat, 2018-09-01 at 08:43 -0500, mcatanz...@gnome.org wrote:
> I'm nervous about this one for three reasons:

Similar feelings here. Extremely happy to see progress but let's give
testing three weeks (3.30.0 to 3.30.1) instead of three days.

andre
-- 
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[mcatanzaro]

I'll give a hesitant +1 to this one, since the change is small.

If you consider it important enough for a 3.30.0 freeze break, rather 
than waiting three weeks for 3.30.1, then it should also important 
enough to backport to 3.28. It would be nice to see this fixed there 
too.


Thanks for solving it,

Michael

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[verdre]

I have an alternative solution which would be more compatible with 
changes we'll make in the future, could this one also get an approval?


It's even less intrusive than the other one since there's no need to 
stop initially hiding the label.


https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/215

Thank you,
verdre

On 02.09.2018 02:37, mcatanz...@gnome.org wrote:


I'll give a hesitant +1 to this one, since the change is small.

If you consider it important enough for a 3.30.0 freeze break, rather 
than waiting three weeks for 3.30.1, then it should also important 
enough to backport to 3.28. It would be nice to see this fixed there too.


Thanks for solving it,

Michael


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Emmanuele Bassi via release-team]

With 24 hours to go from the cut off deadline for 3.30, I don’t think this
is a good idea; this can wait for 3.30.1, and might as well use the
appropriate fix. Most distros will ship that version anyway.

Ciao,
 Emmanuele.

On Sun, 2 Sep 2018 at 17:13, verdre  wrote:

> I have an alternative solution which would be more compatible with
> changes we'll make in the future, could this one also get an approval?
>
> It's even less intrusive than the other one since there's no need to
> stop initially hiding the label.
>
> https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/215
>
> Thank you,
> verdre
>
> On 02.09.2018 02:37, mcatanz...@gnome.org wrote:
> >
> > I'll give a hesitant +1 to this one, since the change is small.
> >
> > If you consider it important enough for a 3.30.0 freeze break, rather
> > than waiting three weeks for 3.30.1, then it should also important
> > enough to backport to 3.28. It would be nice to see this fixed there too.
> >
> > Thanks for solving it,
> >
> > Michael
> >
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
>
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[verdre]

This is the appropriate fix, it's not going to get any better. But I understand 
if you don't want to ship it so close to the deadline.

Thanks,
verdre

> With 24 hours to go from the cut off deadline for 3.30, I don’t think this is 
> a good idea; this can wait for 3.30.1, and might as well use the appropriate 
> fix. Most distros will ship that version anyway.
> 
>  
> Ciao,
>  Emmanuele.
> 
> 
> On Sun, 2 Sep 2018 at 17:13, verdre < ver...@v0yd.nl> wrote: 
> > I have an alternative solution which would be more compatible with 
> >  changes we'll make in the future, could this one also get an approval? 
> >  
> >  It's even less intrusive than the other one since there's no need to 
> >  stop initially hiding the label. 
> >  
> >  https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/215 
> >  
> >  Thank you, 
> >  verdre 
> >  
> >  On 02.09.2018 02:37, mcatanz...@gnome.org wrote: 
> > > 
> > > I'll give a hesitant +1 to this one, since the change is small. 
> > > 
> > > If you consider it important enough for a 3.30.0 freeze break, rather 
> > > than waiting three weeks for 3.30.1, then it should also important 
> > > enough to backport to 3.28. It would be nice to see this fixed there too. 
> > > 
> > > Thanks for solving it, 
> > > 
> > > Michael 
> > > 
> >  ___ 
> >  release-team@gnome.org 
> >  https://mail.gnome.org/mailman/listinfo/release-team 
> >  Release-team lurker? Do NOT participate in discussions.
> 
> 
> -- 
> 
> https://www.bassi.io 
> [@] ebassi [@ [gmail.com](http://gmail.com)]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[mcatanzaro]

+1 / 2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for GNOME Shell

[Andre Klapper]

On Fri, 2019-03-08 at 13:53 -0600, mcatanz...@gnome.org wrote:
> +1 / 2

r-t approval 2 of 2

andre
-- 
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Michael Catanzaro]

Approval 1


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Emmanuele Bassi]

And approval 2/2.

Ciao,
Emmanuele.

On Mon, 2 Mar, 2020 at 09:11, Michael Catanzaro  
wrote:


Approval 1


___
release-team@gnome.org 

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.

Re: UI freeze break request for gnome-shell

[Javier Jardón]

On 1 September 2012 06:06, Giovanni Campagna  wrote:
> Hello release team,
>
> I'm requesting a UI freeze break for the following bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=682285
> (only the two patches marked accepted-commit_now are significant, the
> rest are dubious code cleanups)
>
> The scope of the bug is to replace the arrow handle in the screen lock
> curtain with an animation that makes it clear the curtain is meant to
> be lifted up with a mouse or touch gesture.
>
> Screenshot before:
> https://dl.dropbox.com/s/wu4iv9w5avl33ry/lock-screen-before.png
> Screenshot after: 
> https://dl.dropbox.com/s/wlo6o1ny5urelkn/lock-screen-after.png
> (The second screenshot is hopefully usable as-is for release notes and
> documentation, as taking it required careful timing and a good amount
> of luck)

The patches are aproved by design team and maintainers, lets try to
get this in .91
+ 1 / 2 from release team

Cheers
-- 
Javier Jardón Cabezas
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for gnome-shell

[Matthias Clasen]

On Fri, Aug 31, 2012 at 7:41 PM, Javier Jardón  wrote:
> On 1 September 2012 06:06, Giovanni Campagna  
> wrote:
>> Hello release team,
>>
>> I'm requesting a UI freeze break for the following bug:
>> https://bugzilla.gnome.org/show_bug.cgi?id=682285
>> (only the two patches marked accepted-commit_now are significant, the
>> rest are dubious code cleanups)
>>
>> The scope of the bug is to replace the arrow handle in the screen lock
>> curtain with an animation that makes it clear the curtain is meant to
>> be lifted up with a mouse or touch gesture.
>>
>> Screenshot before:
>> https://dl.dropbox.com/s/wu4iv9w5avl33ry/lock-screen-before.png
>> Screenshot after: 
>> https://dl.dropbox.com/s/wlo6o1ny5urelkn/lock-screen-after.png
>> (The second screenshot is hopefully usable as-is for release notes and
>> documentation, as taking it required careful timing and a good amount
>> of luck)
>
> The patches are aproved by design team and maintainers, lets try to
> get this in .91
> + 1 / 2 from release team
>

+1 from me as well
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for gnome-shell

[Matthias Clasen]

On Tue, Sep 4, 2012 at 3:49 PM, Giovanni Campagna
 wrote:
> Hello release team,
>
> As promised, I'm here again with another request for UI freeze break.
> This time, it's about https://bugzilla.gnome.org/show_bug.cgi?id=682544
> What it does is replacing the "Authentication failed" banner
> notification on password failure, as well as other PAM messages, in
> gdm and in the unlock dialog with an orange prompt below the entry, in
> the style of the mockup at
> https://github.com/gnome-design-team/gnome-mockups/raw/master/system-lock-login-boot/authentication-failure.png
> , except without the icon.
> The feature is listed in the BoF page at priority 0 for the login dialog.
> I had this prepared for 3.5.91, but a required gdm change appeared
> after gnome-shell 3.5.91 was released, so this won't make it, unless a
> 3.5.91.1 is released.

+1 for the release team, although you should probably include
gnome-i18n - those are new translatable strings, I guess ?
I'll make sure we get a .1  release for it, if required.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for gnome-shell

[Giovanni Campagna]

2012/9/4 Matthias Clasen :
> On Tue, Sep 4, 2012 at 3:49 PM, Giovanni Campagna
>  wrote:
>> Hello release team,
>>
>> As promised, I'm here again with another request for UI freeze break.
>> This time, it's about https://bugzilla.gnome.org/show_bug.cgi?id=682544
>> What it does is replacing the "Authentication failed" banner
>> notification on password failure, as well as other PAM messages, in
>> gdm and in the unlock dialog with an orange prompt below the entry, in
>> the style of the mockup at
>> https://github.com/gnome-design-team/gnome-mockups/raw/master/system-lock-login-boot/authentication-failure.png
>> , except without the icon.
>> The feature is listed in the BoF page at priority 0 for the login dialog.
>> I had this prepared for 3.5.91, but a required gdm change appeared
>> after gnome-shell 3.5.91 was released, so this won't make it, unless a
>> 3.5.91.1 is released.
>
> +1 for the release team, although you should probably include
> gnome-i18n - those are new translatable strings, I guess ?
> I'll make sure we get a .1  release for it, if required.

There are no new strings, the messages come from libpam or gdm and are
already translated.

Giovanni
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for gnome-shell

[Javier Jardón]

On 5 September 2012 05:56, Giovanni Campagna  wrote:
> 2012/9/4 Matthias Clasen :
>> On Tue, Sep 4, 2012 at 3:49 PM, Giovanni Campagna
>>  wrote:
>>> Hello release team,
>>>
>>> As promised, I'm here again with another request for UI freeze break.
>>> This time, it's about https://bugzilla.gnome.org/show_bug.cgi?id=682544
>>> What it does is replacing the "Authentication failed" banner
>>> notification on password failure, as well as other PAM messages, in
>>> gdm and in the unlock dialog with an orange prompt below the entry, in
>>> the style of the mockup at
>>> https://github.com/gnome-design-team/gnome-mockups/raw/master/system-lock-login-boot/authentication-failure.png
>>> , except without the icon.
>>> The feature is listed in the BoF page at priority 0 for the login dialog.
>>> I had this prepared for 3.5.91, but a required gdm change appeared
>>> after gnome-shell 3.5.91 was released, so this won't make it, unless a
>>> 3.5.91.1 is released.
>>
>> +1 for the release team, although you should probably include
>> gnome-i18n - those are new translatable strings, I guess ?
>> I'll make sure we get a .1  release for it, if required.
>
> There are no new strings, the messages come from libpam or gdm and are
> already translated.

Great, 2/2 for r-t



-- 
Javier Jardón Cabezas
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break request for gnome-shell

[Florian Müllner]

On Tue, Sep 18, 2012 at 8:33 PM, Giovanni Campagna
 wrote:
> With the patch, "Authentication error" is shown for a few seconds under the
> entry (in the same place as "Authentication failed"), and the greeter
> is reset or the lock screen curtain falls down again.

Could you attach a screenshot on the bug so that the designers can
give a quick thumbs-up as well?

Thanks,
Florian
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break request for gnome-shell

[Giovanni Campagna]

2012/9/18 Florian Müllner :
> On Tue, Sep 18, 2012 at 8:33 PM, Giovanni Campagna
>  wrote:
>> With the patch, "Authentication error" is shown for a few seconds under the
>> entry (in the same place as "Authentication failed"), and the greeter
>> is reset or the lock screen curtain falls down again.
>
> Could you attach a screenshot on the bug so that the designers can
> give a quick thumbs-up as well?

Done now.

Giovanni
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break request for gnome-shell

[Matthias Clasen]

On Tue, Sep 18, 2012 at 2:33 PM, Giovanni Campagna
 wrote:

The patch looks good to me. I've asked #gnome-design to weigh in.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break request for gnome-shell

[Gabor Kelemen]

2012-09-18 20:33 keltezéssel, Giovanni Campagna írta:

Hello release team, hello translators,

I'd like to break the string freeze for gnome-shell for bug
https://bugzilla.gnome.org/show_bug.cgi?id=683060. The main part of it
is already solved, what is left out is handling DBus errors that might
happen even if GDM is available and the right version.
There is only one string, "Authentication error", and in the normal
case it should be never shown to the user. In fact, I've never
experienced such problems myself, but
https://bugzilla.gnome.org/show_bug.cgi?id=684172 tells me otherwise.
Without the patch, the shell is left with a broken greeter (half
animated avatar, no prompt) or unlock dialog (full grey screen). With
the patch, "Authentication error" is shown for a few seconds under the
entry (in the same place as "Authentication failed"), and the greeter
is reset or the lock screen curtain falls down again.



Sounds serious enough, so i18n approval 1/2.

Regards
Gabor Kelemen
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break request for gnome-shell

[Gil Forcada Codinachs]

2/2 from i18n.

Cherrs,
On Sep 19, 2012 9:09 AM, "Gabor Kelemen"  wrote:

> 2012-09-18 20:33 keltezéssel, Giovanni Campagna írta:
>
>> Hello release team, hello translators,
>>
>> I'd like to break the string freeze for gnome-shell for bug
>> https://bugzilla.gnome.org/**show_bug.cgi?id=683060.
>> The main part of it
>> is already solved, what is left out is handling DBus errors that might
>> happen even if GDM is available and the right version.
>> There is only one string, "Authentication error", and in the normal
>> case it should be never shown to the user. In fact, I've never
>> experienced such problems myself, but
>> https://bugzilla.gnome.org/**show_bug.cgi?id=684172tells
>>  me otherwise.
>> Without the patch, the shell is left with a broken greeter (half
>> animated avatar, no prompt) or unlock dialog (full grey screen). With
>> the patch, "Authentication error" is shown for a few seconds under the
>> entry (in the same place as "Authentication failed"), and the greeter
>> is reset or the lock screen curtain falls down again.
>>
>>
> Sounds serious enough, so i18n approval 1/2.
>
> Regards
> Gabor Kelemen
> __**_
> gnome-i18n mailing list
> gnome-i...@gnome.org
> https://mail.gnome.org/**mailman/listinfo/gnome-i18n
>
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for GNOME Shell

[Matthias Clasen]

On Fri, Oct 26, 2012 at 1:18 PM, Florian Müllner  wrote:
> Hey!
>
> I am really sorry for this, but I'd like to request another freeze
> break for GNOME Shell. As you may know, notifications in the message
> tray now spot a small close button, which may be used to dismiss the
> notification. While we managed to match the mockups pretty well, the
> designers did not agree at all with the implemented behavior of the
> button once they actually were able to try the code[0] - which was
> fairly late unfortunately.
> Yesterday we finally managed to land the requested changes to master,
> but unless we push out a 3.6.2 release including those, we will give
> users six months to become accustomed to the "wrong" behavior, making
> the change far more painful than necessary.
> I have done a quick check on the documentation, it does not look like
> either behavior is currently documented; in terms of code, the changes
> are very small and unintrusive. So my only concern is really to
> irritate users by pushing a change like this in a stable series, which
> is of course far from ideal. Still, I believe it will be much more
> disruptive at a later point, so including it in a 3.6.2 release
> constitutes the lesser evil in my opinion.
>
> Thoughts?

Sounds like a fairly convincing argument to me. +1 from me.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for GNOME Shell

[Shaun McCance]

On Fri, 2012-10-26 at 19:18 +0200, Florian Müllner wrote:
> Hey!
> 
> I am really sorry for this, but I'd like to request another freeze
> break for GNOME Shell. As you may know, notifications in the message
> tray now spot a small close button, which may be used to dismiss the
> notification. While we managed to match the mockups pretty well, the
> designers did not agree at all with the implemented behavior of the
> button once they actually were able to try the code[0] - which was
> fairly late unfortunately.
> Yesterday we finally managed to land the requested changes to master,
> but unless we push out a 3.6.2 release including those, we will give
> users six months to become accustomed to the "wrong" behavior, making
> the change far more painful than necessary.
> I have done a quick check on the documentation, it does not look like
> either behavior is currently documented; in terms of code, the changes
> are very small and unintrusive. So my only concern is really to
> irritate users by pushing a change like this in a stable series, which
> is of course far from ideal. Still, I believe it will be much more
> disruptive at a later point, so including it in a 3.6.2 release
> constitutes the lesser evil in my opinion.
> 
> Thoughts?
> 
> Florian
> 
> [0] https://bugzilla.gnome.org/show_bug.cgi?id=682237

I'm deferring to Mike Hill for the docs impact. He's been through
these pages more than anybody else this release cycle.

Meta: How can we prevent these kinds of late-cycle changes in the
future? Part of the problem may be implementing from mockups with
insufficient specification of behavior. But there will always be
implementation issues you don't anticipate in design specs.

What about a concerted effort to test implementations against the
designs immediately following the freeze?

--
Shaun



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for GNOME Shell

[Michael Hill]

On Fri, Oct 26, 2012 at 1:18 PM, Florian Müllner  wrote:

> I have done a quick check on the documentation, it does not look like
> either behavior is currently documented...

+1 from Docs Team... we were just holding off so the right behaviour
could be immortalized in the docs.

Mike
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for GNOME Shell

[Florian Müllner]

On Fri, Oct 26, 2012 at 8:35 PM, Shaun McCance  wrote:
> Meta: How can we prevent these kinds of late-cycle changes in the
> future?

Testable[0]. And OSTree, hopefully.


> Part of the problem may be implementing from mockups with
> insufficient specification of behavior. But there will always be
> implementation issues you don't anticipate in design specs.

Yes. And some ideas appear absolutely fantastic when written in a
spec, but just don't work out when you sit in front of the
implementation. Reevaluating design specs by testing the
implementation as early as possible and refining the design based on
the results is essential here in my opinion. Ideally designers should
start evaluating a feature as it lands, so that code and design can
evolve in parallel. Unfortunately jhbuild is not exactly a friendly
tool for non-developers (in particular mid-cycle, where running a
build without breakage by one dependency or another is the rare
exception). And as we start to integrate more deeply with lower
layers, jhbuild doesn't work at all. Around Guadec time, fully testing
the code in development basically required running a bleeding edge
system like Rawhide, with a couple of system packages replaced by
versions built straight from git.

Discussion on how to improve this took up a good part of the GnomeOS
BOF at Guadec for a reason - and the resulting initiatives around
automatic builds, QA and early testing hopefully will bear fruits
soon.


> What about a concerted effort to test implementations against the
> designs immediately following the freeze?

I don't think that's good enough. Coincidentally, Allan filed this
particular bug the very same day of the freeze, but between some back
and forth between coders and designers, getting patches written and
reviewed and working on quite a list of other fixes for 3.6.1, we
still ended up as late as now.

We will need to do better, but there's hope we actually will.


Florian


[0] https://live.gnome.org/GnomeOS/Testable
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for GNOME Shell

[Frederic Peters]

Michael Hill wrote:

> On Fri, Oct 26, 2012 at 1:18 PM, Florian Müllner  wrote:
> 
> > I have done a quick check on the documentation, it does not look like
> > either behavior is currently documented...
> 
> +1 from Docs Team... we were just holding off so the right behaviour
> could be immortalized in the docs.

2/2 from the release team, then.

Go ahead!

Fred
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Feature freeze break request for gnome-shell

[Matthias Clasen]

>
> I would like to request a feature freeze break for gnome-shell in order to
> include https://bugzilla.gnome.org/show_bug.cgi?id=735625 , Now that the
> shell has gestures support it's a bit of a shame that the one feature that
> was truly inaccessible through touch remains like that :). This was made to
> follow https://wiki.gnome.org/Design/OS/Gestures btw.

+1 for the release team.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Feature freeze break request for gnome-shell

[Frederic Peters]

Hi Carlos,

> I would like to request a feature freeze break for gnome-shell in order to
> include https://bugzilla.gnome.org/show_bug.cgi?id=735625 , Now that the
> shell has gestures support it's a bit of a shame that the one feature that
> was truly inaccessible through touch remains like that :). This was made to
> follow https://wiki.gnome.org/Design/OS/Gestures btw.

Fine, that's your 2 of 2.


Fred
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break request for gnome-shell

[Daniel Mustieles García]

1/2 from i18n

Cheers

2014-09-12 12:04 GMT+02:00 Florian Müllner :

> Hey folks,
>
> sorry for the late request, but the bug in question[0] only came in today
> ...
>
> In the system menu, we'd like to link to the corresponding Settings
> panel in the Location submenu (like all other submenus do), which
> would add the new string "Privacy Settings".
>
> -- Florian
>
> [0] https://bugzilla.gnome.org/show_bug.cgi?id=736542
> ___
> gnome-i18n mailing list
> gnome-i...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break request for gnome-shell

[Alexandre Franke]

2/2 from i18n.

-- 
Alexandre Franke
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for gnome-shell

[Matthias Clasen]

On Wed, Mar 11, 2015 at 4:45 PM, Giovanni Campagna
 wrote:
> Hello release-team,
>
> long time no see :)
>
> I'd like to request a UI freeze break to solve bug 660293 (which is a dupe
> of 740750).
>
> There are no screenshots in the bug, but what it does is fairly simple:
> instead of popping up a network password modal dialog out of the blue, it
> shows a notification asking for password.
> You click on the notification and you get the usual dialog. You dismiss the
> notification and the connection fails.
> The UI was acked by designers.
>
> I made sure to reuse existing strings (including some typographical fixes
> which are not visible in the patch attached to the bug, but I have locally),
> so this is only a UI freeze break, not a string freeze break.

Hi Giovanni,

a strong +1 from me for the release team. Getting rid of spontaneous
modal dialogs has been one of the things we've pushed for with the
target bug list. Nice to see that we'll make some progress on this
before the gates close for 3.16.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: UI freeze break request for gnome-shell

[Andre Klapper]

On Wed, 2015-03-11 at 17:13 -0400, Matthias Clasen wrote:
> On Wed, Mar 11, 2015 at 4:45 PM, Giovanni Campagna wrote:
> > I'd like to request a UI freeze break to solve bug 660293 (which is a dupe
> > of 740750).
> >
> > There are no screenshots in the bug, but what it does is fairly simple:
> > instead of popping up a network password modal dialog out of the blue, it
> > shows a notification asking for password.
> > You click on the notification and you get the usual dialog. You dismiss the
> > notification and the connection fails.
> > The UI was acked by designers.
> >
> > I made sure to reuse existing strings (including some typographical fixes
> > which are not visible in the patch attached to the bug, but I have locally),
> > so this is only a UI freeze break, not a string freeze break.
> 
> Hi Giovanni,
> 
> a strong +1 from me for the release team. Getting rid of spontaneous
> modal dialogs has been one of the things we've pushed for with the
> target bug list. Nice to see that we'll make some progress on this
> before the gates close for 3.16.

Second +1 for https://bugzilla.gnome.org/show_bug.cgi?id=660293#c42 ;
this sounds like a way better approach to me.

andre
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

UI/hardcode freeze break request for GNOME Shell

[Allan Day]

Hi all,

This is a break request that changes some visual styling in GNOME shell.
The code changes are deliberately minimal. However, the visual change is
noticeable.

The design team recognise that it is late in the cycle but we'd be unhappy
putting the release out in its current state.

The bug containing the patch:
https://bugzilla.gnome.org/show_bug.cgi?id=787446

Thanks,

Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.