Re: Not sure about recent change in tzsetup
(I'll be dropping private CCs from further replies unless you request them)
On Friday 13 November 2009, Colin Watson wrote:
> > Right, and this means that you introduce a significant inconsistency
> > in the functionality offered to users installing at default prio who
> > happen to select a country with multiple time zones versus a single
> > time zone.
>
> It's an inconsistency, but not all inconsistencies are worse than
> nothing.
IMO offering a large set of users less functionality than others is
something to be avoided.
> Besides, it's not as if the extra question you're relying on
> for your argument in localechooser is asked outside expert mode ...
1) that has nothing to do with your introducing an inconsistency
2) that's why my proposal lower down in this mail and my new proposal in
my earlier mail today
> Actually, personally I think that it wouldn't hurt to promote
> tzsetup/selected to high priority. It was medium at least in part
> because it didn't offer any additional flexibility, but now it does.
That would be a better implementation. However, it would then be even
better to just drop the tzsetup/selected question and just ask time/zone
of everybody, as I did in my UTC patch. Users in countries with one
timezone would then simply get e.g:
Europe/Amsterdam
other
> > My viewpoint is that you're solving the problem in the wrong place.
> > The problem was a limitation in localechooser, which is now resolved.
>
> I don't agree that you have resolved this adequately. Any interface that
> involves innocent (non-expert) users having locale strings inflicted on
> them is not really fit for purpose.
See the new proposal in my other mail.
> I'm also not particularly happy with the obvious alternative, which is
> effectively to ask the country question twice with slightly different
> semantics.
IMO that is the better solution though.
> The only purpose for asking which country you live in (as
> opposed to which country's localisation conventions you want) is to
> select an appropriate timezone;
You're forgetting that it also determined the default mirror country.
Admittedly it's easy to select a different country there, but still.
> as such, this operation logically fits
> in tzsetup, not in localechooser. Furthermore, we should just get on
> with it and let the user choose the right timezone rather than making
> them jump through hoops by selecting the right country followed by the
> right timezone.
IMO it's simply not that obvious to users what the "right" country is. For
me the most natural answer when asked to select a country is where I live.
> At least if this all lives in tzsetup it's trivial to go back and
> forward if you make a mistake. Artificially splitting it up between
> localechooser and tzsetup makes it awkward for the user to do so (when
> you find yourself wanting to add template text telling the user to go
> back to the main menu and select a different item there in order to get
> the option you want, it's a good sign that you've probably made a design
> error).
I only suggested the addition in the template as a hint for users who are
so used to working around the current limitation in localechooser that
they select the wrong country. The new descriptions in localechooser
should result in new users getting it right the first time.
> In addition, localechooser is memory-constrained (since it lives in the
> initrd) in a way that tzsetup is not so much. As such, I'd have thought
> you'd be in favour of moving things *out* of localechooser when
> possible.
That reasoning is not correct. There are two separate, but related issues:
- initrd size
- memory usage
initrd size is relevant for general reasons like download size of
installation images, and is a real constraint for some architectures like
sparc (when netbooting) and arm.
Memory usage is an issue for everything that happens before swap is
activated during partitioning.
And as (almost) all udebs get loaded during anna, their size is very much
relevant when it comes to how well we support systems with little memory
(not only ancient x86 systems, but now mainly embedded devices).
In general *all* templates, and especially translated ones are expensive
when it comes to memory usage. Only how much (additional) memory
components require to *run* stops being an issue after swap is activated.
So, for that reason adding this huge template really is undesirable.
relatively minor changes in size of the localechooser script are a much,
much lower cost.
> > I'm currently considering the following additional changes:
> > - revert your patch: with localechooser in SVN it's no longer needed
>
> I don't want to get into a revert war. Please do me a favour and don't
> start one ... This attitude really frustrates me.
How is it a revert war when it is done after proper discussion? I suggested
reversion as part of an alternative solution, which is a lot different
from "I don't like this change, I'm reverting it without bothering to tell
the original committer". I even bothered to CC you on my original mail to
make sure you did not miss it.
> > - add a para to the description of time/zone saying something like:
> > "If the desired time zone is not listed, then please go back to
> > the step "Choose language" and select a country that uses the
> > desired time zone (the country where you live or are located)."
>
> Going back this far in the installer doesn't really work all that
> nicely.
Technically and functionally it works fine at this stage. It only becomes a
problem after base-installer has been started.
> I recommend against this. In any case, this is unreasonable -
> it's asking the user to take manual action when the installer could just
> let them do what they want (the equivalent of saying "please run this
> command to recover" rather than just doing it).
See my comment above: it's only a hint for users who are too used to making
the "wrong" choice.
> I do not think that it particularly helps users to insist that they be
> aware of and honour a tight binding between countries and time zones in
> order to make their computer keep the right time. We should be more
> flexible than that. Good user interfaces let the user do what they need
> to do rather than making them read the software's mind up-front and
> effectively punishing them by sending them back through convoluted
> channels when they fail to do so.
Good interfaces guide their users in making the correct choice. By asking
users to select the country "in which they live" localechooser now does
that. My opinion remains that this is an issue that needs to be resolved
in localechooser.
Reply to: