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

Hi Server Team,
I'm Alberto from the marketing team,
Talking points are key highlights of the new release. They should be
compelling, but they will not necessarily be comprehensive. There are
different types of talking points for different types of people:
general desktop users/everyone, developers, and sysadmins. For the
Fedora 28 cycle, we will also have talking points to address some of
the Spins. They are meant to provide a short, effective answer to the
question, "What cool stuff is in the latest release of Fedora?"
Each cycle, the Marketing team compiles a short list of approximately
three talking points for each of these audiences for the upcoming
release.
So, What is new from the Server Team side??
If you have a talking point that you feel meets the criteria found on
the talking points SOP page at
https://fedoraproject.org/wiki/Talking_points_SOP,
Best Regards
--
Alberto Rodriguez Sanchez <bt0dotninja(a)fedoraproject.org>

On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote:
>
> == Scope ==
> * Proposal owners:
> The general AArch64 support is already in place and is widely and
> actively supported by the Fedora ARM SIG and numerous ARM vendors and
> third parties in Fedora. There will be further and wider support,
> hardware enablement, polish and general improvements.
>
> * Other developers:
> N/A: There's no work required for other developers, the aarch64
> architecture is already widely supported as an Alternate Architecture.
>
> * Release engineering:
> Needs approval from release engineering as a primary architecture as
> well as pungi configuration changes to output artifacts to new
> location on the primary mirror.
> rel-eng ticket #7243: https://pagure.io/releng/issue/7243
>
> * Policies and guidelines:
> Updates to the primary architectures and release blocking details will
> need to be updated to reflect that the AArch64 Server/Cloud/Docker
> components are now considered primary.
>
> * Trademark approval:
> N/A (not needed for this Change)
A significant miss here is 'testing'. Making an arch primary means we
need to ensure we have the necessary resources to run all the relevant
validation testing.
I note pwhalen is a co-owner of the proposal so he's likely signed up
to ensure testing gets done, but still, it should be properly covered
in the Change document itself.
As a further note, almost all the Server validation for x86_64 is done
by openQA; doing it manually can be a considerable pain, as you have to
set up a mini FreeIPA deployment. It would probably be best if we add
aarch64 workers to the Fedora openQA deployment to run these tests on
aarch64; we've already extended openQA (staging) to ppc64, so all the
bits should be in place for us to add another arch, pretty much. I'm
going to follow up on this with pwhalen.
Another consideration would be whether we ought to also have aarch64
support in Taskotron, if it's going to become a primary arch. I'm not
actually sure if Taskotron currently covers 32-bit ARM, though, even.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Hey, Server WG folks: I'd like to propose that, as part of this Change
Proposal, we add the aarch64 install media to our blocking set (thus making
it an "official" Server Edition release)
On Mon, Jan 8, 2018 at 8:41 AM Jan Kurik <jkurik(a)redhat.com> wrote:
> = System Wide Change: AArch64 Server Promotion =
> https://fedoraproject.org/wiki/Changes/AArch64_Server_Promotion
>
> Change owner(s):
> * Peter Robinson <pbrobinson AT fedoraproject DOT org>
> * Paul Whalen <pwhalen AT fedoraproject DOT org>
>
> Promote Aarch64 server technologies to Primary Architecture status.
> This would include the Server installer, the DVD installer ISOs, the
> Cloud (qcow2 images) and Docker base images to the same status as
> other primary Server architectures. This would NOT currently include
> other components such as Workstation images/installs, any of the
> various spins, or Fedora Atomic components.
>
>
> == Detailed Description ==
> The AArch64 Architecture in the server space is a mature product with
> numerous platforms widely available for testing. We support both SBSA
> Enterprise Haware as well as a number of Single Board Computers,
> initially officially supported in Fedora 27 with the aarch64 SBC
> Feature, with new device support being added all the time and more
> widely available and affordable hardware.
>
> The changes is actually a minor one as we already produce all the
> deliverables as an Alternate Architecture, this primarily be a change
> of where the output of the artifacts are delivered on the mirrors and
> making the architecture a release blocking architecture.
>
> This would NOT currently include other components such as Workstation
> images/installs, any of the various spins, or Fedora Atomic
> components.
>
>
> == Scope ==
> * Proposal owners:
> The general AArch64 support is already in place and is widely and
> actively supported by the Fedora ARM SIG and numerous ARM vendors and
> third parties in Fedora. There will be further and wider support,
> hardware enablement, polish and general improvements.
>
> * Other developers:
> N/A: There's no work required for other developers, the aarch64
> architecture is already widely supported as an Alternate Architecture.
>
> * Release engineering:
> Needs approval from release engineering as a primary architecture as
> well as pungi configuration changes to output artifacts to new
> location on the primary mirror.
> rel-eng ticket #7243: https://pagure.io/releng/issue/7243
>
> * Policies and guidelines:
> Updates to the primary architectures and release blocking details will
> need to be updated to reflect that the AArch64 Server/Cloud/Docker
> components are now considered primary.
>
> * Trademark approval:
> N/A (not needed for this Change)
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71
> <https://maps.google.com/?q=Purkynova+99/71&entry=gmail&source=g>, 612 45
> Brno, Czech Republic
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>