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: 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

[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

[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

[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

[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]

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

[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'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

[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

[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

[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

[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

[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]

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

[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

[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

[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 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

[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 fpet...@gnome.org 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
matthias.cla...@gmail.com wrote:
 On Fri, Sep 19, 2014 at 8:10 AM, Frederic Peters fpet...@gnome.org 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

[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

[Piotr Drąg]

2013/10/10 Florian Müllner fmuell...@gnome.org:
 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 piotrd...@gmail.com wrote:
 2013/10/10 Florian Müllner fmuell...@gnome.org:
 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 piotrd...@gmail.com, Thu, 10 Oct 2013 16:38:42 +0200:

 2013/10/10 Florian Müllner fmuell...@gnome.org:
  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 Fri, Mar 1, 2013 at 9:20 AM, Cosimo Cecchi cosimo.cec...@gmail.com 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 cosimo.cec...@gmail.com 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

[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.

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

[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

[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 fmuell...@gnome.org 
  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 fmuell...@gnome.org 
  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 chat/on-screen-keyboard integration

[Javier Jardón]

On 22 September 2011 20:27, Dan Winship d...@gnome.org wrote:
 On 09/22/2011 01:23 PM, Matthias Clasen wrote:
 On Thu, Sep 22, 2011 at 10:34 AM, Dan Winship d...@gnome.org wrote:
 https://bugzilla.gnome.org/show_bug.cgi?id=658603 should have gotten
 committed before the freeze/tarball, but accidentally didn't. It fixes
 two pretty ugly problems when trying to use chat with the on-screen
 keyboard (the smaller patch fixes a problem with things not animating
 correctly, the larger patch fixes a problem with the chat disappearing
 when you move the pointer into the keyboard).


 Are you going to address Marina's comments there, or just commit the
 patch as is for 3.2 and revisit it later ?

 I'm going to merge in her suggestion.

Go ahead then, 2/2 from RT



-- 
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

[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/caribou keyboard interaction

[Matthias Clasen]

On Thu, Sep 22, 2011 at 5:36 PM, Dan Winship d...@gnome.org wrote:
 Under certain circumstances (especially if gnome-shell crashes and is
 restarted), it's possible for antler (the fallback on-screen keyboard
 that is part of caribou) to end up running under gnome-shell.

 This is easy to fix, it's just a matter of picking the right dbus flags
 when grabbing the unique name.

 shell patch:
 https://bugzilla.gnome.org/show_bug.cgi?id=659865

 caribou patch:
 https://bugzilla.gnome.org/show_bug.cgi?id=659867


I've tested these, they make the on-screen keyboard a lot more reliable. +1
___
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 fmuell...@gnome.org

 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.