The following proposal comes out of the discussion at this weeks Server SIG
meeting[1]
Fedora Server will have:
* / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
* SWAP will continue to be calculated automatically based on available RAM on
the system
* All unused space will be assigned to a volume group and available to be
assigned to new partitions or extend existing partitions.
* Anaconda will continue to handle the appropriate EFI and /boot settings
We also discussed during the meeting whether we should have a separate /var
partition by default, but the general sense was that we might be better served
by developing a mechanism to allow partitions to be split from existing mount
points, which would be more flexible going forward.
As we did not have quorum in the meeting by the point we got to this proposal,
I'm taking it to the list for discussion and votes.
For the record, the current behavior of the partitioning scheme is for / to be
given up to 50 GiB of space and then any remaining space after that is assigned
to a separate /home partition.
[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-03-15/serversig.201…
On Tue, 2018-02-27 at 09:02 -0500, Josef Ridky wrote:
> Hi folks,
>
> I would like to inform you, that net-snmp package will use Python3 package instead of Python2.
> With this change, python2-net-snmp package will be renamed to python3-net-snmp package.
> This change will be applied in Fedora Rawhide and Fedora 28.
>
> I would be glad for any feedback.
This sounds a bit odd. What do you mean by 'renamed', exactly? It's not
as if you can just have python3-net-snmp provide and obsolete python2-
net-snmp ; any dependency which actually needs the python2 one is not
going to keep working with this change.
Do you just mean the python2-net-snmp package will go away and anything
using it has to migrate to python3-net-snmp? If so, have you actually
looked at the things that use it and considered how difficult it will
be to migrate them?
I see, for instance, '389-ds-base-owner' CCed on this mail; if 389-ds-
base depends on python2-net-snmp it is not at all going to be
acceptable to just throw it away without regards to whether 389-ds-base
can reasonably migrate to python3 right now. That is a core component
of one of our release-blocking deliverables, Fedora Server.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
I would like to ask for a review of Release blocking deliverables [1]
for F28 release delivered by Server SIG/WG. Please let me know in case
of missing images, or in case the "blocking" status has changed since
the last release.
[1] https://fedoraproject.org/wiki/Releases/28/ReleaseBlocking#Server
Thanks,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
================================================================
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2018-02-13)
================================================================
Meeting started by sgallagh at 21:00:06 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-1/2018-02-13/serversig.2…
.
Meeting summary
- ---------------
* Roll Call (sgallagh, 21:00:06)
* Agenda (sgallagh, 21:04:30)
* Agenda Item: Modular Repo By Default (sgallagh, 21:04:34)
* Agenda Item: Module-creator Conscription (sgallagh, 21:04:37)
* Modular Repo By Default (sgallagh, 21:07:02)
* AGREED: Fedora Server Edition will ship the Fedora Modular
repository configuration as enabled and available by default. (+4,
0, -0) (sgallagh, 21:09:44)
* Module-creator Conscription (sgallagh, 21:09:53)
* Plan of action is to approach targeted groups and assist them with
making module streams for F28 Beta. Documentation will be improved
in parallel and we will make a general availability announcement for
module packaging at the end of February. (sgallagh, 21:29:36)
* Next Meeting (sgallagh, 21:32:49)
* ACTION: sgallagh to send out a new meeting time request (sgallagh,
21:36:16)
* Open Floor (sgallagh, 21:36:22)
Meeting ended at 21:43:09 UTC.
Action Items
- ------------
* sgallagh to send out a new meeting time request
Action Items, by person
- -----------------------
* sgallagh
* sgallagh to send out a new meeting time request
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (62)
* langdon (12)
* nirik (10)
* zodbot (8)
* mjwolf (6)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.1.1
Comment: https://www.mailvelope.com
wkYEAREIABAFAlqDXEwJEHolVWI2uqOjAAAp3QCfaemwt3NHIiF9rO0Z9i5X
CZAnmFsAn1jHYzcMiSvSKFiKv0CqaR/0LVbb
=/T9h
-----END PGP SIGNATURE-----
It's become apparent that attendance at the Server SIG meetings is *way*
down. I think part of that is due to its extreme inconvenience for those in
European timezones. So I'm sending out a WhenIsGood [1] to try to find a
more optimal time for the weekly meeting. If you feel that you are likely
to want to attend, please respond with the times that would work for you.
The responses are public [2]. Let's see what we can find.
[1] http://whenisgood.net/4dyzhts
[2] http://whenisgood.net/4dyzhts/results/xg9a3ym
We haven't had a meeting in a while and there are a few things to discuss.
First, I'd like us to formally vote on whether Server Edition will ship
with the modular repository enabled by default. I assume the answer will be
"yes", given our previous attempts to go *fully* modular, but I'd like to
have the vote on record.
Second, I'd like to discuss starting a campaign to have people work on
creating modules to ship alongside Fedora 28 when it releases. I'm leaning
towards making the following proposal on the general Fedora mailing list,
once we have a couple last hiccups worked out in the build and compose
process (hopefully this week):
Hello, Fedorans! As I'm sure most of you are aware by now, Fedora 28 will
be shipping with Modularity as an add-on repository[1]. In order to ensure
that this effort is successful, we're going to need a set of real, usable
modules in the repository at launch time. What I would like to see is this:
if you have any package that is making a major-version jump between Fedora
27 and 28 (and for which you will be continuing to support the older
version on Fedora 27 anyway), I'd like to ask you to build a module stream
for that older version to be usable in Fedora 28.
As a real-world example, I have created a set of module streams for Node.js
in Fedora 28. We will be shipping Node.js 8.x in the standard RPM
repository (as it is the latest LTS release and will be supported beyond
the lifetime of Fedora 28). Because I also maintain the 6.x LTS branch for
EPEL 7, I opted to also produce that version as a module stream for Fedora
28, so that anyone who wishes to may load that version to run whatever apps
they might require that haven't been updated yet to support the 8.x series.
And, because this is Fedora and we like to be First, I have also packaged
Node.js 9.x which is the latest upstream release (with a short lifecycle)
for developers to use as needed.
We have documentation on how to create and manage modules available[2]. For
anyone who is having difficulty doing this, they are welcome to ask any
questions on this list, on #fedora-modularity on Freenode, or to simply
contact myself or one of the other Modularity developers directly. We are
prepared to help.
[1] https://fedoraproject.org/wiki/Changes/F28AddonModularity
[2] https://docs.pagure.org/modularity/
sgallagh and I both noticed that the release criteria do not currently
include any requirements around Edition branding or installer
customizations. We think they probably should. Thus, we're proposing
the following new criteria. They would be in a new section for each
page, something like "Edition requirements" or something like that,
probably with a brief explanation of what "Editions" are outside of any
specific criterion text.
For Beta:
== Installer customization ==
For each Edition, all significant functional customization of installer
behavior that are intended to be a part of that Edition must take
effect on that Edition's installable release-blocking images.
footnote: 'Significant functional?': significant functional
customization would usually include, for e.g., changes to the default
filesystem and firewall configuration. The WG or SIG responsible for
each Edition has the definitive say on what is or is not considered a
'significant functional customization' for that Edition.
For Final:
== Self-identification ==
For each Edition, the installer must be clearly identified as that
Edition in all of that Edition's installable release-blocking images.
Also, for any deployment of that Edition in accordance with the rest of
these criteria, the relevant fields in {{filename|/etc/os-release}}
must include the correct Edition name.
Thoughts, comments, suggestions, flames? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net