#857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience
Closed None Opened 7 years ago by rbergero.

For 2012-06-04 fesco meeting.

Agreed to defer discussion a week

The following was posted to the Fedora devel list. It asks some interesting questions and I'd like to track them so they don't get missed at the meeting tomorrow:

Oron Peled wrote:
Being a KDE user, this feature page was my first encounter with
this interesting proposal. As a result I also followed the mentioned:
and related:

I wanted to raise 3 separated issues not mentioned in Fedora feature page:
1. There's no mention of other desktops:
* For example, let's assume KDE has no equivalent feature.

* We still need the KDE (or other desktops) spin to have during
  the first boot a functionality (but not necessarily the same look)
  of "firstboot"

* So IMO, this feature should explicitly mention how it intends to
  treat other desktops (e.g: booting with KDM, LXDM) regarding basic
  mandatory configuration (e.g: creating new user, setting timezone)
  1. The GUI seems to bundle system-wide settings with per-user ones:

    • What if other GNOME users would like to use the same modern
      GUI to enroll into their online accounts on their first login?

    • It seems to me a lot better not to mix "first boot" functionality
      with "first login" functionality.

    • Even if the design people want to pack them into a single "integral"
      UI, the per-user part should still be designed to be operational
      by itself on "first login" of any user (not only the one that
      installed the system).
      [obviously, a new user should have her chance to take the "tour"
      on first login even if the system was installed 5 months ago by
      someone else]

  2. No mention of kickstart integration:

    • Would we still be able to have fully automatic install?
      [without the first user being bothered with system level
      stuff like networks, timezones, etc.]

I think these 3 aspects should be marked in the feature page and with
proposed strategy to handle each of them.

Thanks (maybe it's all taken care for, and I simply missed it in
the feature page...)

FESCO decided to postpone voting 1 week in order that concerns about firstboot's future might be addressed and clarified.

I spoke with anaconda & firstboot maintainers. So, what I get is:
* anaconda could do some part of firstbook work
* IE has no code? So it's not sure which part will be done in anaconda and which in IE.
If someone has more precise information, then please share them.

Wouldn't be better to make the plan for longer time period? After changes in anaconda will be known all DE could decide their next steps. DE can use simplified firstboot or wrote something else. IE shouldn't be replacement of firstboot, but it's not sure what will happened to firstboot.

I guess we need to speak about anaconda features to plan for all SIGs in this case.

I'm not really sure what you're asking/getting at in comment #4.

I spoke with David Cantrell last week. The current plan, as far as anyone knows, is that anything that isn't the Desktop spin will still use firstboot and firstboot is still being maintained in F18. That includes the install DVD, other DE spins, etc.

Apparently anaconda developers didn't even know about this feature (I'm afraid I have asked the firstboot maintainer, but not anaconda), and they plan relevant changes to the UI.

I have sent the following to the feature owners and anaconda-devel and kde mailing lists, to hopefully involve everyone in the conversation and arrive at a common and widely-understood plan. Please notify any other relevant teams I might have forgotten, we've postponed the feature to ask for more information twice now, let's try to do better in the future.

it seems that not all relevant parties have been talking to each other; if anyone else should be involved, please add them.

In short, a new Fedora feature https://fedoraproject.org/wiki/Features/InitialExperience was proposed, replacing firstboot for the GNOME spin (only) and integrating per-system and per-user configuration.

The original suggestion was for non-GNOME spins (including the DVD installation) would continue using firsboot.

Now it turns out that anaconda plans to do more setup during the initial installation (including setting up the clock and adding an initial user), perhaps making all of firstboot unnecessary on non-live installations. OTOH for live-{CD,DVD} installations, the same clock/user screens would be displayed in firstboot, sharing the code; if "initial experience" plans to support firstboot screens, this (and the presumed firstboot module API changes) would affect it.

Can you all talk to each other and figure out a definite plan, please? The integrated nature of IE goes against the "one installed system with multiple installed desktop environments" concept, which is sort of acceptable as long as both IE and firsboot have active maintainers, but asking the user about the same things both in anaconda and IE wouldn't do.

  • Which settings/screens happen in anaconda?
  • Which settings/screens move between anaconda and firsboot/IE (and using what mechanism)?
  • Which settings/screens happen both in firstboot and IE (and on which installation paths)? What code will be shared?
  • Which settings will be governed by each desktop environment individually? How does the transition between per-system and per-user settings happen if IE doesn't want the user to log in during the process?
  • Which parts of the GNOME stack will have to be installed on non-GNOME spins, or from the installation DVD when installing a non-GNOME desktop only?
    (and other things that I might have forgotten)

Replying to [comment:6 mitr]:

Apparently anaconda developers didn't even know about this feature (I'm afraid I have asked the firstboot maintainer, but not anaconda), and they plan relevant changes to the UI.

Given that I've sat in meetings where this was discussed between the desktop team and the anaconda team leads at RH, I find this odd.

This Feature was approved at the 2012-06-18 meeting.

Login to comment on this ticket.