New Blocker Criterion Proposal: Same default packages for all arches

[Stephen Gallagher]

For a little background, yesterday we had a very long discussion of a
bug[1] during the blocker bug meeting. The quick overview of that bug is
that Firefox failed to build on some non-x86 architectures, so the
package maintainer opted to stop building Firefox on anything but i686
and x86_64. This had the cascading effect of causing the alternative
architecture composes to fail (including ARM/XFCE).

During that meeting, I argued that the specific firefox bug didn't
violate any criteria and that we should create a new bug[2] and mark
that one as a blocker. However, I think I argued my contradicting
example a bit too well and it was misconstrued that I was suggesting
that we drop Firefox on alternative architectures and call that a
solution. My point was mostly that I wanted us blocking on a bug that
described the failed criteria, not dictating a specific solution.

I went digging through the criteria to try to find something that I
could cite to get the Firefox issue back onto the blocker list (because
on reflection *do* think it's extremely serious and I've considered
taking it to FESCo for their override). However, it seems that our
blocker criteria do not describe one institutional guideline that we've
been trying to follow: that alternative architectures should be
delivering the same content as the "primary" architectures.

What I would like to propose (wordsmithing welcome) is an addendum to
the Beta criteria under the Installer->Default Package Set requirements:

"The default package set installed from blocking media must be the same
on all architectures for that Edition, Spin or netinstall except for
packages whose sole purpose is hardware enablement for one or more
architectures."

Breaking it down, I think we should have an explicit criterion that
installing the default package set for e.g. XFCE spin on armv7 must be
the same set of packages you would get in a default install of e.g. XFCE
spin on x86_64. If there are specific examples of where there are known
(non-hardware-enablement) packages for which this is impossible, I'd
suggest adding a clause like "FESCo will maintain a list of packages
exempt from this requirement".

So I'd like for us to consider including this requirement for F26 Beta
(though I realize time is a little short on that score). If Fedora QA
feels that it's too late for us to add this criterion, I'll take the
specific matter of the Firefox builds to FESCo. I do think we should set
a precedent here and document it for the future.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1443938
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1448923

[Adam Williamson]

On Tue, 2017-05-09 at 19:39 -0400, Stephen Gallagher wrote:
>  However, it seems that our
>  blocker criteria do not describe one institutional guideline that we've
>  been trying to follow: that alternative architectures should be
>  delivering the same content as the "primary" architectures. 
Nitpick: ARM *is* a primary architecture. x86_64 and armhfp are the
current Fedora primary architectures. All others are 'alternat(iv)e
architectures' (the words 'alternate' and 'alternative' seem to be
used
as if they were interchangeable, in the various pages discussing this).

Ref: https://fedoraproject.org/wiki/Architectures

>  What I would like to propose (wordsmithing welcome) is an addendum
> to
>  the Beta criteria under the Installer->Default Package Set requirements:
>  
>  "The default package set installed from blocking media must be the same
>  on all architectures for that Edition, Spin or netinstall except for
>  packages whose sole purpose is hardware enablement for one or more
>  architectures."
>  
>  Breaking it down, I think we should have an explicit criterion that
>  installing the default package set for e.g. XFCE spin on armv7 must be
>  the same set of packages you would get in a default install of e.g. XFCE
>  spin on x86_64. 
Well, we weren't talking about only changing the default on ARM, in the
meeting. The implication was that we'd change the default for x86_64 as
well. Since about three weeks ago we don't technically *have* to, I
think, because we tweaked comps to allow specifying packages by arch,
but we've not actually used this at all yet.

The wrinkle in this situation is that Xfce is *only* a release-blocking 
environment *for ARM*. It is not a release blocking environment for
x86_64. So I don't think the proposed criterion would actually *mean*
much in this case. If someone actually decided to push for changing the
Xfce default browser as a resolution to the bug (rather than fixing
Firefox), telling them they have to change it for x86_64 as well as ARM
probably wouldn't dissuade them. They'd just say "Fine, we'll do
that."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Stephen Gallagher]

On 05/09/2017 08:17 PM, Adam Williamson wrote:
>  On Tue, 2017-05-09 at 19:39 -0400, Stephen Gallagher wrote:
> > However, it seems that our
> > blocker criteria do not describe one institutional guideline that we've
> > been trying to follow: that alternative architectures should be
> > delivering the same content as the "primary" architectures.
>  Nitpick: ARM *is* a primary architecture. x86_64 and armhfp are the
>  current Fedora primary architectures. All others are 'alternat(iv)e
>  architectures' (the words 'alternate' and 'alternative' seem to be
> used
>  as if they were interchangeable, in the various pages discussing this).
>
>  Ref: https://fedoraproject.org/wiki/Architectures 
Apologies, that was a misstatement.

