From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by sourceware.org (Postfix) with ESMTPS id CE207385042F for ; Thu, 1 Oct 2020 11:51:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CE207385042F Received: by mail-wr1-x444.google.com with SMTP id j2so5342570wrx.7 for ; Thu, 01 Oct 2020 04:51:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=g/u6YUWYsNvQqtAfJeCAweM6aFX/C7fgxmT7w66m54w=; b=Xsxv9YzxFklMSJji3mjgDwqUAmyMLjxml1Hj9K2LYrC9ucPuP4lAg5RsuU9tIEHoD7 mgvJwbisaYrPPEEsbXJswNTNbDGqrDxZr3i4WmPX83O8LE46AFwUboudl2RITFn/mbVD Cpfl/I5wWP1r8gjRmlNJcJoT2UClp26vAyYIh3qalF0ihY5bWS4xzqgVX1/ht2e4k4SG 7dhZHL33Pt22BfT3/0ejnl75JzbV8cWYKUP4bpSzvhLcfc89WbTHxVhVZU91BuVpIhJm xzJSX3AFiVUW0Rpn/8QXyuBuEE6gD1NdYE6BD//Sj2gl/evBQp72axid2cV688Z4/izu V5cA== X-Gm-Message-State: AOAM531tqaQgkTsARpxs7Y3z6/E1cr+1yJjo+E6xQ2GJ0lv+T4u1qglv bdgFBMCjEdDltnz+RSDIp0I= X-Google-Smtp-Source: ABdhPJyEpSTK34OedRCkSg3725/VMOQm/DZKke/82ZnVPAZpY2Z3Qcl0dZQqG9padRGg87BVikIVtg== X-Received: by 2002:adf:fed1:: with SMTP id q17mr8252687wrs.85.1601553090981; Thu, 01 Oct 2020 04:51:30 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id o4sm8719927wrv.86.2020.10.01.04.51.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 04:51:30 -0700 (PDT) Subject: Re: [PATCH 00/16] Fixes; Document remaining stdint.h types To: "Michael Kerrisk (man-pages)" Cc: linux-man@vger.kernel.org, libc-alpha@sourceware.org, gcc@gcc.gnu.org References: <20201001101559.77163-1-colomar.6.4.3@gmail.com> <754766a8-6749-1d95-f0ba-999f1a123405@gmail.com> <2dc7f5d7-c134-9209-67c2-7aeda0ad651b@gmail.com> From: Alejandro Colomar Message-ID: <886f5647-2911-951a-b62a-4f9b1ed8850f@gmail.com> Date: Thu, 1 Oct 2020 13:51:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 11:51:33 -0000 Okay then :) Thanks, Alex On 2020-10-01 13:50, Michael Kerrisk (man-pages) wrote: > Hi Alex, > > On 10/1/20 1:41 PM, Alejandro Colomar wrote: >> Hi Michael, >> >> I did it this way because then you have a clearly ordered list >> of the commits, and in which order they go, >> so I thought it might be easier for you (creating less conflicts). > > Yes, I understand the rationale. But when I get a series of > loosely related patches in a series of 20, and multiple > conversations start about independent topics, I'm finding > it quite some effort to keep track. > >> And also, I can hold any more recent patches, such as __int128, >> for when you finish applying the previous set, so I fix the >> conflicts before you ever see them. >> >> Don't you think? >> >> I don't mind fixing for example patch 5, >> and then rebasing the rest (and also the patches I didn't send yet), >> and resending them as an answer to v1 00/16. >> >> But if you still prefer smaller sets, I'll send you smaller sets. > > I do prefer smaller sets. And yes, occasionally things may > go wrong in terms of patch conflicts, but I think that may be > a smaller than the problem I note above. > >> It's just that these patches are usually very dependent of the >> previous ones, and therefore prone to conflicts if you >> don't apply them in the same exact order. >> >> Your thoughts? > > As you can see, there's no perfect solution here. In such > situations what I try to do (where possible) is order the > patches from least contentious to most contentious. > That way, the patches that are almost certainly going to > be applied are loaded at the front and the chance of having > to rebasing later patches in a series is lower. > > Thanks, > > Michael > > > >> On 2020-10-01 13:32, Michael Kerrisk (man-pages) wrote: >>> Hi Alex, >>> >>> On 10/1/20 12:15 PM, Alejandro Colomar wrote: >>>> Hi Michael, >>>> >>>> Here are a few fixes (including one removing .br), >>>> and then the remaining stdint types. >>> >>> These very long patch series are a bit overwhelming for me. >>> I'd have preferred a few smaller patch series. For example, >>> I think I would have preferred 3 series like this: >>> >>> 1-4 >>> 5-12 >>> 13-16 >>> >>> One reason is that the multiple parallel reply threads that >>> sometimes occur can sometimes be rather difficult to track. >>> (Your patches have started some quite useful conversations!) >>> >>> For example, I suspect Jonathan's comments may trigger changes >>> for patches 5-12. >>> >>> For now, I'm applying 1-4 and 13-16. It looks like some reworking is >>> going to be needed for the others. When you do resubmit them, please >>> start a new thread (rather than replying into this thread). >>> >>> Thanks, >>> >>> Michael