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

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