#182 Google Account doesn't work during initial setup (requires new blocker criterion)
Closed: Fixed 4 years ago by chrismurphy. Opened 4 years ago by catanzaro.

I'd like to nominate RHBZ: Google Account doesn't work during initial setup as a special final (not beta) release blocker. This bug causes online account setup to fail in gnome-initial-setup: WebKit gets into a crash loop because selinux prevents it from launching its web content process. I don't know how to fix it; it requires some selinux expertise. This doesn't violate any formal blocker criterion and this seems too highly-specific to craft a criterion to cover it, so my proposal is to use the rarely-used special blocker process where WG simply designates it as a blocker.


CC: @adamw @kparal since afaik we only ever used the special blocker process once before, I don't remember where, and I can't find any evidence that it actually exists in the policy document. But I'm pretty sure I'm not just making this up; haven't we done this once before? I thought we had a policy allowing the WG to designate special blockers somewhere....

Bugs designated by FESCo as blockers are automatic blockers. Working groups are subcommittees of FESCo.

Also per FESCo approved governance:

The Working Group may make binding decisions on any matters affecting the Fedora Workstation product, including any software contained in the product.

Seems implied to me, and if FESCo disagrees they can overrule, also per governance.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

4 years ago

Metadata Update from @chrismurphy:
- Issue set to the milestone: Fedora 33

4 years ago

haven't we done this once before? I thought we had a policy allowing the WG to designate special blockers somewhere....

I know I talked about this in the past, saying that I'd like to see WGs having this right (at the same time, it might be wise to separate the release cycles of different editions first). But I'm not sure if it is written down somewhere, I'm certainly not aware of it. And I don't remember a WG using this privilege in the past. @chrismurphy is correct about FESCo blockers, but I'm not sure what exactly this means for individual WGs.

@adamwill Can you search your endless memory whether we already used/talked about this process before?

@catanzaro You can still propose a criterion saying e.g. that all elements of the initial setup screen must do the right thing. Or perhaps something less broad, if you can think of a way to describe it.

You can still propose a criterion saying e.g. that all elements of the initial setup screen must do the right thing. Or perhaps something less broad, if you can think of a way to describe it.

"basic functionality test" ?

"basic functionality test" ?

That only applies to applications which you can run from the system menu. It could apply to gnome-control-center, if it was broken there, but it isn't. But we could extend the criterion to also cover initial setup screen. Of course we would still argue whether adding an online account is a basic functionality or not :)

Off the top of my head I don't think we've ever had a WG designate a blocker. I think we may have had a case where a WG wanted something to be a blocker and asked FESCo and FESCo designated it as one.

Off the top of my head I don't think we've ever had a WG designate a blocker.

Pretty sure we've done it once before? I just don't remember what issue it was for.

Anyway, discussing this case, we agree a special blocker is not really needed. We should instead create a criterion to ensure basic functionality of the firstboot experience is working. Action: mcatanzaro to propose a new criterion.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

4 years ago

I mean, I can't say for 100% sure, but I really don't think so. I'm usually pretty opposed to stuff that isn't in The Process, and there's nothing in The Process that says WGs can designate blockers. There is wording specifically stating that FESCo can designate blockers.

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

4 years ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

4 years ago

Metadata Update from @chrismurphy:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Log in to comment on this ticket.

Metadata