server January 2018

server@lists.fedoraproject.org

8 participants
6 discussions

Release criteria proposals: Edition branding and installer customizations
by Adam Williamson 01 Feb '18

01 Feb '18

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

1 2

No meeting today
by Stephen Gallagher 30 Jan '18

30 Jan '18

I'll be somewhere over the Atlantic Ocean at the meeting time.

1 0

[Talking Points] Server Team
by Alberto Rodriguez Sanchez 29 Jan '18

29 Jan '18

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>

1 0

Re: F28 System Wide Change: AArch64 Server Promotion
by Adam Williamson 09 Jan '18

09 Jan '18

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

6 15

Re: F28 System Wide Change: AArch64 Server Promotion
by Stephen Gallagher 08 Jan '18

08 Jan '18

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 >

2 1

2018-01-08 @ 17:00 UTC - Fedora 28 Blocker Review Meeting
by Adam Williamson 05 Jan '18

05 Jan '18

# F28 Blocker Review meeting # Date: 2018-01-08 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have six proposed blockers for Fedora 28 Beta, so let's have a review meeting on Monday. If you have time over the weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F28 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server January 2018