On Mon, Aug 24, 2020 at 01:52:19PM -0400, Don Zickus wrote:
> On Mon, Aug 24, 2020 at 09:31:53AM -0500, Justin Forbes wrote:
> > > Right. rh-configs and fedora-configs are nice in that they build ONLY those
> > > configs.
> > >
> > I don't see a problem with having them broken out for specific cases,
> > but really by default people should be in the habit of build/check for
> > both. if you break one, you break everything.
>
> Here is my thinking on this. The problem is really _time_. For a large
> majority of the use cases, developers are not engaging in make config
> changes. They just want to create them and start hacking.
Yes, time is a major part of the problem here, but there is also the
fact that currently dist-configs "builds" config for both, but
"processes" only for one (or the other way around). See the confusion?
(mangled paths to make them shorter)
redhat ((1170437ac4a7...))]$ make dist-configs
BUILDID is ".test".
cd /redhat/configs; rm -f kernel-*.config \
kernel-*.config.orig \
kernel-*.config.tmp
cd /redhat/configs; ./build_configs.sh "kernel" "" ""
Building /redhat/configs/kernel-x86_64-rhel.config ... done
Building /redhat/configs/kernel-x86_64-debug-rhel.config ... done
Building /redhat/configs/kernel-ppc64le-rhel.config ... done
Building /redhat/configs/kernel-ppc64le-debug-rhel.config ... done
Building /redhat/configs/kernel-s390x-rhel.config ... done
Building /redhat/configs/kernel-s390x-debug-rhel.config ... done
Building /redhat/configs/kernel-s390x-zfcpdump-rhel.config ... done
Building /redhat/configs/kernel-aarch64-rhel.config ... done
Building /redhat/configs/kernel-aarch64-debug-rhel.config ... done
Building /redhat/configs/kernel-x86_64-fedora.config ... done
Building /redhat/configs/kernel-x86_64-debug-fedora.config ... done
Building /redhat/configs/kernel-i686-fedora.config ... done
Building /redhat/configs/kernel-i686-debug-fedora.config ... done
Building /redhat/configs/kernel-ppc64le-fedora.config ... done
Building /redhat/configs/kernel-ppc64le-debug-fedora.config ... done
Building /redhat/configs/kernel-s390x-fedora.config ... done
Building /redhat/configs/kernel-s390x-debug-fedora.config ... done
Building /redhat/configs/kernel-aarch64-fedora.config ... done
Building /redhat/configs/kernel-aarch64-debug-fedora.config ... done
Building /redhat/configs/kernel-armv7hl-fedora.config ... done
Building /redhat/configs/kernel-armv7hl-debug-fedora.config ... done
Building /redhat/configs/kernel-armv7hl-lpae-fedora.config ... done
Building /redhat/configs/kernel-armv7hl-lpae-debug-fedora.config ... done
Processing /redhat/configs/kernel-5.9.0-aarch64-debug.config ... done
Processing /redhat/configs/kernel-5.9.0-aarch64.config ... done
Processing /redhat/configs/kernel-5.9.0-ppc64le-debug.config ... done
Processing /redhat/configs/kernel-5.9.0-ppc64le.config ... done
Processing /redhat/configs/kernel-5.9.0-s390x-debug.config ... done
Processing /redhat/configs/kernel-5.9.0-s390x-zfcpdump.config ... done
Processing /redhat/configs/kernel-5.9.0-s390x.config ... done
Processing /redhat/configs/kernel-5.9.0-x86_64-debug.config ... done
Processing /redhat/configs/kernel-5.9.0-x86_64.config ... done
Processed config files are in /redhat/configs
Which flavor does kernel-5.9.0-x86_64.config have? If it had 'built'
only 'rhel', I would know better. Point is, you have only one of the
flavors built, and untagged. So I'm wondering, how useful it really
is, as is?
If it gets changed to be rh-configs + fedora-configs by default (if no
other flavor is explicitly passed on the cmdline), even if it takes
longer, that's fine by me, as it will be clearer.
But yeah, some will complain that now they need to copy a different
file to import the .config, but at least they will be sure of what
they are copying.
>
> For that case, we should aim to be as quick as possible. I mean generating
> the configs is slower than what people expect.
>
> However, as part of an MR verification process, we _should_ check. We
> should run 'make dist-check-configs' as part of the CI to catch anything.
> Nothing should be merged unless it passes that check for the exact reasons
> you provided.
>
> Now once developers get burned a few times, they will learn to run that
> command locally before submitting an MR. And that is easy to do.
>
> For that reason, I have been leaning towards finding ways to speed up
> dist-configs and incorporate the full checks in gitlab-ci.yml.
>
> Thoughts?
>
> Cheers,
> Don
>
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
