From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4027 invoked from network); 15 Dec 2021 22:52:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2021 22:52:29 -0000 Received: (qmail 1671 invoked by uid 550); 15 Dec 2021 22:52:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1636 invoked from network); 15 Dec 2021 22:52:25 -0000 ARC-Seal: i=1; a=rsa-sha256; t=1639608731; cv=none; d=zohomail.com; s=zohoarc; b=lA/77DsoYI+ZgrzS7yMDtJ7cQAbweHakC2GVkCFkTUEpymlA57SdWpupZG0z0VYxLJBVQ/tlX2ZdWpinYrBIQAHTIl+fMYxpGmHrHxnopA0U8H2FaSONFm2OHNSvENQU9Q2GqrNLSAEqM2L2Q8w+TOhzyFK2a5LDoKNu00ynwzs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1639608731; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=Gbrh8isOSbn2dmE9cPTh1I2QFUQL8tTXSWgZlFTiOCM=; b=UTUxcfjVM9YJoW9QTIBxRMSMhiwcKTzZVPn8rX7+X5SuCbEaD+GQakwg2dZMUsFlB2BObszct4/dFLmyhawm29ESvQLIBwMAb6YzNJ30M9FcxJ4K7RrLILkUi95paCfb7LJUunw0ssyW/PfWwRX0fsvVGPwCwCWYgdh0Xdkfd7w= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zv.io; spf=pass smtp.mailfrom=me@zv.io; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1639608731; s=zoho; d=zv.io; i=me@zv.io; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:Content-Type:MIME-Version:Content-Transfer-Encoding; bh=Gbrh8isOSbn2dmE9cPTh1I2QFUQL8tTXSWgZlFTiOCM=; b=LiHz9b/OtXCVUnACqbGaprzpXcm+TeXV+yY25HGRsbye1C8ayoJROsOFu6uxErk3 v1kDK0GfN/xePb7NCZUV80sdI88qir4GafDDZ8nVFJjORZMzUsbFbQxvTNaV9xVx9va MN8Ov/JelFfvpq+U2c0bglqoIgr4YOi7Y2fN21cM= Message-ID: <5faf9ff0eaa6b72ac3c3b22e3a41bde071ae5806.camel@zv.io> From: Zach van Rijn To: musl@lists.openwall.com Date: Wed, 15 Dec 2021 16:52:05 -0600 In-Reply-To: <8ed85057-5ad8-1341-ba02-46bb15ee04bd@dustri.org> References: <8ed85057-5ad8-1341-ba02-46bb15ee04bd@dustri.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Subject: Re: [musl] Current state and future of musl development infrastructure On Wed, 2021-12-15 at 22:22 +0100, jvoisin wrote: > Hello everyone, >=20 > ... > > I think that everyone agrees that we need a bugtracker, and > likely some CI. Something lightweight (ho heavy dependencies), > self-hosted, that can integrate well with emails/mailing- > lists/patch tracking/=E2=80=A6 My primary concern is that this will create unnecessary noise and maintenance burdens. Note IRC and the mailing list are 3rd party. Having watched this space over the past few years I think there is one actual problem we need to solve and many that we don't: 1. Fixes and improvements are suggested in IRC or on the list, then folks follow up months later to ask what is the status. The matter is lost in the wash or it is unclear who had the baton. Rich is busy. But is an issue tracker needed here? The rule of thumb up to this point has been to punt it from IRC to the list. Since Rich is the sole gatekeeper, a disciplined approach to keeping "serious" topics/discussion to the list, and using IRC as casual grounds for starting discussions might be sufficient. Then a TODO list would be the right tool to ensure issues aren't lost. For example: what of the Hexagon port? Using an issue tracker would provide a public view of open/closed issue status, and maybe subscriptions. Is this all that we need? Would splitting the lists into 'musl-devel' and 'musl-support' be enough? Even this seems like overkill. Most of the other problems are mitigated by the sole-developer model and general nature (libc) of this project: * Quality control -- each change is already carefully reviewed * Widespread testing by various distros * Relative stability and low churn -- ~50 commits in a year! As for CI. It would probably be helpful to be able to run libc-test and perhaps other applications on a number of real hardware platforms in some automated manner. > ... >=20 > dalias is very adamant that CI & testing don't belong in the > same repo as software, but in a separate one. +1 > Most of the forges providing continuous integration (gogs, > gitea, gitlab, =E2=80=A6) don't play nice with emails, except sourcehut > ( https://sourcehut.org/ ), which is "email first". >=20 > Henceforth, I think that a good move forward would be to go > with sourcehut: Very few people want to read documentation to submit patches. I must say, I had to use Google to find the sourcehut docs. Can you find it on https://sourcehut.org/ or https://sr.ht/ ? The ~foo/bar+baz@example.com syntax is unintuitive for newcomers. > ... >=20 > > What do you people think? Overall the volume of fixes/improvements/features is so low that it might not make sense to set up and maintain any more than: 1. A TODO list 2. A brick-simple cluster of machines for testing /$0.02 ZV