> > What I would like to propose (wordsmithing welcome) is an addendum to
> > the Beta criteria under the Installer->Default Package Set requirements:
> >
> > "The default package set installed from blocking media must be the same
> > on all architectures for that Edition, Spin or netinstall except for
> > packages whose sole purpose is hardware enablement for one or more
> > architectures."
> >
> > Breaking it down, I think we should have an explicit criterion that
> > installing the default package set for e.g. XFCE spin on armv7 must be
> > the same set of packages you would get in a default install of e.g. XFCE
> > spin on x86_64.
>  Well, we weren't talking about only changing the default on ARM, in the
>  meeting. The implication was that we'd change the default for x86_64 as
>  well. Since about three weeks ago we don't technically *have* to, I
>  think, because we tweaked comps to allow specifying packages by arch,
>  but we've not actually used this at all yet.
>
>  The wrinkle in this situation is that Xfce is *only* a release-blocking 
>  environment *for ARM*. It is not a release blocking environment for
>  x86_64. So I don't think the proposed criterion would actually *mean*
>  much in this case. If someone actually decided to push for changing the
>  Xfce default browser as a resolution to the bug (rather than fixing
>  Firefox), telling them they have to change it for x86_64 as well as ARM
>  probably wouldn't dissuade them. They'd just say "Fine, we'll do
> that." 
Sure, but that puts pressure on the maintainers of that spin to make a
decision. If they *really* want to keep Firefox on their x86_64
platform, they'll push to get it fixed. On the other hand, if they don't
actually care, then at minimum we will maintain a consistent experience
across architectures. I think it's valuable to have that encoded as a
blocking requirement.

[Kamil Paral]

On Wed, May 10, 2017 at 1:39 AM, Stephen Gallagher <sgallagh(a)redhat.com&gt;
wrote:

>  For a little background, yesterday we had a very long discussion of
> a
>  bug[1] during the blocker bug meeting. The quick overview of that bug is
>  that Firefox failed to build on some non-x86 architectures, so the
>  package maintainer opted to stop building Firefox on anything but i686
>  and x86_64. This had the cascading effect of causing the alternative
>  architecture composes to fail (including ARM/XFCE).
>
>  During that meeting, I argued that the specific firefox bug didn't
>  violate any criteria and that we should create a new bug[2] and mark
>  that one as a blocker. However, I think I argued my contradicting
>  example a bit too well and it was misconstrued that I was suggesting
>  that we drop Firefox on alternative architectures and call that a
>  solution. My point was mostly that I wanted us blocking on a bug that
>  described the failed criteria, not dictating a specific solution.
>
>  I went digging through the criteria to try to find something that I
>  could cite to get the Firefox issue back onto the blocker list (because
>  on reflection *do* think it's extremely serious and I've considered
>  taking it to FESCo for their override). However, it seems that our
>  blocker criteria do not describe one institutional guideline that we've
>  been trying to follow: that alternative architectures should be
>  delivering the same content as the "primary" architectures.
>
>  What I would like to propose (wordsmithing welcome) is an addendum to
>  the Beta criteria under the Installer->Default Package Set requirements:
>
>  "The default package set installed from blocking media must be the same
>  on all architectures for that Edition, Spin or netinstall except for
>  packages whose sole purpose is hardware enablement for one or more
>  architectures."
>
>  Breaking it down, I think we should have an explicit criterion that
>  installing the default package set for e.g. XFCE spin on armv7 must be
>  the same set of packages you would get in a default install of e.g. XFCE
>  spin on x86_64. If there are specific examples of where there are known
>  (non-hardware-enablement) packages for which this is impossible, I'd
>  suggest adding a clause like "FESCo will maintain a list of packages
>  exempt from this requirement".
>
>  So I'd like for us to consider including this requirement for F26 Beta
>  (though I realize time is a little short on that score). If Fedora QA
>  feels that it's too late for us to add this criterion, I'll take the
>  specific matter of the Firefox builds to FESCo. I do think we should set
>  a precedent here and document it for the future.
>
>
>
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1443938
>  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1448923
>
>
>  
I don't really understand this, and I haven't read the meeting log, so I
apologize if my questions are dumb.

Why would we dictate that Editions/Spins can't use different software on
different architectures? It might make perfect sense to use browser X on
x86_64 because it's very good, but use browser Y on i386 because of memory
limitations of i386 arch (browser Y needing much less memory than browser
X). Similarly, if shell A no longer supports i386, why would be ban it from
being preinstalled on x86_64? i386 would have shell B instead. Those are
random examples, but it seems to me that they can be completely valid. If
there's such requirement that Editions/Spins can't install different
software on different arches, I think that should be established by FESCo,
not us.

For this particular Firefox example, what is the core problem that you're
trying to fix here? Is it the fact that Firefox excluded many arches from
builds? From my QA POV, since it excluded arm, it's a blocker, since arm is
primary. If it hadn't excluded arm, it would not be a blocker, and
alternate arches would need to find a way (fix the bug or use a different
browser). If you still think this should not happen, you could ask FESCo to
present some rules saying when Fedora packagers can exclude other arches
from the build and when they can't. We could then enforce that (instead of
prohibiting different package sets).

[Richard Ryniker]

I agree with you that Firefox is an important resource that Fedora should
deliver, but think a criterion that failure to supply the same default
package set for all (blocking) architectures will do more harm than good.

