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.3 required=5.0 tests=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 18407 invoked from network); 16 Dec 2021 05:02:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Dec 2021 05:02:38 -0000 Received: (qmail 27761 invoked by uid 550); 16 Dec 2021 05:02:35 -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 27726 invoked from network); 16 Dec 2021 05:02:34 -0000 Date: Thu, 16 Dec 2021 00:02:20 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20211216050220.GL7074@brightrain.aerifal.cx> References: <8ed85057-5ad8-1341-ba02-46bb15ee04bd@dustri.org> <5faf9ff0eaa6b72ac3c3b22e3a41bde071ae5806.camel@zv.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5faf9ff0eaa6b72ac3c3b22e3a41bde071ae5806.camel@zv.io> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Current state and future of musl development infrastructure On Wed, Dec 15, 2021 at 04:52:05PM -0600, Zach van Rijn wrote: > On Wed, 2021-12-15 at 22:22 +0100, jvoisin wrote: > > Hello everyone, > > > > ... > > > > 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/… > > 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? This is roughly what we need: a place to represent long-term state for the subset of issues that cannot be resolved immediately. Historically that was very few, but what happens is that they start to accumulate over time -- this is rather inherent in their nature. Representing immediately fixable bugs would be fine too, but less important. > Would splitting the lists into 'musl-devel' and 'musl-support' be > enough? Even this seems like overkill. No, I don't think so. The problem is not that the list is overloaded for multiple uses. The problem is that there's limited capability to search for and reply into existing historical threads unless you're a list member with your copy of the archive, and there's no way to link new requests with old ones like "duplicate of..." relationship in a bug tracker, nor any easy way to filter on "still open" vs "resolved", etc. > 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. Yes. Having this automated would be really nice. Even better if it could be done not just for the official upstream repo but for proposed patches/patchsets or third-party git branches (on some sort of request). I'd really love if the CI were optimized to do incremental builds and reuse artifacts as much as possible for rapid results, but doing that right probably requires fixing missing dependency tracking in the build. > > 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 A manually curated TODO list/wishlist on the wiki was how this was managed for the last N years, and it wasn't really good because it failed to link community discussion of the issue and didn't capture things not already valued by me or community. Even with a bug tracker it would be perfectly fine (and much more effective than it is now) to have a TODO/roadmap, since it could *link to* the relevant tracker items for more detail and record of what exactly is wanted or proposed and why. Rich