Hi John,
On 08/05/2009 21:17, John Leser wrote:
> Hi folks,
>
> I'm sending this out to close the loop on some hallways discussion
> earlier today regarding how existing NWAM 0/.5 state will be handle when
> the system is upgraded to phase 1.
>
> Prior to our discussion, the plan was that during an upgrade to NWAM
> 1.0, existing NWAM state would migrated into the User NCP, and the User
> NCP would be enabled after the upgrade. This differs from a newly
> installed system, which starts out with the Automatic NCP enabled.
>
> Thus, we end up with a set of users who's systems are running with the
> User NCP, just because they happened to get to NWAM 1.0 via upgrade
> rather than fresh install. AFAIK, this is independent of whether they
> ever customized their previous NWAM configuration through the GUI or by
> editing the llp files. This is a problem for a number of reasons, most
> importantly:
>
> * Users end up with non-default NWAM 1.0 behavior, having likely never
> expressed a desire for non-default behavior.
>
> * It is a significant, unnecessary difference in system state/behavior
> between freshly installed and upgraded systems.
>
> * If users might have either Automatic or User NCUs active for such
> an unrelated reason as install method, the line between the User and
> Automatic NCP becomes blurred to the point where the distinction is not
> helpful.
>
> With phase 1.0, I think we really, really want the Automatic NCP to work
> for most run-of the mill laptop/desktop use cases. Due to a variety of
> factors, it is not possible to reliably determine if a user ever
> modified the NWAM 0/.5 configuration, so we cannot base NCP selection or
> upgrade strategy on whether the old environment was customized.
>
> Having outlined the concerns with the current method, the solution we
> are now considering for upgrades is:
>
> 1. At upgrade time, migrate existing NWAM state into the User NCP.
> 2. Always activate the Automatic NCP after an upgrade.
I think that this makes sense, although I do think that some logic could tell if
the upgrade is different - mainly by generating a new User NCP, and comparing it
to the Automatic NCP - if they are the same use the Automatic NCP.
The only difficulty here is if they have priority values but the same order
(when sorted) - so the order is all that should be considered not the actually
value - i.e.
i/f prio
bge0 0
ath0 1
would be the same as
i/f prio
bge0 1
ath0 5
I don't think would be too unreasonable as an upgrade logic.
> 3. At first interaction with the NWAM GUI, inform the user that the
> previous configuration has been saved in into the User profile, provide
> information about how to activate that NCP, but encourage
> trying/sticking with the Automatic profile.
>
> 4. Augment #3 with release notes/other documentation.
>
> The exact manner and wording of step 3. will be critical. Darren, I
> don't know if you have any suggestions for how best this can be handled
> through the GUI.
This would sound like a dialog on first run of the properties editor, is that
what you're thinking?
The main concern I would have is that we are telling people things that they may
simply not care about - and we'd likely have to do this for all users of a
system, that's why I would prefer we at least try to ascertain if the switch is
really necessary.
Calum, and ideas here?
Thanks,
Darren.