Release criteria should focus on the quality of what is delivered in a
release.  They should not be a specification for its content, or a
mechanism to allocate developer resources.

The "critical path" concept already defines a set of resources considered
essential to a usable Fedora release.  A Web browser (in workstation
builds) is an essential resource - Fedora could specify Firefox for this
role, or accept any usable browser to meet this need, even different
browsers on different architectures.

The major problem with a heavy-handed "same default package set"
criterion is the delay that might cause - especially if upstream
resources are required.  While Fedora waits for the last "default set"
package to be fixed for some architecture, everything else in the frozen
release ages.  Sure, more recent package builds can accumulate in updates
repositories, but then, when the release actually happens, users perform
their first upgrade and wind up with a system too much different from
what was actually tested for that release.

In an extreme situation, a release could be nearly impossible due to
dependency cycles.

I think it better to agree the same default package set is desirable, but
not essential, in a release.  Judiciously add packages to the "critical
path" set when a case is made that they are essential to Fedora.  In
other situations, argue for an exception to be made to block a release
because, though perhaps not critical, some feature is so important to
such a large group of users that it causes more damage to release without
support on some architecture than to wait until it is fixed.

[Mike Ruckman]

On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
>  I don't really understand this, and I haven't read the
> meeting log, so I
>  apologize if my questions are dumb. 
I was in the meeting, and I was confused - so your questions aren't
dumb. :)

>  Why would we dictate that Editions/Spins can't use different
> software on
>  different architectures? It might make perfect sense to use browser X on
>  x86_64 because it's very good, but use browser Y on i386 because of memory
>  limitations of i386 arch (browser Y needing much less memory than browser
>  X). Similarly, if shell A no longer supports i386, why would be ban it from
>  being preinstalled on x86_64? i386 would have shell B instead. Those are
>  random examples, but it seems to me that they can be completely valid. If
>  there's such requirement that Editions/Spins can't install different
>  software on different arches, I think that should be established by FESCo,
>  not us. 
I concur with Kamil on this one, I think there's valid reasons a package
set might be different based on the arch. If this is indeed the
direction we want to go, I think FESCo needs to make that call.

>  For this particular Firefox example, what is the core problem that
> you're
>  trying to fix here? Is it the fact that Firefox excluded many arches from
>  builds? From my QA POV, since it excluded arm, it's a blocker, since arm is
>  primary. If it hadn't excluded arm, it would not be a blocker, and
>  alternate arches would need to find a way (fix the bug or use a different
>  browser). If you still think this should not happen, you could ask FESCo to
>  present some rules saying when Fedora packagers can exclude other arches
>  from the build and when they can't. We could then enforce that (instead of
>  prohibiting different package sets). 
As I think I said in the meeting, I thought the bug as filed was the
blocker and didn't see the need for the shadow bug created to track
blockeriness. It was a secondary affect, sure; but we deal with that all
the time. I concur that it might be a good idea to keep a list (FESCo
generated probably?) of "key" packages that need to be available on all
arches, or what arches they're allowed to not use.

// Mike
--
Fedora QA

[Adam Williamson]

On Wed, 2017-05-10 at 16:52 +0200, Kamil Paral wrote:
>  For this particular Firefox example, what is the core problem that
> you're
>  trying to fix here? Is it the fact that Firefox excluded many arches from
>  builds? From my QA POV, since it excluded arm, it's a blocker, since arm is
>  primary. 
There is not, in fact, any blocker criterion which simply makes it a
blocker issue to disable a package build on a primary arch. There are,
I think, several 'legitimate' cases of this, in fact.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kamil Paral]

On Wed, May 10, 2017 at 10:24 PM, Adam Williamson <
adamwill(a)fedoraproject.org&gt; wrote:

>  On Wed, 2017-05-10 at 16:52 +0200, Kamil Paral wrote:
>  > For this particular Firefox example, what is the core problem that you're
>  > trying to fix here? Is it the fact that Firefox excluded many arches from
>  > builds? From my QA POV, since it excluded arm, it's a blocker, since arm
>  is
>  > primary.
>
>  There is not, in fact, any blocker criterion which simply makes it a
>  blocker issue to disable a package build on a primary arch. There are,
>  I think, several 'legitimate' cases of this, in fact.
>  
I didn't specify my full thinking process. I wanted to write it like this:
firefox no longer available for arm -> arm is primary arch -> release
criteria apply for arm -> release criteria say that default browser must
work -> blocker
(until either firefox is available and working again, or until that
particular arm edition replaces firefox with a different default browser)

[Stephen Gallagher]

On 05/11/2017 02:53 AM, Kamil Paral wrote:
>  
>  
>  On Wed, May 10, 2017 at 10:24 PM, Adam Williamson <adamwill(a)fedoraproject.org
>  <mailto:[e-mail]>> wrote:
>  
>      On Wed, 2017-05-10 at 16:52 +0200, Kamil Paral wrote:
>      > For this particular Firefox example, what is the core problem that you're
>      > trying to fix here? Is it the fact that Firefox excluded many arches from
>      > builds? From my QA POV, since it excluded arm, it's a blocker, since arm is
>      > primary.
>  
>      There is not, in fact, any blocker criterion which simply makes it a
>      blocker issue to disable a package build on a primary arch. There are,
>      I think, several 'legitimate' cases of this, in fact.
>  
>  
>  I didn't specify my full thinking process. I wanted to write it like this:
>  firefox no longer available for arm -> arm is primary arch -> release criteria
>  apply for arm -> release criteria say that default browser must work -> blocker
>  (until either firefox is available and working again, or until that particular
>  arm edition replaces firefox with a different default browser) 

It's that last part that bugs me. While I know it's the way the rules work today
(and I argued on Monday to follow the letter of the rules), I think that we
should really have another rule that prevents this moving of goalposts.

At the very least, I want a rule that would accomplish the following: If XFCE
Spin on ARM cannot use Firefox, then XFCE Spin on x86_64 (and others) cannot
ship Firefox by default. That way the standard behavior is the same for all of
them. This also puts pressure on the maintainer to fix it for the arch(es) that
are broken if they or the Spin owners want it available.

Maybe it doesn't need to be as wide-reaching as my original proposal, but I
think we need this for at least the default application sets.

[Adam Williamson]

On Thu, 2017-05-11 at 08:01 -0400, Stephen Gallagher wrote:
>  On 05/11/2017 02:53 AM, Kamil Paral wrote:
>  > 
>  > 
>  > On Wed, May 10, 2017 at 10:24 PM, Adam Williamson <adamwill(a)fedoraproject.org
>  > <mailto:[e-mail]>> wrote:
>  > 
>  >     On Wed, 2017-05-10 at 16:52 +0200, Kamil Paral wrote:
>  >     > For this particular Firefox example, what is the core problem that
> you're
>  >     > trying to fix here? Is it the fact that Firefox excluded many arches from
>  >     > builds? From my QA POV, since it excluded arm, it's a blocker, since
> arm is
>  >     > primary.
>  > 
>  >     There is not, in fact, any blocker criterion which simply makes it a
>  >     blocker issue to disable a package build on a primary arch. There are,
>  >     I think, several 'legitimate' cases of this, in fact.
>  > 
>  > 
>  > I didn't specify my full thinking process. I wanted to write it like this:
>  > firefox no longer available for arm -> arm is primary arch -> release
> criteria
>  > apply for arm -> release criteria say that default browser must work ->
> blocker
>  > (until either firefox is available and working again, or until that particular
>  > arm edition replaces firefox with a different default browser)
>  
>  
>  It's that last part that bugs me. While I know it's the way the rules work today
>  (and I argued on Monday to follow the letter of the rules), I think that we
>  should really have another rule that prevents this moving of goalposts. 
I don't really see why. To me, it's getting beyond the appropriate
business of the release criteria.

It's generally the case that deciding the appropriate *resolution* to
blocker bugs is ultimately up to the relevant maintainers. In this
case, it'd be the Xfce SIG, at least immediately: if they don't think
that switching browsers is acceptable, well, there's no problem. If
they *do* think it's fine for the Xfce spin to use a different default
browser (as I believe it has in the past), I don't immediately see why
the release criteria should overrule them.

>  At the very least, I want a rule that would accomplish the following:
> If XFCE
>  Spin on ARM cannot use Firefox, then XFCE Spin on x86_64 (and others) cannot
>  ship Firefox by default. 
My biggest cause for hesitation here is this the saying "hard cases
make bad law". Have you tried to think through the consequences of this
in all other possible cases, or are you just slapping a band-aid on a
problem that doesn't even *exist* yet? We only brought up the
possibility of switching default browsers to *illustrate* why the
blocker isn't technically just "Firefox doesn't build on ARM"; no-one
actually *suggested* switching browsers would be a good idea, and I
haven't heard anyone from the Xfce SIG say they want to do it yet. I'm
really reluctant to make what seems like quite a complicated rule on
the basis of a single case of something that actually hasn't happened
yet.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Peter Robinson]

