From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Korsgaard Date: Sun, 06 Sep 2020 09:43:02 +0200 Subject: [Buildroot] More maintainers In-Reply-To: (Adam Duskett's message of "Sat, 5 Sep 2020 15:25:19 -0700") References: <638a9bc4-197f-931e-0795-2605ff734291@mind.be> <20200903182409.6b337059@windsurf.home> <87o8mlmoga.fsf@dell.be.48ers.dk> <87blilmeo2.fsf@dell.be.48ers.dk> <877dt8n2o7.fsf@dell.be.48ers.dk> <20200905211650.0a229191@windsurf.home> <20200905223835.1e68d658@windsurf.home> <20200905230431.34bcd9ea@windsurf.home> Message-ID: <87imcric55.fsf@dell.be.48ers.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net >>>>> "Adam" == Adam Duskett writes: Hi, Thanks for the constructive input! > Basic things that could be done with CI/CD that don't take much CPU power and > would reduce the time spent on each patch: > - Running check-pkg automatically I guess you mean check-package? > - Running basic grammar and spelling checks I don't know how easy that is to do, given that commit messages often quote code and/or command output. We can certainly extend check-package to run the commit message through aspell. What open source utilities are available for grammar checks? > - Checking if all recursive dependencies of new packages have been added in > new Config.in files. That IMHO very fast becomes complicated with optional dependencies and patches to existing packages rather than a completely new package, but if you have a good idea? > If you want to get complicated a reduction of CPU time/resources could > also be done with: > - Having prebuilt docker images or tarballs that have a partially > complete build I am not sure how realistic that is given that master (or next) is a moving target and we would want to test against the current situation? -- Bye, Peter Korsgaard