Server SIG Weekly Meeting Minutes (2017-11-07)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
================================================================
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2017-11-07)
================================================================
Meeting started by sgallagh at 21:01:01 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-1/2017-11-07/serversig...
.
Meeting summary
- ---------------
* Roll Call (sgallagh, 21:01:01)
* Agenda (sgallagh, 21:06:01)
* Agenda Item: What do we do for upgrades? (sgallagh, 21:06:22)
* Agenda Item: Name of the Edition (sgallagh, 21:06:26)
* Agenda Item: Final Release Criteria for modularity (sgallagh,
21:06:29)
* Agenda Item: Testing requested on Beta RC (sgallagh, 21:06:34)
* Agenda Item: Beta Blockers (sgallagh, 21:07:54)
* What do we do for upgrades? (sgallagh, 21:08:05)
* LINK: https://fedoramagazine.org/where-is-fedora-server-27-beta/
(langdon, 21:13:23)
* AGREED: Upgrade bugs from Fedora 26 Server Edition to Fedora 27 do
not block the release of either F27 or F27 Modular. We will address
(attempt to fix, at least document) issues with dnf upgrade from
Fedora 26 Server to Fedora 27 non-modular packages on a best-effort
basis. We currently intend to provide a recommended upgrade path
from Fedora 26 Server to Fedora 28 at the time of Fedora 28 release.
(sgallagh, 21:42:27)
* Name of the Edition (sgallagh, 21:42:42)
* AGREED: Call it "Fedora Modular Server" to avoid end-user confusion
as requested by multiple parties. (sgallagh, 21:56:20)
* Testing requested on Beta RC (sgallagh, 21:58:29)
* AGREED: BZ 1510629 is a blocker for F27 Modular Server Beta
(sgallagh, 22:04:12)
* Final Release Criteria for modularity (sgallagh, 22:04:55)
* We will postpone this discussion to next week after QA feedback is
incorporated. (sgallagh, 22:07:23)
* Open Floor (sgallagh, 22:07:27)
* We have an RC! (sgallagh, 22:08:18)
* LINK:
https://kojipkgs.fedoraproject.org/compose/27/Fedora-Modular-27-20171107....
(sgallagh, 22:09:27)
Meeting ended at 22:11:24 UTC.
Action Items
- ------------
Action Items, by person
- -----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (107)
* adamw (52)
* langdon (51)
* nirik (26)
* smooge (16)
* zodbot (12)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.0.0
Comment: https://www.mailvelope.com
wkYEAREIABAFAloCL8UJEHolVWI2uqOjAACiSACcDsjqSRf8MEjaXGLN2TLm
h96vkMIAnRXmKJ47E0Q+fP6C7gyNMu+/TAPV
=soFm
-----END PGP SIGNATURE-----
6 years, 4 months
Re: Product requirements for Modularity server.
by Adam Williamson
On Fri, 2017-11-03 at 11:00 -0400, James Antill wrote:
> Hey, so we put this together for test requirements for Modularity
> server:
>
> https://fedoraproject.org/w/index.php?title=User%3AJames%2FDraft%3AFedo
> ra_27_Final_Release_Criteria%2Bmodularity&diff=501506&oldid=501503
Thanks for that!
I'm not sure I like the preamble. For a start, the criteria are not
"instructions" for testing. Beyond that, I'm not sure it serves any
function; we don't need to specifically state that the criteria really
do apply to this or that. What's the purpose of the preamble, to you?
The meat of the requirements seems fine, but I'd probably choose to
represent them a bit differently. The requirement isn't really about
'modular data' in the repositories, that's kind of an implementation
detail. The requirement is for the installer and the installed system
to be able to manipulate modules, right? So, I'd want to follow the
pattern established by existing requirements related to *packages* in
that area.
For instance, we have a Beta criterion:
"Package set selection
When installing with the generic network install image, interactively
selecting a package set other than the default must work."
So, wouldn't it make sense to add another criterion directly below it:
"Module selection
When installing with a release-blocking [https://docs.pagure.org/modula
rity/ Modularity]-enabled image, changing the default module selection
must work."
or something like that? (It'd be nice to be more precise about exactly
what we expect from the installer, but I can't be more precise because
I don't know yet :>)
Similarly, for the installed system, I'd probably want to add a new
criterion to "Post-install requirements" at Beta or Final rather than
have this new section. It's an interesting point that we don't actually
require package installation or removal to work in the criteria; this
is intentional, though arguable. We only require package *update* to
work in the criteria, the logic being that if package install or
removal is broken we can ship an update to fix it. I'm not sure I'm
still married to that position, though. :) So we might want to extend
the criteria to require that basic package installation and removal
with the official tools works, and add a corresponding criterion for
module interactions directly beneath it.
WDYT? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6 years, 4 months
2017-11-06 @ ** 17:00 ** UTC - Fedora 27 Blocker Review Meeting
by Adam Williamson
# F27 Blocker Review meeting
# Date: 2017-11-06
# Time: ** 17:00 ** UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We currently have only one proposed freeze exception for
Fedora 27. However, in case more blockers show up over the weekend,
I'm scheduling a review meeting for Monday; if there aren't any,
I'll just run a very quick meeting where we don't do anything.
Note that daylight savings time ends in most of North America this
weekend, so we'll be changing the meeting time to 17:00 UTC. If
daylight savings ends (clocks go back) for you this weekend, the
meeting should be at the same local time as always. If you don't
observe daylight savings or it ends at a different time, the meeting
will be one hour later in your local time than it was last week.
If you have time this 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 F27 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
Note that for the special case of the Server release being split from
the main release stream for Fedora 27, we have created separate Server
blocker tracking bugs and will be following the same basic process for
the Server release dates using those trackers.
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
6 years, 4 months