> > For a little background, yesterday we had a very long discussion
> of a
> > bug[1] during the blocker bug meeting. The quick overview of that bug is
> > that Firefox failed to build on some non-x86 architectures, so the
> > package maintainer opted to stop building Firefox on anything but i686
> > and x86_64. This had the cascading effect of causing the alternative
> > architecture composes to fail (including ARM/XFCE).
> >
> > During that meeting, I argued that the specific firefox bug didn't
> > violate any criteria and that we should create a new bug[2] and mark
> > that one as a blocker. However, I think I argued my contradicting
> > example a bit too well and it was misconstrued that I was suggesting
> > that we drop Firefox on alternative architectures and call that a
> > solution. My point was mostly that I wanted us blocking on a bug that
> > described the failed criteria, not dictating a specific solution.
> >
> > I went digging through the criteria to try to find something that I
> > could cite to get the Firefox issue back onto the blocker list (because
> > on reflection *do* think it's extremely serious and I've considered
> > taking it to FESCo for their override). However, it seems that our
> > blocker criteria do not describe one institutional guideline that we've
> > been trying to follow: that alternative architectures should be
> > delivering the same content as the "primary" architectures.
> >
> > What I would like to propose (wordsmithing welcome) is an addendum to
> > the Beta criteria under the Installer->Default Package Set requirements:
> >
> > "The default package set installed from blocking media must be the same
> > on all architectures for that Edition, Spin or netinstall except for
> > packages whose sole purpose is hardware enablement for one or more
> > architectures."
> >
> > Breaking it down, I think we should have an explicit criterion that
> > installing the default package set for e.g. XFCE spin on armv7 must be
> > the same set of packages you would get in a default install of e.g. XFCE
> > spin on x86_64. If there are specific examples of where there are known
> > (non-hardware-enablement) packages for which this is impossible, I'd
> > suggest adding a clause like "FESCo will maintain a list of packages
> > exempt from this requirement".
> >
> > So I'd like for us to consider including this requirement for F26 Beta
> > (though I realize time is a little short on that score). If Fedora QA
> > feels that it's too late for us to add this criterion, I'll take the
> > specific matter of the Firefox builds to FESCo. I do think we should set
> > a precedent here and document it for the future.
> >
> >
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1443938
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1448923
> >
> >
>
>  I don't really understand this, and I haven't read the meeting log, so I
>  apologize if my questions are dumb.
>
>  Why would we dictate that Editions/Spins can't use different software on
>  different architectures? It might make perfect sense to use browser X on
>  x86_64 because it's very good, but use browser Y on i386 because of memory
>  limitations of i386 arch (browser Y needing much less memory than browser 
You can't guarantee memory on any device, you should have a consistent
experience in terms of applications not perceived possible issues such
as memory. EG you could easily have a Power64 or aarch64 device that's
faster than x86)64 with more memory.

>  X). Similarly, if shell A no longer supports i386, why would be ban
> it from
>  being preinstalled on x86_64? i386 would have shell B instead. Those are
>  random examples, but it seems to me that they can be completely valid. If
>  there's such requirement that Editions/Spins can't install different
>  software on different arches, I think that should be established by FESCo,
>  not us.
>
>  For this particular Firefox example, what is the core problem that you're
>  trying to fix here? Is it the fact that Firefox excluded many arches from
>  builds? From my QA POV, since it excluded arm, it's a blocker, since arm is 
Well it causes most of the world to fail to compose on numerous
architectures. EG Workstation on both ARMv7 and aarch64 is very usable
and accelerated on a number of devices but now completely fails to
compose, Firefox is the default browser there.

> primary. If it hadn't excluded arm, it would not be a blocker, and alternate
> arches would need to find a way (fix the bug or use a different browser). If
> you still think this should not happen, you could ask FESCo to present some
> rules saying when Fedora packagers can exclude other arches from the build
> and when they can't. We could then enforce that (instead of prohibiting
> different package sets).
>
>
> _______________________________________________
> test mailing list -- test(a)lists.fedoraproject.org
> To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
>

[Peter Robinson]

On Wed, May 10, 2017 at 4:15 PM, Richard Ryniker <ryniker(a)alum.mit.edu&gt; wrote:
>  I agree with you that Firefox is an important resource that Fedora
> should
>  deliver, but think a criterion that failure to supply the same default
>  package set for all (blocking) architectures will do more harm than good.
>
>  Release criteria should focus on the quality of what is delivered in a
>  release.  They should not be a specification for its content, or a
>  mechanism to allocate developer resources.
>
>  The "critical path" concept already defines a set of resources considered
>  essential to a usable Fedora release.  A Web browser (in workstation
>  builds) is an essential resource - Fedora could specify Firefox for this
>  role, or accept any usable browser to meet this need, even different
>  browsers on different architectures.
>
>  The major problem with a heavy-handed "same default package set" 
We've aimed for a consistent experience across Fedora for numerous
things whether it be spins (everything has to have SELinux for
example) and I don't see why it should be any different for say an
expected package set on an architecture for a particular Spin/Edition
of Fedora and hence I don't see it as heavy handed.

>  criterion is the delay that might cause - especially if upstream
>  resources are required.  While Fedora waits for the last "default set"
>  package to be fixed for some architecture, everything else in the frozen
>  release ages.  Sure, more recent package builds can accumulate in updates
>  repositories, but then, when the release actually happens, users perform
>  their first upgrade and wind up with a system too much different from
>  what was actually tested for that release.
>
>  In an extreme situation, a release could be nearly impossible due to
>  dependency cycles. 
You'd need to provide specific examples for "extreme" as this has not
happened in recent Fedora history (at least back to F-21)

> I think it better to agree the same default package set is desirable, but
> not essential, in a release.  Judiciously add packages to the "critical
> path" set when a case is made that they are essential to Fedora.  In
> other situations, argue for an exception to be made to block a release
> because, though perhaps not critical, some feature is so important to
> such a large group of users that it causes more damage to release without
> support on some architecture than to wait until it is fixed.
> _______________________________________________
> test mailing list -- test(a)lists.fedoraproject.org
> To unsubscribe send an email to test-leave(a)lists.fedoraproject.org

