On 12. 01. 19 19:47, Kevin Fenzi wrote:
On 1/12/19 5:59 AM, Miro Hrončok wrote:
On 12. 01. 19 14:19, Kevin Kofler wrote:
Dan Horák wrote:
This is a reminder that this begins this Friday and will probably be in
place for 4 days. If there are increased downtimes, we will update the
data when we know it.
4 whole DAYS of Koji outage are absolutely unacceptable!
This just shows how bad an idea it was to add those exotic secondary
architectures to the primary Koji and to make them blocking for all
builds.
We really need to go back to building secondary architectures on
secondary
Koji instances, so that they do not hold the entire Fedora hostage for
days!
While I don't necessarily agree with the tone or wording, Kevin has a
point here.
I don't agree with the tone, wording or point. :)
Ah, it seems my e-mail was a little pointless without providing more thoughts.
Sorry about that.
When there were secondary arch koji's it took a number of people full
time to nurse along koji shadow. Often things would land in primary,
secondary would find a bug later and there would need to be a lot of
coordination and back and forth before things were fixed in both places.
Now all those folks can concentrate on the bugs as they happen in
primary koji, fix them faster and everyone wins.
I agree with this. That clearly reduces a lot of work that would otherwise be
carried by a group of alternate arch fighters. Also, the situation is more
easily to read etc.
No doubt that having everything in one Koji is beneficial.
If there were constant outages you might have more of a point, but this
is the only multi-day one I can think of, it's over a weekend, noarch
packages can keep building and if there's a security or urgent issue we
can just Exclude s390x until it's back up.
It's however not just about outages. What bothers me about s390x is:
* From time to time there are situations where the build waits for a s390x
builder.
* Upstreams don't have access to a s390x CI service and are often unable to
debug s390x problems without (very slow) virtualization.
* With ppc64 removal, s390x is the only Big Endian arch in the pool (while
ppc64 was easier to get to via CentOS CI).
I just think that we are burning a lot of resources without a clear visible
benefit. Don't get me wrong, I am no architectures expert and I don't intent to
pretend I am. It's just that all the s390x bugs I've seen for packages I happen
to help taking care of are from other Fedora maintainers who fight FTBFS for
their own packages etc., never from any actual users.
s390x just feels to me like "that weird thing that often breaks and nobody
really cares about". I realize this view is very narrow and is mostly based on
feelings rather than facts, however it just how it feels.
Hence I consider it unfortunate that s390x can block the whole distro, even if
it's just for a couple days.
I'm not saying all this to start a flame or to blame one poor architecture, I'd
genuinely love to know the answers to:
* Where can upstreams get a nice CI as a service for s390x? [1]
* What are the users of Linux on z and what packages/apps/tools are they
interested about? Do they run desktop environments, should I e.g. bother fixing
a bug in a desktop GUI application that controls a 3D printer? Or is it just OK
to Exclude s390x on such apps? etc.
* Where do we actually gain users of Fedora/s390x? When I search for Linux
s309x, I get to our Wiki (after several Ubuntu and IBM links) [2], but that page
is probably not very user targeted and seems a bit outdated.
[1]
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/5FH2DUYXQEOJQZPDA7KSHVBRANKXV3X2/
[2] https://fedoraproject.org/wiki/Architectures/s390x
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
