Coordinating https://fedoraproject.org/wiki/Features/InitialExperience with firsboot, anaconda
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
On Fri, Jun 15, 2012 at 12:36 PM, Miloslav Trmač mitr@volny.cz 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
----- 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 kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
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 msivak@redhat.com 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 kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
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 ?
- 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
-
Chris Lumens -
Jaroslav Reznik -
Jasper St. Pierre -
Martin Sivak -
Matthias Clasen -
Miloslav Trmač