[Peter Robinson]

On Wed, May 10, 2017 at 8:24 PM, Mike Ruckman <roshi(a)fedoraproject.org&gt; wrote:
>  On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
> > I don't really understand this, and I haven't read the meeting log, so I
> > apologize if my questions are dumb.
>
>  I was in the meeting, and I was confused - so your questions aren't
>  dumb. :)
>
> > Why would we dictate that Editions/Spins can't use different software on
> > different architectures? It might make perfect sense to use browser X on
> > x86_64 because it's very good, but use browser Y on i386 because of memory
> > limitations of i386 arch (browser Y needing much less memory than browser
> > X). Similarly, if shell A no longer supports i386, why would be ban it from
> > being preinstalled on x86_64? i386 would have shell B instead. Those are
> > random examples, but it seems to me that they can be completely valid. If
> > there's such requirement that Editions/Spins can't install different
> > software on different arches, I think that should be established by FESCo,
> > not us.
>
>  I concur with Kamil on this one, I think there's valid reasons a package
>  set might be different based on the arch. If this is indeed the
>  direction we want to go, I think FESCo needs to make that call. 
FESCo has stated for alternate architectures to be considered
"primary" that they should be the same and consistent as the other
architectures for years (going back to F-18 or earlier) so for this to
change now is inconsistent in what's been stated to date. We've been
thumped numerous times for differences.

>> For this particular Firefox example, what is the core problem that you're
>> trying to fix here? Is it the fact that Firefox excluded many arches from
>> builds? From my QA POV, since it excluded arm, it's a blocker, since arm is
>> primary. If it hadn't excluded arm, it would not be a blocker, and
>> alternate arches would need to find a way (fix the bug or use a different
>> browser). If you still think this should not happen, you could ask FESCo to
>> present some rules saying when Fedora packagers can exclude other arches
>> from the build and when they can't. We could then enforce that (instead of
>> prohibiting different package sets).
>
> As I think I said in the meeting, I thought the bug as filed was the
> blocker and didn't see the need for the shadow bug created to track
> blockeriness. It was a secondary affect, sure; but we deal with that all
> the time. I concur that it might be a good idea to keep a list (FESCo
> generated probably?) of "key" packages that need to be available on all
> arches, or what arches they're allowed to not use.
>
> // Mike
> --
> Fedora QA
> _______________________________________________
> test mailing list -- test(a)lists.fedoraproject.org
> To unsubscribe send an email to test-leave(a)lists.fedoraproject.org

[Adam Williamson]

On Thu, 2017-05-11 at 17:33 +0100, Peter Robinson wrote:
>  > For this particular Firefox example, what is the core problem
> that you're
>  > trying to fix here? Is it the fact that Firefox excluded many arches from
>  > builds? From my QA POV, since it excluded arm, it's a blocker, since arm is
>  
>  Well it causes most of the world to fail to compose on numerous
>  architectures. EG Workstation on both ARMv7 and aarch64 is very usable
>  and accelerated on a number of devices but now completely fails to
>  compose, Firefox is the default browser there. 
The point is that as the criteria stand, we could fix that without
fixing Firefox, by simply changing the default browser on the image. We
don't *technically* have to make Firefox build again in order to
resolve the blocker issue.

Some people have an instinctive feeling that this is 'bad' and the
criteria must somehow require that we fix Firefox. Stephen is proposing
something less than that; that at least we should never vary the
'default browser' (and other 'applications') between arches.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Thu, 2017-05-11 at 17:40 +0100, Peter Robinson wrote:
>  On Wed, May 10, 2017 at 8:24 PM, Mike Ruckman
> <roshi(a)fedoraproject.org&gt; wrote:
>  > On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
>  > > I don't really understand this, and I haven't read the meeting log, so
> I
>  > > apologize if my questions are dumb.
>  > 
>  > I was in the meeting, and I was confused - so your questions aren't
>  > dumb. :)
>  > 
>  > > Why would we dictate that Editions/Spins can't use different software on
>  > > different architectures? It might make perfect sense to use browser X on
>  > > x86_64 because it's very good, but use browser Y on i386 because of memory
>  > > limitations of i386 arch (browser Y needing much less memory than browser
>  > > X). Similarly, if shell A no longer supports i386, why would be ban it from
>  > > being preinstalled on x86_64? i386 would have shell B instead. Those are
>  > > random examples, but it seems to me that they can be completely valid. If
>  > > there's such requirement that Editions/Spins can't install different
>  > > software on different arches, I think that should be established by FESCo,
>  > > not us.
>  > 
>  > I concur with Kamil on this one, I think there's valid reasons a package
>  > set might be different based on the arch. If this is indeed the
>  > direction we want to go, I think FESCo needs to make that call.
>  
>  FESCo has stated for alternate architectures to be considered
>  "primary" that they should be the same and consistent as the other
>  architectures for years (going back to F-18 or earlier) so for this to
>  change now is inconsistent in what's been stated to date. We've been
>  thumped numerous times for differences. 
But...we don't actually have the same package set per arch, already. We
have different bootloaders and different bootloader config tools on
different arches, just to give a trivial example.

