On Tue, 01 Sep 2026 18:37:32 +0200 Dag-Erling Smørgrav <[email protected]> wrote:
> Tomoaki AOKI <[email protected]> writes: > > Dag-Erling Smørgrav <[email protected]> writes: > > > Tomoaki AOKI <[email protected]> writes: > > > > It would be nice if UPDATING has an entry whenever clean builds are > > > > required, with the reason why for future records. > > > That would be a huge step backward since our goal is to never need a > > > clean build. We have a script (depend-cleanup.sh) which is supposed to > > > automatically clean either part of or the whole object tree when needed. > > If it's always maintained to work flawlessly just-in-time. > > Same goes for your UPDATING suggestion. Someone has to do it. If > Someone is going to to Something, adding an entry to depend-cleanup.sh > is more useful than adding an entry to UPDATING, and not much harder. > > DES > -- > Dag-Erling Smørgrav - [email protected] Would be a bit different. For UPDATING, I think any committer who noticed the regression can add warning even if cannot take enough time to fixup depend-cleanup.sh, while depend-cleanup.sh should be fixed by the committer of the offending commit (or dedicatedly assigned specific committers). In this kind of cases, UPDATING entry isn't needed to be 100% precise. Something like Upgrading from commit aaaaaaaaaaaa to commit bbbbbbbbbbbb requires clean full build. is meaningful enough, and any committer who had enough time to bisect can narrow down the range until the fixup of depend-cleanup.sh is finished and committed. And if there's another committer bitten on upgrading from commit cccccccccccc (in between commit aaaaaaaaaaaa and commit bbbbbbbbbbbb) and commit dddddddddddd (after commit bbbbbbbbbbbb), the committer can fix the range with commit cccccccccccc to commit bbbbbbbbbbbb. This kind of rough informations are still quite helpful. Regards. -- Tomoaki AOKI <[email protected]>
