This is the mail archive of the libc-alpha@sourceware.org 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
right.

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.

Thanks,
Florian


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