Hi,
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.
> 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.
> 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.
>> 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.
> 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 :)
> 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.)
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.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
