From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id F07341F461 for ; Tue, 16 Jul 2019 10:01:05 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=JIqphFQ59K3myo38 D1Bd7V5kqo78u0mKsg7Xr3Xa5804Lx8Nz5YckFTh3AczIR5wqls5tPdGwfGPlAKD v+LGMJUlXP9Ts1hMjS6rn6X+SVYQM2AJOx0hVbtSE8gUbt2Dk337miFmM3Mc+QAV DtkBsWDWXbA6pwhrc5/cn2MZ5rQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; s=default; bh=yUFquR0M/QZcQs19IVnZha HTdTM=; b=RGtB5mPlGDCmA5xUOS9GMgUtd0Ssm2fVCe7YmBqUQpWwTdEGjDg6+G pp1UcvFAKoXMgGAePyGZIC2z9tFO/8PIwlouJ82X4AoxI4JX8Ui9I+s/7iTJMomV 3ORB4FPziPMkat+Kcscm4Aq5bhgaCdL5STJ0K9RMOK5HN65NuyWTs= Received: (qmail 74942 invoked by alias); 16 Jul 2019 10:01:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 74934 invoked by uid 89); 16 Jul 2019 10:01:03 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: shared-ano163.rev.nazwa.pl Date: Tue, 16 Jul 2019 11:54:13 +0200 (CEST) From: Rafal Luzynski To: Carlos O'Donell Cc: libc-alpha@sourceware.org Message-ID: <230990254.1749254.1563270853574@poczta.nazwa.pl> In-Reply-To: <59540b52-517d-8fff-6634-68cec3ecc0ef@redhat.com> References: <1071591234.75034.1562890378582@poczta.nazwa.pl> <981995761.250170.1562927048771@poczta.nazwa.pl> <59540b52-517d-8fff-6634-68cec3ecc0ef@redhat.com> Subject: CI/CD in glibc (was: nss_db: protect against empty mappings) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 12.07.2019 13:36 Carlos O'Donell wrote: > [...] > Rafal, > > If you think this is a bad developer experience, then please feel > free to voice your concerns. This is little off-topic so I'm changing the subject of the thread. To some extent it is indeed a kind of bad experience. In a perfect world, every "make" run should rebuild all binaries whose source code had changed and reuse those existing binaries from the previous builds whose source code had not changed. Usually this works fine but sometimes does not. In these rare cases "delete everything and rebuild from scratch" is the correct answer. I don't want to waste my time and other developers' time to build a system where every "make" works incrementally correctly because the aim is to ensure that the rebuild from scratch works correctly because this is what the distros are doing. Incremental build is necessary only for our small group of developers and, again, it works fine most of the time. So maybe instead of focusing on incremental builds I should explain why I perceive building as so important. I always want to ensure that my patches do not break glibc, including ensuring that they don't break today (if yesterday everything was OK it does not mean it is OK today because something might have changed upstream). This is a simple and repetitive task which could be done automatically. So the question is: can we have a CI/CD mechanism in glibc project which would perform all builds and tests for every commit and raise an alarm if anything goes wrong? Can it be extended to verifying patches when they are posted on this mailing list, before pushing to the main repository? Can it be part of sourceware.org, maybe integrated with patchwork.sourceware.org? Some big source code management systems like GitHub or GitLab already include such features, can we reuse them? If not, can we have an unofficial clone at GitHub (well, we already have one [1]) to do that task? Such a mechanism would be useful to detect use cases like: * something goes wrong but the problem is only in my machine because the online service confirms there is no problem; * the code works fine in my machine and in all other developers' machines but fails in one exotic hardware architecture. Regards, Rafal [1] https://github.com/bminor/glibc/