"Obviously" this is different, but encoding things that are "obvious"
to humans in the release criteria is sometimes quite hard...:)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Peter Robinson]

On Thu, May 11, 2017 at 6:35 PM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Thu, 2017-05-11 at 17:40 +0100, Peter Robinson wrote:
> > On Wed, May 10, 2017 at 8:24 PM, Mike Ruckman <roshi(a)fedoraproject.org&gt; wrote:
> > > On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
> > > > I don't really understand this, and I haven't read the meeting log,
> so I
> > > > apologize if my questions are dumb.
> > >
> > > I was in the meeting, and I was confused - so your questions aren't
> > > dumb. :)
> > >
> > > > Why would we dictate that Editions/Spins can't use different software
> on
> > > > different architectures? It might make perfect sense to use browser X on
> > > > x86_64 because it's very good, but use browser Y on i386 because of
> memory
> > > > limitations of i386 arch (browser Y needing much less memory than browser
> > > > X). Similarly, if shell A no longer supports i386, why would be ban it
> from
> > > > being preinstalled on x86_64? i386 would have shell B instead. Those are
> > > > random examples, but it seems to me that they can be completely valid. If
> > > > there's such requirement that Editions/Spins can't install
> different
> > > > software on different arches, I think that should be established by FESCo,
> > > > not us.
> > >
> > > I concur with Kamil on this one, I think there's valid reasons a package
> > > set might be different based on the arch. If this is indeed the
> > > direction we want to go, I think FESCo needs to make that call.
> >
> > FESCo has stated for alternate architectures to be considered
> > "primary" that they should be the same and consistent as the other
> > architectures for years (going back to F-18 or earlier) so for this to
> > change now is inconsistent in what's been stated to date. We've been
> > thumped numerous times for differences.
>
>  But...we don't actually have the same package set per arch, already. We
>  have different bootloaders and different bootloader config tools on
>  different arches, just to give a trivial example.
>
>  "Obviously" this is different, but encoding things that are
> "obvious"
>  to humans in the release criteria is sometimes quite hard...:) 
To quote Stephen's proposal:

"The default package set installed from blocking media must be the same
on all architectures for that Edition, Spin or netinstall except for
packages whose sole purpose is hardware enablement for one or more
architectures."

So bootloaders are kind of hardware enablement/specific, and
ultimately don't affect the outcome which is a booted Fedora system.

[Stephen Gallagher]

On 05/11/2017 01:33 PM, Adam Williamson wrote:
>  On Thu, 2017-05-11 at 17:33 +0100, Peter Robinson wrote:
> >> For this particular Firefox example, what is the core problem that you're
> >> trying to fix here? Is it the fact that Firefox excluded many arches from
> >> builds? From my QA POV, since it excluded arm, it's a blocker, since arm is
> > Well it causes most of the world to fail to compose on numerous
> > architectures. EG Workstation on both ARMv7 and aarch64 is very usable
> > and accelerated on a number of devices but now completely fails to
> > compose, Firefox is the default browser there.
>  The point is that as the criteria stand, we could fix that without
>  fixing Firefox, by simply changing the default browser on the image. We
>  don't *technically* have to make Firefox build again in order to
>  resolve the blocker issue.
>
>  Some people have an instinctive feeling that this is 'bad' and the
>  criteria must somehow require that we fix Firefox. Stephen is proposing
>  something less than that; that at least we should never vary the
>  'default browser' (and other 'applications') between arches. 
Well,
I was specifically trying to avoid making a rule that applied to
Firefox specifically (because as I mentioned, there's nothing stopping
us from deciding that Chromium or Epiphany or even elinks should be the
default on all systems). My reasoning was that this would be sort of a
back-door to forcing this to be fixed, since the SIGs would apply
pressure not to be forced to switch their other arches to move away from
a package just because it doesn't build (currently) on one of them.

I'm open to a better approach here, but I want to try to encode into the
criteria somewhere that the same deliverable should have the same
default behaviors on all arches for which it is built.

[Matthew Miller]

On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
>  Why would we dictate that Editions/Spins can't use different
> software on
>  different architectures? It might make perfect sense to use browser X on
>  x86_64 because it's very good, but use browser Y on i386 because of memory
>  limitations of i386 arch (browser Y needing much less memory than browser
>  X). Similarly, if shell A no longer supports i386, why would be ban it from 
Speaking as someone who "sells" this stuff, I think it'd be confusing
for the Editions to offer different software (except where dictated by
enabling the hardware). It'd be better to just say that we don't offer
the Edition and instead suggest various spins for architectures where
this comes up. Or, where we decide it's important enough, to make sure
we use software that works across all relevant archs (or if possible to
fix it when it doesn't work).



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Kamil Paral]

On Thu, May 11, 2017 at 11:33 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

