Bug 136725

[ ACK, the code is from s-c-date ]

NTP configuration _is_ overly complex ;-).

- "Use Local Time Source": this is if you have a locally attached
authoritative time source (a "reference clock" in NTP documentation
jargon), like an RF time receiver, and you want to use that. It puts
"server 127.127.1.0" into ntp.conf

- "Enable NTP broadcast": Broadcast for an NTP server on the local
subnet(s), puts "broadcastclient" into ntp.conf

I agree that these options warrant tooltips/help/some mor guidance for
the user not knowing about NTP. I could also hide these behind some
"Show advanced options" though you probably don't want that as well
;-). The problem is that when we disallow access to these options
completely, people start to ask questions why it's in s-c-date and not
in firstboot.

Regarding multiple servers and how they're configured: Trust me, the
code is less complex (and buggy, hopefully) than it was when you could
only configure one and it had to deal with e.g. admins configuring
multiple servers manually in ntp.conf. Doing it like in
gnome-keyboard-properties isn't quite feasible because the user needs
to be able to add his local NTP server to the list. Having an extra
entry line to add these would be even more complex than what we have
now. If youhave an idea how to do this differently without losing
functionality, I'd like to know. Perhaps putting the first entry into
the list when the user enables NTP would be a starter?

If NTP configuration really was overly complex, it wouldn't belong
in firstboot. But the reason it does belong there is:

 - Simple configurations work for most users. If I recall correctly,
   XP enables it by default pointed to a MS server. I've been
   told that OS X, it's off by default by default but one click
   to configure.

 - It really is a big win for the user.

But you are saying that "NTP configuration is complex" because:

 - Users might have a locally attached authoritative time
   source. (0.1%, 0.01%?)

 - The user might have a NTP broadcasting server on the network
   (if they have a sysadmin to set that up, they probably
   have a sysadmin to kickstart their box...)

 - The user might want to set up multiple upstream servers
   (for better robustness? to improve accuracy by a couple
   of milliseconds)

I'm not happy about having this complexity in s-c-d, but it
basically doesn't hurt a lot, because the user running s-c-d
says "I care about my date/time". But in firstboot the user
basically is being asked to figure out what a authoritative
time source is before they can log into their shiny new
OS the first time.

I don't see any reason to worry about questions people ask 
why things are in s-c-date and not in firstboot. The answer
is simple:

 "The purpose of firstboot is to set up a machine to be
  usable; putting every possible option in it isn't possible"

About the multiple servers questions - generally we've found that

 [ Controls configuring item ] + [ list of items ] + Add

is a confusing combination of controls. What we've traditionally
done in GNOME is to have Add fire up a separate dialog. 

Really, probably the best way forward here for FC4 to RHEL5 is to
work with the UI folks to come up with designs for the firstboot
and s-c-d.

Hmm, what about:

Don't show these options in firstboot or hide them behind "Show
more/advanced/complex configuration options". Should be doable and the
backend code is ready for this, as if it is already configured, it
leaves the option in place. If the corresponding UI widget is hidden,
it should still leave an option set in place.

I'm a bit confused about "What we've traditionally done in GNOME is to
have Add fire up a separate dialog" -- how does that fit within your
former example of gnome-keyboard-properties, i.e.:


Selected options:             Available options:
Option 1              Add     Option 3
Option 2              Remove
Option 4

(I've left out Up and Down buttons, I don't think they're needed in
the context of NTP).

One idea would be to have a New button which inserts a new line in
"Selected Options", similar to adding a new folder in Nautilus or the
new file selector. What do you think?

I've added tooltips for the options in CVS so users have at least an
idea what they mean: BTW I'm still waiting on feedback on hiding the
more esoteric options as well as the redesign of the NTP server
list/interface.

My tendency for firstboot would not be to show them at all.
Though the multiple server bit is likely harder to deal with that
way. What I'd probably do for that would be to allow only a single
server in firstboot, unless the ntp.conf *already* has multiple
servers in it. (Which is a weird edge case.)

I was making an alternate suggestion for the server selection
based on the feedback that the keyboard-properties style didn't
work. For infrenquently used controls (and how often do people
configure ntp?) clarity is a lot more important than speed.
So, that's basically why I'm suggesting the separate-dialog 
style. There is no ambiguity in how you interact with it - 
it's immediately obvious. 

Owen and Seth, please take a look at current system-config-date (1.7.99.0).
While this doesn't address your problem with multiple NTP servers, I think the
interface is more in line with what we have elsewhere, i.e. instead of text
entry -> add button -> list gets extended we have only the add button which
doesn't pop up dialog but inserts a new entry labeled "New NTP server" which
gets selected to be subsequently edited by the user (very much like the file
chooser or nautilus IMO).

Please let me know what you think.

No answer is still an answer ;-). Closing due to inactivity.