This is the mail archive of the
mailing list for the glibc project.
Re: Automating the maintenance of the ChangeLog file
* Joseph Myers:
> On Wed, 28 Nov 2018, Florian Weimer wrote:
>> Does our Patchwork instance support this? Are there Gnus/mutt
> I thought that the main requirement for patchwork to remove committed
> patches automatically was that the git-patch-id of the committed change
> was the same as that of the patch posting. The patch-id does not depend
> on the commit message, only on the diffs (but this does require that the
> posted diffs be the same as the committed ones - in particular, committing
> changes to the ChangeLog file that aren't included in the diffs prevents
> such automatic removal at present).
Interesting. But given that Patchwork is a wasteland today and only a
subset of posted patches will be ever committed (each revision counts as
a new patch, after all), I don't think the auto-closing of posted
patches is a substantial factor in reducing the number of stale patches
I'm coming to this from a completely different angle. I want a way for
contributors and reviewers to have a *reliable* to determine what the
patch will look like in the repository. That includes both the diff
*and* the commit message.
Patchwork could be a tool in this context. If it is able to close
approximate the commit, then we could give contributors a list of
formatting rules, and they can double-check on Patchwork if they got it
On the other hand, maybe an approach based on pull requests is the
future, where all this is much more tightly integrated. But I don't
know if we (as in GNU) have hosting for that available.