>  On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
>  > Why would we dictate that Editions/Spins can't use different software on
>  > different architectures? It might make perfect sense to use browser X on
>  > x86_64 because it's very good, but use browser Y on i386 because of
>  memory
>  > limitations of i386 arch (browser Y needing much less memory than browser
>  > X). Similarly, if shell A no longer supports i386, why would be ban it
>  from
>
>  Speaking as someone who "sells" this stuff, I think it'd be confusing
>  for the Editions to offer different software (except where dictated by
>  enabling the hardware). It'd be better to just say that we don't offer
>  the Edition and instead suggest various spins for architectures where
>  this comes up. Or, where we decide it's important enough, to make sure
>  we use software that works across all relevant archs (or if possible to
>  fix it when it doesn't work).
>
>  
And that's a completely valid approach if we choose to do it like this. I
just feel we shouldn't be deciding this in the test list. It's a higher
level policy than what we usually discuss regarding blocker criteria.

[Peter Robinson]

On Fri, May 12, 2017 at 9:36 AM, Kamil Paral <kparal(a)redhat.com&gt; wrote:
>  On Thu, May 11, 2017 at 11:33 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
>  wrote:
> >
> > On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
> > > Why would we dictate that Editions/Spins can't use different software on
> > > different architectures? It might make perfect sense to use browser X on
> > > x86_64 because it's very good, but use browser Y on i386 because of
> > > memory
> > > limitations of i386 arch (browser Y needing much less memory than
> > > browser
> > > X). Similarly, if shell A no longer supports i386, why would be ban it
> > > from
> >
> > Speaking as someone who "sells" this stuff, I think it'd be confusing
> > for the Editions to offer different software (except where dictated by
> > enabling the hardware). It'd be better to just say that we don't offer
> > the Edition and instead suggest various spins for architectures where
> > this comes up. Or, where we decide it's important enough, to make sure
> > we use software that works across all relevant archs (or if possible to
> > fix it when it doesn't work).
> >
>
>  And that's a completely valid approach if we choose to do it like this. I
>  just feel we shouldn't be deciding this in the test list. It's a higher
>  level policy than what we usually discuss regarding blocker criteria. 
Stephen did say he planned to take it to FESCo

[Richard Ryniker]

> > In an extreme situation, a release could be nearly impossible due
> to
> > dependency cycles.
>
> You'd need to provide specific examples for "extreme" as this has not
> happened in recent Fedora history (at least back to F-21) 
I cannot cite an historical example.  With more than a thousand packages
in the Live edition, and several thousand in the Workstation edition, it
seems severe to insist they must all (except hardware-specific) work in
the primary architectures or a release is automatically blocked.

That may be the right thing to do, and handle any situations that are too
awkward on an exception basis.

To concoct an extreme situation, suppose the Firefox developers decide
that a newer version of GCC is necessary to build for the ARM
architecture.  I would argue the appropriate choice is to release Fedora
without Firefox in the ARM builds, and include Firefox for ARM in a later
release.  I do not consider this a reason to remove a valuable Firefox
from X86 builds.

In a general sense, one might argue any time a program works on one
architecture but fails on another, this must involve hardware enablement
at some level.  A compiler enables convenient use of a machine's
architecture-specific instruction set and hardware features, therefore
any application that uses this compiler is hardware-specific, and enables
that hardware in some way.

None of this reduces the value of a consistent Fedora experience across
architectures.  I believe this objective should influence choices about
what to include in the default package set, and where to allocate
development resources, but not forbid packages that deliver significant
value.

Most users are likely to quickly augment Fedora with their favorite
applications and configuration, and thereby make their Fedora different
from the default experience.  It is still valuable to strive for
consistency across architectures, but wrong to pretermit valuable
applications only because they do not, or cannot, support some
architecture.

[Stephen Gallagher]

On 05/12/2017 06:17 AM, Peter Robinson wrote:
>  On Fri, May 12, 2017 at 9:36 AM, Kamil Paral
> <kparal(a)redhat.com&gt; wrote:
> >
> > On Thu, May 11, 2017 at 11:33 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;
> > wrote:
> >> On Wed, May 10, 2017 at 04:52:05PM +0200, Kamil Paral wrote:
> >>> Why would we dictate that Editions/Spins can't use different software on
> >>> different architectures? It might make perfect sense to use browser X on
> >>> x86_64 because it's very good, but use browser Y on i386 because of
> >>> memory
> >>> limitations of i386 arch (browser Y needing much less memory than
> >>> browser
> >>> X). Similarly, if shell A no longer supports i386, why would be ban it
> >>> from
> >> Speaking as someone who "sells" this stuff, I think it'd be
> confusing
> >> for the Editions to offer different software (except where dictated by
> >> enabling the hardware). It'd be better to just say that we don't offer
> >> the Edition and instead suggest various spins for architectures where
> >> this comes up. Or, where we decide it's important enough, to make sure
> >> we use software that works across all relevant archs (or if possible to
> >> fix it when it doesn't work).
> >>
> > And that's a completely valid approach if we choose to do it like this. I
> > just feel we shouldn't be deciding this in the test list. It's a higher
> > level policy than what we usually discuss regarding blocker criteria.
>  Stephen did say he planned to take it to FESCo 

https://pagure.io/fesco/issue/1707