Friendly reminder that 9 February is the deadline for any changes to be made in the Spin. We can revisit in our next meeting.
-- Cheers, Justin W. Flory (he/him) https://jwf.io Sent from ProtonMail mobile
-------- Original Message -------- On Jan 26, 2021, 08:36, Ben Cotton < bcotton@redhat.com> wrote:
The change complete (testable) deadline for Fedora 34 changes is Tuesday 9 February. At this point, changes should be in a testable state. Please indicate this by setting the tracker bug for your change to MODIFIED.
Other upcoming schedule milestones: * 2021-02-09 — Fedora 34 branches from Rawhide * 2021-02-23 — Change completion deadline (100% code complete) * 2021-02-23 — Beta freeze begins
For more information, see the schedule[1]
[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: [https://fedoraproject.org/wiki/Mailing%5C_list%5C_guidelines%5D%5Bhttps_fedo...] List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
[https_fedoraproject.org_wiki_Mailing_list_guidelines]: https://fedoraproject.org/wiki/Mailing_list_guidelines
Good to know. afaik we should have thunar or any file browser of choice and probably check about xss-lock and we will be ready to ship.
Br,
El mié, 27 ene 2021 a las 19:56, Justin W. Flory (foss@jwf.io) escribió:
Friendly reminder that 9 February is the deadline for any changes to be made in the Spin. We can revisit in our next meeting.
-- Cheers, Justin W. Flory (he/him) https://jwf.io Sent from ProtonMail mobile
-------- Original Message -------- On Jan 26, 2021, 08:36, Ben Cotton < bcotton@redhat.com> wrote:
The change complete (testable) deadline for Fedora 34 changes is Tuesday 9 February. At this point, changes should be in a testable state. Please indicate this by setting the tracker bug for your change to MODIFIED.
Other upcoming schedule milestones:
- 2021-02-09 — Fedora 34 branches from Rawhide
- 2021-02-23 — Change completion deadline (100% code complete)
- 2021-02-23 — Beta freeze begins
For more information, see the schedule[1]
[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro... _______________________________________________ Fedora i3 SIG mailing list -- i3wm@lists.fedoraproject.org To unsubscribe send an email to i3wm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/i3wm@lists.fedoraproject.org
Eduard Lucena x3mboy@fedoraproject.org writes:
Good to know. afaik we should have thunar or any file browser of choice and probably check about xss-lock and we will be ready to ship.
While I like xss-lock, I don't think that we should ship it: it's been untouched since 2014.
Having a file browser sounds like a good idea. I've been using pcmanfm for years and am quite happy with it, but I have no objections against Thunar or anything other, provided it gets the job done and doesn't pull in a bazillion extra packages.
Cheers,
Dan
I also want to rescind my suggestion to include xss-lock, and recommend not to include thunar and firefox (some users are starting to go the flatpak direction so don't want stuff such as firefox on the host - I might be one of them, but don't know yet).
After reading through some responses to an earlier post where I suggested adding a couple extra things I have personally swung completely the other way.
My current thinking is that the base spin should only include the i3 sanctioned utilities (i3lock, i3status, etc.) and a terminal (seems uxrvt has already been selected for this).
Any experienced i3 users are likely opinionated already (and anything extra in the base spin could probably be stepping on their toes).
Any new i3 users would probably find a very limited package set underwhelming (when compared to the other spins). Whereas no packages with an explanation of why, and how to proceed might produce a better experience for them.
The Qubes installer (which is also Anaconda) has a "SOFTWARE SELECTION" section. Although it currently only has one option (xfce de), it seems that they intend to ultimately allow the user to select different desktop environments in the future (see screen shot in the "Installation summary" section at https://www.qubes-os.org/doc/installation-guide/).
Does anybody know how to add this "SOFTWARE SELECTION" section to the i3 spin Anaconda installer? Then the base i3 spin could be minimal, and there could be a couple options with progressively more stuff thrown in such as:
* nothing - don't install anything extra * minimal - add things such as xss-lock (ie. things recommended in the default i3 config) * functional - add things that a typical user would want (ie. thunar, firefox, bluetooth) * full - rice it up (ie. music player, calendar, etc.)
Also, I have been experimenting with using flatpaks instead of .rpm where it makes sense, and so far the results seem pretty good. I guess the use of flatpaks will trend up over time. But it does introduce the complexity to spins regarding what would be an rpm (ie. i3status, xss-lock, probably thunar, etc. - basic utilities that make the system work) and what should be flatpak (ie. firefox, music player, etc. - desktop apps that the user interacts with for work or amusement). Is there even a way to install flatpaks during install? Is this something that should be considered, or should flatpaks continue to be completely ignored in favor of a 100% .rpm install?
Casey
On 1/28/21 4:13 PM, Dan Čermák wrote:
Eduard Lucena x3mboy@fedoraproject.org writes:
Good to know. afaik we should have thunar or any file browser of choice and probably check about xss-lock and we will be ready to ship.
While I like xss-lock, I don't think that we should ship it: it's been untouched since 2014.
Having a file browser sounds like a good idea. I've been using pcmanfm for years and am quite happy with it, but I have no objections against Thunar or anything other, provided it gets the job done and doesn't pull in a bazillion extra packages.
Cheers,
Dan
Fedora i3 SIG mailing list -- i3wm@lists.fedoraproject.org To unsubscribe send an email to i3wm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/i3wm@lists.fedoraproject.org
Casey Witt kcwitt@gmail.com writes:
I also want to rescind my suggestion to include xss-lock, and recommend not to include thunar and firefox (some users are starting to go the flatpak direction so don't want stuff such as firefox on the host - I might be one of them, but don't know yet).
After reading through some responses to an earlier post where I suggested adding a couple extra things I have personally swung completely the other way.
My current thinking is that the base spin should only include the i3 sanctioned utilities (i3lock, i3status, etc.) and a terminal (seems uxrvt has already been selected for this).
Any experienced i3 users are likely opinionated already (and anything extra in the base spin could probably be stepping on their toes).
An experienced i3 user is not really the target audience of this spin (imho). They'll probably just grab the server installation ISO and run their installation script/playbook or will even deploy their own prebuild image.
Any new i3 users would probably find a very limited package set underwhelming (when compared to the other spins). Whereas no packages with an explanation of why, and how to proceed might produce a better experience for them.
The Qubes installer (which is also Anaconda) has a "SOFTWARE SELECTION" section. Although it currently only has one option (xfce de), it seems that they intend to ultimately allow the user to select different desktop environments in the future (see screen shot in the "Installation summary" section at https://www.qubes-os.org/doc/installation-guide/).
Does anybody know how to add this "SOFTWARE SELECTION" section to the i3 spin Anaconda installer? Then the base i3 spin could be minimal, and there could be a couple options with progressively more stuff thrown in such as:
- nothing - don't install anything extra
- minimal - add things such as xss-lock (ie. things recommended in the default i3 config)
- functional - add things that a typical user would want (ie. thunar, firefox, bluetooth)
- full - rice it up (ie. music player, calendar, etc.)
No idea if that's possible, but it would be nice.
Also, I have been experimenting with using flatpaks instead of .rpm where it makes sense, and so far the results seem pretty good. I guess the use of flatpaks will trend up over time. But it does introduce the complexity to spins regarding what would be an rpm (ie. i3status, xss-lock, probably thunar, etc. - basic utilities that make the system work) and what should be flatpak (ie. firefox, music player, etc. - desktop apps that the user interacts with for work or amusement). Is there even a way to install flatpaks during install? Is this something that should be considered, or should flatpaks continue to be completely ignored in favor of a 100% .rpm install?
I am not 100% sure, but I don't think that Anaconda allows you to install flatpaks (searching for flatpak in the docs yields no results[1]).
Cheers,
Dan
Footnotes: [1] https://anaconda-installer.readthedocs.io/en/latest/search.html?q=flatpak&am...
Hi Casey and Dan,
Does anybody know how to add this "SOFTWARE SELECTION" section to the i3
spin Anaconda installer? Then the base i3 spin could be minimal, and there could be a couple options with progressively more stuff thrown in such as:
- nothing - don't install anything extra
- minimal - add things such as xss-lock (ie. things recommended in the default i3 config)
- functional - add things that a typical user would want (ie. thunar, firefox, bluetooth)
- full - rice it up (ie. music player, calendar, etc.)
No idea if that's possible, but it would be nice.
I'm working on this but pointing to F36. Why? Because we have a lot to do for F35 and it won't be feasible.
If anyone can take the task outside the "core" team (there is no such thing, but only 5 people are constantly showing in meetings)
Also, I have been experimenting with using flatpaks instead of .rpm
where it makes sense, and so far the results seem pretty good. I guess the use of flatpaks will trend up over time. But it does introduce the complexity to spins regarding what would be an rpm (ie. i3status, xss-lock, probably thunar, etc. - basic utilities that make the system work) and what should be flatpak (ie. firefox, music player, etc. - desktop apps that the user interacts with for work or amusement). Is there even a way to install flatpaks during install? Is this something that should be considered, or should flatpaks continue to be completely ignored in favor of a 100% .rpm install?
I am not 100% sure, but I don't think that Anaconda allows you to install flatpaks (searching for flatpak in the docs yields no results[1]).
AFAIK no. Only way should be doing something similar to Kionite, rebasing Silverblue and from there build the image.
Again, thanks for taking the time to comment, every comment enrich us.
Br,
Hi Eduard,
Does anybody know how to add this "SOFTWARE SELECTION" section to
the i3
spin Anaconda installer? Then the base i3 spin could be minimal,
and
there could be a couple options with progressively more stuff
thrown in
such as:
- nothing - don't install anything extra
- minimal - add things such as xss-lock (ie. things recommended
in the
default i3 config)
- functional - add things that a typical user would want (ie.
thunar,
firefox, bluetooth)
- full - rice it up (ie. music player, calendar, etc.)
No idea if that's possible, but it would be nice.
I'm working on this but pointing to F36. Why? Because we have a lot to do for F35 and it won't be feasible.
If anyone can take the task outside the "core" team (there is no such thing, but only 5 people are constantly showing in meetings)
Do you have a starting point for this? I looked at the Anaconda docs, kickstart docs, Qubes anaconda patches, and some CentOS docs (which also seem to have this software selection feature in their version of the anaconda installer). I also looked through the i3 spin kickstart files, and I can't work out where the "software selection" feature comes into play. I can't even work out whether it is an anaconda feature, or a kickstart feature, or even necessarily what the division of responsibility is between anaconda and kickstart.
Also, I have been experimenting with using flatpaks instead of .rpm where it makes sense, and so far the results seem pretty good. I
guess
the use of flatpaks will trend up over time. But it does
introduce the
complexity to spins regarding what would be an rpm (ie. i3status, xss-lock, probably thunar, etc. - basic utilities that make the
system
work) and what should be flatpak (ie. firefox, music player, etc.
desktop apps that the user interacts with for work or amusement).
Is
there even a way to install flatpaks during install? Is this
something
that should be considered, or should flatpaks continue to be
completely
ignored in favor of a 100% .rpm install?
I am not 100% sure, but I don't think that Anaconda allows you to install flatpaks (searching for flatpak in the docs yields no results[1]).
AFAIK no. Only way should be doing something similar to Kionite, rebasing Silverblue and from there build the image.
I think I would support making a Silverblue spin - but also want to absolutely vote against naming it anything other than a "Silverblue i3 spin" - the "spin" terminology was a great idea and makes clear to everybody what the spins are. I am incredibly fatigued by the fancy names people are giving things these days that obscure what the thing actually does. Anyway, probably best to focus on Silverblue later after working out all wrinkles for the current spin.
Cheers, Casey
Hello i3wm sig,
Does anybody know how to add this "SOFTWARE SELECTION" section to
the i3
spin Anaconda installer? Then the base i3 spin could be minimal,
and
there could be a couple options with progressively more stuff
thrown in
such as:
- nothing - don't install anything extra
- minimal - add things such as xss-lock (ie. things recommended
in the
default i3 config)
- functional - add things that a typical user would want (ie.
thunar,
firefox, bluetooth)
- full - rice it up (ie. music player, calendar, etc.)
No idea if that's possible, but it would be nice.
I'm working on this but pointing to F36. Why? Because we have a lot to do for F35 and it won't be feasible.
If anyone can take the task outside the "core" team (there is no such thing, but only 5 people are constantly showing in meetings)
I asked about this (installation groups) in the #anaconda freenode irc chat and user mkolman advised:
the Fedora live spins are configured to run Anaconda in a mode where
it just rsyncs
the image content to the harddrive it just takes the rootfs content
from the live
image itself and rsyncs it to the storage layout that has been
configured by the
user in Anaconda by doing it this way user can try the Fedora image
out without
installing and will get 100% the same thing after the installation
while needing
all the data just once instead of live image + data to install and
the whole thing
is also independent on network connectivity in theory the Anaconda
on the live
image is still the same codebase as the one on the boot iso which
can install from
package repositories (and this supports groups via comps) but this
is simply not
supported and tested at all and not user visible at all
-
Casey Witt -
Dan Čermák -
Eduard Lucena -
Justin W. Flory