This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
in Patchwork.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]