Hi, On Fri, 15 Feb 2013 18:52:39 +0100 intrigeri <[email protected]> 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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
