Date: Fri, 16 Dec 2016 11:30:28 +0100 From: "Vlad K." <vlad-fbsd@acheronmedia.com> To: freebsd-ports@freebsd.org Subject: Re: (In)Stability of the Quarterly Branch Message-ID: <06804aa11a2fb6aae231d50fd5656389@acheronmedia.com> In-Reply-To: <7e071aa9-4fd8-9e6e-07f1-d0fa6632087a@toco-domains.de> References: <3e7f94efc6428181a289742d7dd627df@acheronmedia.com> <CAO%2BPfDcYDy=w9Xaf02zWiYNO38Yex0ioX6z4a-5KL8k7e9qgQA@mail.gmail.com> <20161215170154.0ca2017914c0bb032516b413@gmail.com> <d806b1f6-9f9a-6546-d44f-5b04f3c422a9@FreeBSD.org> <CAO%2BPfDd0BWuUnY62EeOVzv21pZ3estu=Vgz4chvbqWcaD6adaQ@mail.gmail.com> <7e071aa9-4fd8-9e6e-07f1-d0fa6632087a@toco-domains.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-12-16 11:08, Torsten Zuehlsdorff wrote: > > There are two problems with this: > 1) Many ports have no maintainer > 2) Even more ports have no tests at all We can't have our cake and eat it :) Obviously, a STABLE repo would have to be a subset of ports, not all 26k of them. The criteria I spoke of in the original post would include that each port has a valid maintainer. Maintainer TIMEOUTS would be monitored and port kicked out if the maintainer is gone. For starters, we'd have to enumerate all the ports that have stable upstreams. For example, RoundCube supports both the new 1.2.x repo and the old, legacy 1.1.x. That means 1.1.x could've been added to the STABLE repo and maintained until it EOLs. Second, ports that do not obey some reasonable versioning scheme, eg. major version changes MAY break backwards compatibility, minor MUST not, and major.minor.point MUST be only bugfixes and security. can be added ONLY and ONLY if the MAINTAINER commits to manually checking every change and making sure only security and bugfixes are backported. Third, ports with no unit tests... well.. I don't know how many are there, but perhaps we can make a list of "strategically important" ports for servers and maybe desktops, and those that are strategically important but have no unit tests, would go in, but would require an active maintainer committed to do run tests. I'm sure such a list would be bikeshed into oblivion, but we could at least try... Fourth. It'd be ideal if Poudriere could grow a function that: a) runs port's unit tests b) permutates OPTIONS and for each re-runs the build + unit test. Broken combinations can be automatically marked as BROKEN. Now... automatically: b.1) a patch is automatically generated but a human has to review and commit b.2) the testing infrastructure autocommits (I'm sure portmgr would object to this) b.3) we create a new "stability" database like vuxml which these automated tests can automatically populate Brainstorming here, critique welcome! -- Vlad K.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06804aa11a2fb6aae231d50fd5656389>