Coordinating https://fedoraproject.org/wiki/Features/InitialExperience with firsboot, anaconda

[Miloslav Trmač]

Hello,
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)

Thank you,
    Mirek

[Jasper St. Pierre]

On Fri, Jun 15, 2012 at 12:36 PM, Miloslav Trmač  wrote:
> Hello,
> 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?

Read https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup#line-141
> Which settings/screens move between anaconda and firsboot/IE (and
>
> using what mechanism)?

There has always been a plan so that we will skip screens that 'an
installer' has marked as done. Some basic protocol like having a
marker '/var/lib/gnome-iniital-setup/done-pages/location' file is OK
by me.
> Which settings/screens happen both in firstboot and IE (and on which
>
> installation paths)?  What code will be shared?

No code will be shared. Talking to people involved in firstboot, they
cannot upgrade to GTK+3, as they have third-party modules from
customers they cannot break. The current goal has been to integrate
existing firstboot screens like third-party things using XEmbed
(GtkPlug/GtkSocket).
> Which settings will be governed by each desktop environment
>
> individually?

I don't understand the question.
> 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?

g-i-s has plans to set up:

* Keyboard layout / Language
 * EULAs
 * Timezone / clock
 * User account / enterprise login
 * Network
 * Online Accounts
> 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?

I'm quite sure g-i-s will not run on KDE spins.
> (and other things that I might have forgotten)
>
> Thank you,
>    Mirek

[Moray Henderson]

> From: Miloslav Trmač [mailto:[e-mail]]
> Sent: 15 June 2012 17:36
>
> ...
>  The integrated nature of IE goes against the "one installed system
> ...

That's quite a confusing acronym for the wider Information Technology world
;-)

Moray.
"To err is human; to purr, feline."

[Jaroslav Reznik]

----- Original Message -----
> Hello,
> 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.

Is it already known what's going to be part of Anaconda? Personally I
prefer no firstboot at all as it's causing a lot of troubles (we seen
a few before F17 release) and I like to see basic stuff settings in
Anaconda (with initial non-super user).

So I think - without knowing what's going to happen in Anaconda, it's
useless discussion right now. Maybe I missed this discussion, could
anybody from this team comment it?

Thanks
R.
> Thank you,
>     Mirek
> _______________________________________________
> kde mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/kde
> New to KDE4? - get help from http://userbase.kde.org

[Martin Sivak]

Hi,

our plan is to keep firstboot alive for OEM and possibly Live CD reasons. In the standard install scenario we will show the firstboot screens during package extraction and probably mark them as done. Firstboot will then show only the screens which weren't configured (if there are any).

Regarding the specific screens:

- Anaconda will have to keep setting the time and timezone to prevent bugs like https://bugzilla.redhat.com/show_bug.cgi?id=171187.
- We also plan on creating the user (root or wheel group member) during the package extraction step.

--
Martin Sivak
[e-mail]
Anaconda team / Brno, CZ

----- Original Message -----
> ----- Original Message -----
> > Hello,
> > 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.
>
> Is it already known what's going to be part of Anaconda? Personally I
> prefer no firstboot at all as it's causing a lot of troubles (we seen
> a few before F17 release) and I like to see basic stuff settings in
> Anaconda (with initial non-super user).
>
> So I think - without knowing what's going to happen in Anaconda, it's
> useless discussion right now. Maybe I missed this discussion, could
> anybody from this team comment it?
>
> Thanks
> R.
> > Thank you,
> >     Mirek
> > _______________________________________________
> > kde mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/kde
> > New to KDE4? - get help from http://userbase.kde.org
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Matthias Clasen]

On Fri, 2012-06-29 at 09:12 -0400, Martin Sivak wrote:
> Hi,
>
> our plan is to keep firstboot alive for OEM and possibly Live CD reasons. In the standard install scenario we will show the firstboot screens during package extraction and probably mark them as done. Firstboot will then show only the screens which weren't configured (if there are any).
>
> Regarding the specific screens:
> Anaconda will have to keep setting the time and timezone to prevent bugs like https://bugzilla.redhat.com/show_bug.cgi?id=171187.
> We also plan on creating the user (root or wheel group member) during the package extraction step.

Hi,

sorry for taking long to answer; a few questions to help further
coordination:

- Can we add an option to firstboot that lets us embed it into another
window (via xembed) ? That would really help us in maintaining support
for third-party firstboot screens with only a small compromise on the
initial-setup user experience. I think Jasper has been trying to get an
answer on this; he can probably provide a patch if needed.

- You mention firstboot will skip screens that have been 'marked as
done'. How is that going to be communicated from anaconda to firstboot ?
We may want to use this information in initial-setup as well.

- You say anaconda will create a user, but then you mention root, so
this is not entirely clear. Do you plan to have a fully-featured account
creation screen in anaconda, including network accounts ? I assume this
is going to be optional as well ?

[Chris Lumens]

> Can we add an option to firstboot that lets us embed it into another
>
> window (via xembed) ? That would really help us in maintaining support
> for third-party firstboot screens with only a small compromise on the
> initial-setup user experience. I think Jasper has been trying to get an
> answer on this; he can probably provide a patch if needed.

I've not looked at firstboot in quite a while, but yes I do think that
would be possible.
> You mention firstboot will skip screens that have been 'marked as
>
> done'. How is that going to be communicated from anaconda to firstboot ?
> We may want to use this information in initial-setup as well.

This hasn't been decided yet.  The firstboot-like screens on the second
hub of anaconda are currently targeted for F19, so I've not even started
to look at how this communication will be accomplished.
> You say anaconda will create a user, but then you mention root, so
>
> this is not entirely clear. Do you plan to have a fully-featured account
> creation screen in anaconda, including network accounts ? I assume this
> is going to be optional as well ?

Current newui anaconda does not include a place to set up a root
password - we're moving towards having just the user created during
installation to be set up in sudo and all that as well.  So yeah, we'll
have to create a user somewhere in anaconda.  The plan was to do that
off the second hub, and yes I think it was going to be pretty
fully-featured.

Everything off the second hub is planned as being optional to do within
anaconda.  Some of the things may be required to be done eventually,
though.  At least, you will need to create a user somewhere if you
expect to be able to log in.

- Chris