FS#24042 - {archweb} releng: make the clock options clearer

Attached to Project: Arch Linux
Opened by Ionut Biru (wonder) - Monday, 02 May 2011, 09:59 GMT
Last edited by Dan McGee (toofishes) - Thursday, 02 June 2011, 14:32 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Paul Mattal (paul)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Right now the options are:

* unchanged
* configured manually
* NTP

I usually select timezone+utc no NTP. I don't know if is unchanged or configured manually.


This task depends upon

Closed by  Dan McGee (toofishes)
Thursday, 02 June 2011, 14:32 GMT
Reason for closing:  Implemented
Comment by Dieter Plaetinck (Dieter_be) - Saturday, 07 May 2011, 13:27 GMT
hmm, so the user can do the following things:
* change region and/or timezone.
* change time. questions asked: UTC/localtime, manual or NTP.

that translates into the following options:
- default region/timezone. keep clock
- default region/timezone. change clock manually (UTC)
- default region/timezone. change clock NTP (UTC)
- default region/timezone. change clock manually (localtime)
- default region/timezone. change clock NTP (localtime)
- update region/timezone. keep clock
- update region/timezone. change clock manually (UTC)
- update region/timezone. change clock NTP (UTC)
- update region/timezone. change clock manually (localtime)
- update region/timezone. change clock NTP (localtime)


I'm aware this is a lot of options. But I don't want to cut the list: clock setting can be very tricky so I prefer specific feedback. And for the user/reporter it's not really a problem to have a longer list imho. We should probably also mention something like "Note that automatic installs only allow changing the region/timezone, aif has no code by default for automatic installs to change the clock"
Comment by Dieter Plaetinck (Dieter_be) - Tuesday, 17 May 2011, 16:25 GMT
Now the tests contain false successes for some clock options,
probably because the new options have some id's that were used by the old options.
But the old options were very coarse grained so are not sufficient to indicate success (or failure) of a specific new options. And the new options are not necessarily related to the previous ones anyway (other than having the same id's)
So the only solution is removing the clock feedback for all current testresults. However, when I try to edit through the admin pages, it says "this field is required"
Comment by Dan McGee (toofishes) - Tuesday, 17 May 2011, 17:49 GMT
Sure- that makes the whole test result invalid though, no? We can't violate DB constraints and make things optional.

I'm not sure what you want me to do here. It's up to you to decide whether the data is fully valid or not, but I can't override the database or the application in making fields nullable unless you want to do that for all future tests too.
Comment by Dieter Plaetinck (Dieter_be) - Tuesday, 17 May 2011, 17:54 GMT
I'll just email the original submitters and ask for clarification and I'll update for them.
If I don't get a timely response, I'll remove the results.
Comment by Dan McGee (toofishes) - Tuesday, 17 May 2011, 17:56 GMT
OK, sounds good. Thanks for the quick response. The original to new ID mapping can be gleaned from http://projects.archlinux.org/archweb.git/commit/?id=ef7cccf85df1c8908661f3a9525051b7e9d8d3a1

Loading...