Hi,
On Fri, 15 Feb 2013 18:52:39 +0100 intrigeri <intrigeri@???> wrote:
>
> Alan wrote (14 Feb 2013 13:48:50 GMT) :
> > Well, the change was in a bigger commit
> > f42f51987f8ec82bd10d65a46113a158ffc70bf7 that we probably don't want
> > to revert as a whole.
>
> FYI, "git revert --no-commit" + "git add -p" allows to selectively
> revert parts of a commit.
>
Thanks.
> > And there were no "reboot" and "lock screen" actions.
>
> I acknowledge adding a "reboot" action is welcome, and I will possibly
> take it, even if it is not a bugfix.
>
> OTOH, the "lock" action is a mistake, I believe, as we don't install
> gnome-screensaver yet...
>
> Here are simple recipes, applicable late in a release cycle, that help
> keeping release managers happy:
>
> 1. Propose *minimal* changes that *only* fix the bug they are
> supposed to.
> 2. If possible, reuse code that was exposed to some testing already,
> e.g. simply revert the faulty change instead of introducing a new
> way to fix.
> 3. Don't try to sneak in further awesome improvements that don't
> belong to the bug you're fixing. Keep them for later. Seriously.
> 4. If in doubt, refer to 1 :)
>
> In my experience, this set of recipes works both with me and with the
> Debian release team. Every additional fancy idea or change often
> introduces regressions, needs additional communication round-trips,
> and makes people spend more time on the topic that what they've
> happily accepted to in the first place.
>
Sorry for the inconvenience.
> > I made the same changes as with my previous commit, but the way
> > that was done in 0.15 in a newer version of the branch (to be
> > rewritten before a merge as I let old stuff to let people compare).
>
> Awesome.
>
> I've rewritten history to skip the commit+revert and throw away the
> "lock" entry: bugfix/shutdown_with_camouflage-squashed.
>
> If someone tests and ACK's this, I'm happy to take it for 0.17.
> Else, it will have to wait for the next (point-)release.
>
Thanks. I applied the patch to a running experimental and it works. I
volonteer to test it on top of 0.17rc1 once I got it.
> >> If there are good reasons to do it the way this branch does,
> >> probably fine with me, but then, I suggest putting the .desktop
> >> data in separate files, and using `cp' rather than `cat' in
> >> `tails-activate-winxp-theme'. This way, overzealous translators may
> >> find them with `find' (and we could even document it, if it's not
> >> documented yet). See what I mean? :)
> >>
> > I was trying to *only* fix the bug in camouflage mode. In 0.15 there
> > were .desktop files for these actions that were showing up in the
> > menus not only in camouflage mode. But that might indeed be better.
>
> I agree displaying these menu entries in camouflage mode only would be
> nice. That's indeed exactly why I suggested "using `cp' rather than
> `cat'" above (as in "cp from a non-standard location into
> /usr/share/applications/"). I'm sorry I was not clear enough. It is
> now too late to experiment with yet another implementation way, so
> that will be material for 0.18 if someone feels like it.
>
Well actually I don't see it as a problem to have these entries in
menus in all modes and not only with camouflage. I was just imagining
in the first place that you wouldn't want to merge a patch changing all
modes.
> > I was also trying to make these buttons show up straignt in the
> > "System" menu and not in "Administration" which seems me a bit wired
> > place to go to shutdown my computer.
>
> This, too, would be a nice improvement for Tails 0.18 :)
>
If I find how to do, it might be candidate.
> > Also, I fail to see the point of a custom "shutdown helper" applet,
> > which seems me to try to do the same that is implemented straight in
> > gnome-panel as "drawer":
>
> IIRC, I had tried the drawer approach, failed, and then suggested the
> helper way, but my memory may be failing, or perhaps I didn't try hard
> enough. But yeah, in any case, even if the applet is written already,
> and while it would be a bit sad somehow, replacing it with a simple
> drawer would simplify our codebase, and I would warmly welcome it!
> (Note: check that the drawer thing still works in GNOME3 Fallback.)
>
Well let's say these to might be candidate if I want some not urgent
thing to play with.
> Interpretation note: I'm sick, I'm very late to put a RC out, so I'm
> not exactly in the mood to review buggy bugfixes. Thanks for working
> on this, sorry for being a bit of a pain.
>
No problem, and thanks for managing this release.
Cheers
