Bodhi needs to be ready to update modules before the beta too, so there's some infrastructure readiness too.

If we are doing a seperate Modular server release then we need to think about mirroring. Its being tracked at https://pagure.io/modularity/issue/60 for which we still need to make a decision.

For F26 Boltron release, we didn't generate torrents. If torrents are needed then we need to look into that as well.

So far as qa is concerned, I mean, if we have bits to test at any time, we can test them. We run validation testing pretty much 365 days a year anyway.

The thing that concerns me here is we have a whole refined, documented process for doing releases as monoliths on a single schedule. We don't have a refined and documented process for doing...this. Each individual team probably thinks it can do what needs to be done, the thing we get from the release process is the 'glue' between the teams, so everyone knows how bits get generated and passed from releng through qa to the release process, and issues come up from qa to the developers and feed back into the releng cycle.

We have a process for doing two-week Atomic releases, but that's different because it relies entirely on automated testing; we can't really do that for a first release of modular Server, I think, we really need human eyes on it at some point.

@adamwill Yes, that's an excellent point. I'm going to make sure we have extra attention on that ... glue fabric. And will act as the glue where needed.

I have an opinion on point 6 — what to do with traditional Fedora Server.

Fedora as a server operating system continues to be quite popular. I don't have really solid numbers, but I'm comfortable with the rough assessment that 20-25% of users use Fedora in some server capacity. But, from feedback I gathered earlier this year, only a tiny majority are using Fedora Server as Server Edition per se. We never did get the momentum we hoped for for server roles, either in their new lightweight incarnation or the previous design. That's disappointing, but it's not surprising that not everything works out.

That's part of the reason to try this new Modular Server so quickly in the first place, schedule and everything aside — but, I think it also means that as long as we provide people continuity and a clear way to get some kind of Fedora running in a server context, we are largely okay.

Specifically, I think we should keep fedora-release-server, but should skip making the Server tree or install media. On the website at F27 GA, we should direct people to a document addressing three audiences:

People Waiting For Fedora Modular Server

"Coming Soon — this is gonna be awesome."

Ideally, we will have the beta for this available at general GA.

People Using Fedora as a Server, but not Fedora Server Edition necessarily

No problem! Not much changes here. Take a look at the "everything" netinstall, or else maybe Fedora Cloud Base. Or upgrade as usual.

Existing Fedora Server Users

You've got three options:
- Wait a little bit and migrate to new Fedora Modular Server when that's available
- dnf system-upgrade to Fedora Server 27
- Just stay on F26 until the end of that cycle, figure out what to do then (Possibly we'll have some kind of non-modular to modular upgrade path in the future?)

@mattdm without the Server variant people will not get the Server options. Defaults like XFS filesystem will not happen. I think for 27 and 28 we likely should keep doing the Server Variant, perhaps putting it in Alt with the Cloud Variant.

I totally agree with both @adamwill and @ausil. The specific POV of websites is:

• We are able to set up a website for a different release cycle of Modular Server, but this means F27 Beta Modular Server should not be released before 3-4 weeks (but before F27GA)
• I like the idea of having a legacy server image available for users who search for the F27 traditional server. alt.fp.o should be the place where this can live.

I would suggest to make something like that:

• F27 Beta could have legacy server images on getfedora.org, but we will add a section on top that we are waiting for the new edition of Fedora Modular Server and explain that the traditional server image will be replaced by Modular server starting from F27GA.
• Once we have F27 beta Modular Server ready we can put these images on top of the F27 prerelease download page
• At F27 GA release date we will also replace the main server index page with new text and images, keep only F27 Beta Modular server on the download page (while WS and Atomic will switch to F27 GA) and move legacy server to alt.fp.o

We just need to figure out some deadlines to make a plan for the next month.

Personally, I don't think putting a traditional server beta out in any "real" capacity is a good idea because of the "beta should match GA". However, it can be "there" in the way @mattdm describes as available but without install media. I am pretty confident this is what the Server SIG believes too. However, on the rest of @robyduck's points, I agree.

I put together a modified version of the Release Schedule page to try to reflect some dates I think might work. However, I need feedback from @ausil, @mohanboddu, @adamwill , and @kparal. I didn't map the dates of modular-beta <-> traditional-ga only because I thought doing them separately might be a) easier b) less risky. However, as I think about it, is one "release" actually easier/safer for rel-eng? I am sure QA would appreciate the extra week. Please also keep in mind, "available" doesn't mean "promoted" so we may build modular-server-beta on the 17th but not announce it til the 24th.

Lastly, I don't think QA can afford to test both traditional and modular server. However, the testing for traditional workstation, cloud, etc may be sufficient to consider the traditional server build to be "good enough" as it isn't the primary deliverable. However, I would like QA to weigh in on this.

@langdon well, generic testing doesn't prove much about server beyond 'it probably installs and boots'. It doesn't go anywhere to proving whether Server meets its specific criteria to do with firewalls, cockpit, FreeIPA and postgres. The importance of these to actual users is a bit more of an open question, though.

The good news is that most of the existing Server testing is automated, so we get to know whether it's broken pretty much for free. Getting it fixed isn't free, but we would at least know whether it was broken pretty easily.

Note I've already spent a considerable amount of time and effort this cycle getting FreeIPA in particular even vaguely into shape.

Server SIG has given their blessing to a somewhat revised schedule: https://fedoraproject.org/wiki/User:Langdon/Proposed_Modular_Server_Release

Adding to the meeting for tomorrow. Also worth noting that the Server SIG voted to mark the non-modular Server Edition media as non-blocking.

It is important to get FESCo's sign-off, as it affects multiple groups.

AGREED: modular server release schedule is approved (+8,0,0) (nirik, 17:13:07)

Do we need to keep this open to track further items?

retagging for review at the meeting. Beta has slipped and a rain date was not in the schedule for Beta. I believe we can add one and keep the final dates as is without having to push everything out.

I believe we can add one and keep the final dates as is without having to push everything out.

As I understand it, the platform module is not currently building; is this realistic? If it is achievable, I will buy beverages-of-choice for everyone. :)

I believe we can add one and keep the final dates as is without having to push everything out.

As I understand it, the platform module is not currently building; is this realistic? If it is achievable, I will buy beverages-of-choice for everyone. :)

@mattdm
Where are you getting that information? The Platform module was building successfully as recently as yesterday.

FESCo Meeting 2017-10-13

#agreed: Add a presumed one-week slip to be the Rain Date; slip Final if that isn't achieved. (+1:8, -1:0, +0:0)

This looks like it was accidentally reopened.